moq-wg / moq-transport

draft-ietf-moq-transport
Other
79 stars 18 forks source link

Recommend use of mid-range values as default priority in implementations #504

Open englishm opened 1 month ago

englishm commented 1 month ago

The text we landed for draft-05 to define priorities (https://github.com/moq-wg/moq-transport/pull/470) indicates that we should use a 8 bits (x (L) where L is 8) to convey subscriber priority and similarly a byte to convey publisher priority.

Subscriber Priority (8), ( https://www.ietf.org/archive/id/draft-ietf-moq-transport-05.html#section-6.4.2-2 )

Publisher Priority: An 8 bit integer indicating the publisher's priority for the Object ( https://www.ietf.org/archive/id/draft-ietf-moq-transport-05.html#section-6.11.1 )

The text also indicates that lower values have higher priority which I read as meaning 1 (0000 0001) should be sent before 10 (0000 1010), but we don't seem to explicitly indicate anywhere whether we expect these values to be interpreted as signed or unsigned integers.

Should 1000 0101 be sent before or after 0000 0101? (After)

Is 1000 0101 -5 (i8) or 133 (u8)? 1000 0101 is 133 (u8)

Edit: We should probably recommend that implementations use a mid-range value like 127 as a default to allow for prioritizing both above and below it. (The MoQT spec doesn't need to define a default since these values are currently always explicit on the wire, but I think it would be helpful to provide guidance here.)

englishm commented 1 month ago

I have a slight preference for treating these priorities as signed values because it makes 0 a good default for implementations to choose. That way it's possible to go above or below the default.

The same is possible with unsigned values, too, but if we go that direction we may want to provide some guidance to that effect (recommending something like 127 or 128 as a default mid-range value).

englishm commented 1 month ago

Oh, nevermind, @mengelbart noticed some text I missed in section 4: "with 0 being the highest priority" which would imply these are unsigned int values, u8.

It may still be helpful to make that more explicit and recommend a default mid-range value.

ianswett commented 3 weeks ago

I'm fine with some editorial text here if that's how we want to resolve it? (PRs welcome @englishm )

I'm also ok with it being signed, since it it nice for 0 to be a 'default' value, but we don't use signed integers anywhere else in MoQ, so I'm a bit concerned that using them in exactly one spot could be confusing or error prone?

fluffy commented 2 weeks ago

In some cases, things would work better if we allocated some ranges of priorities to specific DSCP like "less than best effort" or "best effort". That would end up making the actually numbers here have absolute meaning too instead of just relative meaning.