Open englishm opened 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).
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.
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?
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.
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)
whereL
is8
) to convey subscriber priority and similarly a byte to convey publisher priority.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(After)1000 0101
be sent before or after0000 0101
?Is1000 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.)