IETF MOQ WG: Thoughts on SWITCH

Message Snapshot

• List: moq@ietf.org
• Thread subject: Thoughts on SWITCH
• Message subject: [Moq] Re: Thoughts on SWITCH
• Author: Gwendal Simon
• Published: 2026-05-27T10:58:16.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Gwendal Simon posted to the MOQ working group mailing list on May 27, 2026. Hi Martin, Thank you for the tradeoff analysis. I want to address a few points where the picture is incomplete. ## It is 4 coordinated messages…

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 Martin, Thank you for the tradeoff analysis. I want to address a few points where the picture is incomplete. ## It is 4 coordinated messages, not 3

Plain-Text Body

Hi Martin,

Thank you for the tradeoff analysis. I want to address a few points where the picture is incomplete.

It is 4 coordinated messages, not 3

Your down-switch sequence is REQUEST_UPDATE + SUBSCRIBE + Absolute Joining FETCH.

1/ Step 1 terminates the old track before the new one is confirmed. It is a break-before-make approach. If the FETCH fails or the new track is unavailable, the old subscription is already gone. The subscriber has no fallback. In live streaming, this produces an unacceptable hard freeze.

2/ Priority management. Because REWIND was not adopted and Joining FETCH priority management is still an open issue, there is no relay-side mechanism to sequence catch-up before live delivery. The subscriber must handle it explicitly, so it is actually 4 messages:

1. REQUEST_UPDATE — end old track at Group 33
2. SUBSCRIBE — new track, explicitly low priority, to prevent live subgroup streams from competing with catch-up delivery before it has converged
3. Absolute Joining FETCH — high priority, delivers Objects [34, Live Edge)
4. REQUEST_UPDATE — reset new track priority to normal after FETCH stream closes

3/ Step 4 is asynchronous. It does not follow steps 1–3 in a burst. It arrives only after the subscriber detects the FETCH stream's FIN, potentially seconds later, depending on the lag and network conditions. The subscriber must maintain state across the lifetime of the FETCH stream, monitor its closure, and issue a corrective message at the right moment. This is not a simple four messages operation; it is implementing a state machine.

4/ This comparison is also against an unstable baseline. The WG has already determined the current Joining FETCH text is not shippable as-is. SWITCH is being compared to a placeholder, not a stable alternative.

Up-switch: picking a future group requires relay-side information

Your second message adds a valid up-switch option: pick a future Group N+k and send the quartet for that group, avoiding duplicates at the cost of a few groups at sub-optimal quality. The problem is that the subscriber does not know which N+k is correct. G_switch selection is exactly this computation done relay-side: the smallest Group ≥ Minimum Switching Group ID where both tracks are fully available up to the live edge.

SWITCH is additive

SWITCH does not replace REQUEST_UPDATE + SUBSCRIBE + Joining FETCH. Anyone who prefers that approach, or who switches at the live edge with SUBSCRIBE + UNSUBSCRIBE, can continue to do so. SWITCH does not touch that path. Those who are satisfied with the status quo for their own use cases should not object unless SWITCH, as an addition to the protocol, causes them concrete harm. A preference for a different design is not that harm.

OTT Live TV use-case is not covered by the existing approach. Subscribers in that context routinely operate 2–5 groups behind the live edge. At that lag, switching based on 4-message stateful operation does not work cleanly. Four independent teams h…