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:04:00.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 Cullen, The poll was on do we need a solution for draft -18. It was also proposed that we should remove the broken solution for now to no…

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 Cullen, The poll was on do we need a solution for draft -18. It was also proposed that we should remove the broken solution for now to not force anyone to implement it as part of the interop target. The discussion also indicated that there are some different views on why a request synchronization mechanism is neede…

Plain-Text Body

Hi Cullen,

The poll was on do we need a solution for draft -18. It was also proposed that we should remove the broken solution for now to not force anyone to implement it as part of the interop target.

The discussion also indicated that there are some different views on why a request synchronization mechanism is needed. Thus, we asked for clarification on the use cases from the WG participants to enable discussion and proposals to consider the relevant use cases when returning to the topic in London in June. This process is to enable solving the issue. It was not intended to implicitly remove a mechanism that has had consensus.

Is it sufficient to state that it is not the intention of removing the concept of request synchronization capability from the protocol by the chairs? The main alternative I see is to leave the required_request_id in -18, possibly with a note about its issues.

The goal here is to find a good solution. And that will require the different participants to state their use cases in sufficient details and what other protocol mechanisms it interacts with. I will comment separately on this aspect.

Cheers

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