IETF MOQ WG: Request Synchronization Use Case

Message Snapshot

• List: moq@ietf.org
• Thread subject: Request Synchronization Use Case
• Message subject: [Moq] Re: Request Synchronization Use Case
• Author: Magnus Westerlund
• Published: 2026-05-04T10:15:17.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Magnus Westerlund posted to the MOQ working group mailing list on May 4, 2026. Hi, This email is a to discuss and clarify the mentioned use cases. See other email related to consensus and removal of the functionality. 1.

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

Hi, This email is a to discuss and clarify the mentioned use cases. See other email related to consensus and removal of the functionality. 1.

Plain-Text Body

Hi,

This email is a to discuss and clarify the mentioned use cases. See other email related to consensus and removal of the functionality.

Swap Tracks: When you say pause here, are you using REQUEST_UPDATE to switch the forward flag on these two existing subscriptions, or are you referring to new subscribes and termination of the old one? 2. Client Side ABR: Is this accomplished using new subscribe and termination of the old, changing forward flag, or assuming SWITCH? 3. PAUSE, Unpause: Also, here I would like to have some clarification on the mechanism used. Because I don�t think you can get request reorder with REQUEST_UPDATE as they are sent inline on the same stream for each track. Thus, eventually all the sent requests will be delivered and processed in the order transmited assuming the QUIC connection doesn�t time out.

Please clarify these use cases so that we can have an informed discussion.

/Magnus

From: Cullen Fluffy Jennings fluffy@iii.ca Date: Saturday, 2 May 2026 at 00:11 To: MOQ Mailing List moq@ietf.org Subject: [Moq] Request Synchronization Use Case

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 objecte…