[Moq] Re: Thoughts on SWITCH

[Gwendal Simon <[e-mail]>]

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 have already implemented (or explored) SWITCH: Zafer Gurel (MoqTails), Tobje (MoqLivemock), Nokia, and ourselves (moqx). That is not the profile of a mechanism without real use.

Gwendal

________________________________
From: Martin Duke <[e-mail]>
Sent: Tuesday, May 26, 2026 8:08 PM
To: MOQ Mailing List <[e-mail]>
Subject: [Moq] Re: Thoughts on SWITCH

Upon further reflection:

In the upswitch case, make-before-break is one option; the other is to pick some future group and send the REQUEST_UPDATE/SUBSCRIBE/Absolute Joining FETCH trio for that future group. The consequences would be a couple of groups at less-than-possible bandwidth but would avoid any duplicates.

On Tue, May 26, 2026 at 10:33 AM Martin Duke <[e-mail]<mailto:[e-mail]>> wrote:
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