IETF MOQ WG: PR #1770 - changes to PUBLISHER_PRIORITY
Martin Duke posted to the MOQ working group mailing list on August 10, 2026. In today's virtual interim, the general sentiment was that this feature was not worth it -- in exchange for 2-3 bytes of compression per subgr…
Message Snapshot
- List:
moq@ietf.org - Thread subject: PR #1770 - changes to PUBLISHER_PRIORITY
- Message subject: [Moq] PR #1770 - changes to PUBLISHER_PRIORITY
- Author: Martin Duke
- Published: 2026-08-10T20:41:03.000Z
- Source tag:
ietf-mailing-list - Message URL: Open in IETF Mail Archive
Summary
Martin Duke posted to the MOQ working group mailing list on August 10, 2026. In today's virtual interim, the general sentiment was that this feature was not worth it -- in exchange for 2-3 bytes of compression per subgr…
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
In today's virtual interim, the general sentiment was that this feature was not worth it -- in exchange for 2-3 bytes of compression per subgroup or datagram, there are race conditions that can make the priority of a given
Plain-Text Body
https://github.com/moq-wg/moq-transport/pull/1770
In today's virtual interim, the general sentiment was that this feature was not worth it -- in exchange for 2-3 bytes of compression per subgroup or datagram, there are race conditions that can make the priority of a given subgroup/datagram ambiguous. This sits uneasily with the idea that the publisher priority of a given object is immutable.
No one on the call would assert that this compression was a critical feature. However, the editors feel that some proponents were not present, so I've initiated this thread to allow any proponents to state the case that this is worth the logical and conceptual problems that it introduces. I refer you to the youtube recording, which presumably will be posted shortly, for a more detailed discussion of potential issues.
Anyway, please reply to this thread by the 24th if you have concerns with the Editors simply NOT submitting pull #1770 in any form, of if you'd like to respond to something else said in the thread.
Martin