IETF MOQ WG: Thoughts on SWITCH

Message Snapshot

• List: moq@ietf.org
• Thread subject: Thoughts on SWITCH
• Message subject: [Moq] Thoughts on SWITCH
• Author: Martin Duke
• Published: 2026-05-26T17:33:16.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Martin Duke posted to the MOQ working group mailing list on May 26, 2026. We ended up getting bogged down in clarifying questions and recapitulation of the basics, and didn't have time for meaningful discussion, but her…

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

We ended up getting bogged down in clarifying questions and recapitulation of the basics, and didn't have time for meaningful discussion, but here's my view of the design tradeoffs here.

Plain-Text Body

We ended up getting bogged down in clarifying questions and recapitulation of the basics, and didn't have time for meaningful discussion, but here's my view of the design tradeoffs here.

Say the subscriber is currently showing Group 33 and would like to shift BW down. Ideally it would start the other track at Group 34. If you think it should be some other number that's not germane to the discussion.

In the draft today, you would send three messages: REQUEST_UPDATE old track, to set end_group = 33 SUBSCRIBE to new track, LatestObject Absolute Joining FETCH, start_group 34.

If the relay has the new track in cache, it will open a FETCH stream from 34 to wherever the live edge is. The old track ends when it should.

This is *exactly *what SWITCH would do. The only difference is that SWITCH is a unitary operation, so if there's weirdness with priorities, packet loss, etc, it works more seamlessly. The request dependency design is in flux right now, so it's a little hard to say how powerful this unitary property is.

If the relay does not have the new track in cache, then SWITCH will continue to deliver the high BW track until the upstream SUBSCRIBE starts delivering groups for the low track.

This has different properties from the Absolute Joining FETCH, which will terminate the old track immediately, and send a FETCH upstream to get group 34. There will be some latency in getting low-BW 34, but on the other hand we won't be jamming up the last hop with an oversized, high-BW 34.

It seems clear to me that this is the tradeoff, but it is not at all clear to me which is better in terms of actual subscriber requirements.

---

In the up-switch, the properties are different. I* think *that the optimal strategy in the current MOQT draft is to send SUBSCRIBE+Absolute Joining FETCH, but delay closing the low BW subscription. Do make-before-break because you presumably have buffer to spare.

In this case, SWITCH avoids some duplicative data, but again, it's not clear to me that it's important due to the conditions in the use case.

---

I don't have strong opinions about the outcomes of these tradeoffs, but I believe the tradeoff analysis is correct and would like the working group to consider the SWITCH consensus call in this context.

Martin