Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
englishm opened this issue Aug 9, 2024 · 4 comments
Open
Labels
Transmission Issues involving what to transmit when, what to drop, priorities, etc

Comments

@englishm
Copy link
Collaborator

englishm commented Aug 9, 2024

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.

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
Copy link
Collaborator Author

englishm commented Aug 9, 2024

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
Copy link
Collaborator Author

englishm commented Aug 9, 2024

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 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
@ianswett
Copy link
Collaborator

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
Copy link
Contributor

fluffy commented Aug 29, 2024

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.

@afrind afrind added the Transmission Issues involving what to transmit when, what to drop, priorities, etc label Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Transmission Issues involving what to transmit when, what to drop, priorities, etc
Projects
None yet
Development

No branches or pull requests

4 participants