IETF MOQ WG: PR #1770 - changes to PUBLISHER_PRIORITY
Victor Vasiliev posted to the MOQ working group mailing list on August 27, 2026. I agree that changing publisher priority is useful. I am skeptical about the scheme proposed in the PR. When changing publisher priority,…
Message Snapshot
- List:
moq@ietf.org - Thread subject: PR #1770 - changes to PUBLISHER_PRIORITY
- Message subject: [Moq] Re: PR #1770 - changes to PUBLISHER_PRIORITY
- Author: Victor Vasiliev
- Published: 2026-08-27T15:31:36.000Z
- Source tag:
ietf-mailing-list - Message URL: Open in IETF Mail Archive
Summary
Victor Vasiliev posted to the MOQ working group mailing list on August 27, 2026. I agree that changing publisher priority is useful. I am skeptical about the scheme proposed in the PR. When changing publisher priority,…
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
I agree that changing publisher priority is useful. I am skeptical about the scheme proposed in the PR. When changing publisher priority, we have roughly three solutions, each of
Plain-Text Body
I agree that changing publisher priority is useful. I am skeptical about the scheme proposed in the PR.
When changing publisher priority, we have roughly three solutions, each of which compromises either:
- A byte per datagram.
- Protocol participants having a consistent view of publisher priority.
- Complexity incurred from a QPACK-style publisher priority update.
#1 is what we do right now, and from my perspective it's the sweet spot. It's suboptimal for audio, but it's probably fairly far from the lowest hanging fruit in terms of byte savings.
I think people underestimate the potential downsides of parties not having a consistent view of publisher priority. Things will work most of the time, but once in a while, active speaker detection will break for some users, and it will be a giant pain to debug. You have to deal with update reordering even if you don't promise full consistency. Also, if something can go wrong across two endpoints, a relay in between would amplify the opportunities for things to go wrong.