You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The text we landed for draft-05 to define priorities (#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.
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.)
The text was updated successfully, but these errors were encountered:
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.
englishm
changed the title
Clarify signedness of subscriber and publisher priority bytes
Recommend use of mid-range values as default priority in implementations
Aug 9, 2024
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 (#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.)The text was updated successfully, but these errors were encountered: