IETF MOQ WG: Knowing the start of a Subgroup
Mo Zanaty (mzanaty) posted to the MOQ working group mailing list on May 4, 2026. Perhaps we should limit Subgroup ID to a single byte. We made everything a varint by default for no good reason. Perhaps we should revisit…
Message Snapshot
- List:
moq@ietf.org - Thread subject: Knowing the start of a Subgroup
- Message subject: [Moq] Re: Knowing the start of a Subgroup
- Author: Mo Zanaty (mzanaty)
- Published: 2026-05-04T04:24:33.000Z
- Source tag:
ietf-mailing-list - Message URL: Open in IETF Mail Archive
Summary
Mo Zanaty (mzanaty) posted to the MOQ working group mailing list on May 4, 2026. Perhaps we should limit Subgroup ID to a single byte. We made everything a varint by default for no good reason. Perhaps we should revisit…
Why It Matters
This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.
Message Excerpt
Perhaps we should limit Subgroup ID to a single byte. We made everything a varint by default for no good reason. Perhaps we should revisit all varint fields to rationalize if they truly need to be. Thanks, Mo
Plain-Text Body
Perhaps we should limit Subgroup ID to a single byte. We made everything a varint by default for no good reason. Perhaps we should revisit all varint fields to rationalize if they truly need to be.
Thanks, Mo
From: Ian Swett ianswett=40google.com@dmarc.ietf.org Sent: Sunday, May 3, 2026 10:38:30 PM To: Cullen Fluffy Jennings fluffy@iii.ca Cc: Magnus Westerlund magnus.westerlund=40ericsson.com@dmarc.ietf.org; MOQ Mailing List moq@ietf.org Subject: [Moq] Re: Knowing the start of a Subgroup
Thanks for all the responses, particularly Mo's detailed response.
I think we should move forward with the bitfield approach in #1618.
I don't love that both Subgroup ID and Priority are ways of prioritizing Objects within a Group. At some point we agreed that priority should only be a single byte. However, with Subgroup ID as well as priority, we now have a huge space. In practice, it probably doesn't matter, and I'm just overthinking this. But it seems like there should be a way to simplify this part of the Object model without restricting any real-world usecases.
Thanks, Ian