IETF MOQ WG: Request Synchronization Use Case

Message Snapshot

• List: moq@ietf.org
• Thread subject: Request Synchronization Use Case
• Message subject: [Moq] Request Synchronization Use Case
• Author: Cullen Fluffy Jennings
• Published: 2026-05-01T22:10:06.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Cullen Fluffy Jennings posted to the MOQ working group mailing list on May 1, 2026. I don’t think it is worth trying to repeat all of them here as people can feel free to find them in the previous meetings but let me me…

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 don’t think it is worth trying to repeat all of them here as people can feel free to find them in the previous meetings but let me mention a few 1) Swap tracks. In a video conference, a subscriber is subscribe to track for Alice and Bob’s video and is watching Alice with Bob paused, but wants to pause Alice and unpa…

Plain-Text Body

I don’t think it is worth trying to repeat all of them here as people can feel free to find them in the previous meetings but let me mention a few

1. Swap tracks. In a video conference, a subscriber is subscribe to track for Alice and Bob’s video and is watching Alice with Bob paused, but wants to pause Alice and unpause the track with Bob. It’s pretty common to want to ensure to pause the current one before unpausing the new track to not have congestion.

2. client side ABR

3. a stream being paused and unpaused in rapid succession and requests reorders on the wire resulting in the opposite of the desired state.

I understand the spec never required the relay to strictly enforce order of operations but that was discussed as “quality of implementation” issue and the time that a relay is likely to get them out of sync was always pretty low ignoring upstream request delay which the use cases can avoid. Most high performance implications are likely to local all the traffic on that quic connection to s single set of processing thread anyways further reducing reorder likelihood.

I’m a bit concerned with how the chairs are positioning this, at the time of the call it was just a poll about did we need to get this sorted out in -18. I don’t think anyone cared about that as there is already too much in -18. Martin clarified as the poll was about punting this to London at which point the objects on the poll were removed. I’m fine with punting this to London.

But after the call I realized what was happening here was the chairs are going to treat this as we no longer have the consensus we had on drafts up to -17 where there was a way to indicate ordering of requests to the proxy. We had no objections to this in last call of -17. We are trying to get to done and reopening base issues about what the requirements are is not helpful.

I want to be very clear I would have objected to bidi if it did not have a way synchronize - this is a fundamental part of bidi. I did not think the poll on the call was that we going to remove the consensus we had around -17. I hope we are are going into London with are assumption about synchronization being we do need a way to indicate desired sequencing of requests to the relay and we are sorting out the details of how to do that without introducing dos problems.