IETF MOQ WG: Consensus Call: DTS and SWITCH

Message Snapshot

• List: moq@ietf.org
• Thread subject: Consensus Call: DTS and SWITCH
• Message subject: [Moq] Re: Consensus Call: DTS and SWITCH
• Author: Gwendal Simon
• Published: 2026-05-28T14:08:56.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 28, 2026. For DTS (1) Should the Working Group adopt the contents of this work in some form? YES

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

For DTS (1) Should the Working Group adopt the contents of this work in some form? YES

Plain-Text Body

For DTS (1) Should the Working Group adopt the contents of this work in some form? YES (2) If yes, should the contents of this work be incorporated into the MOQT draft (as opposed to an extension draft)? YES, with a strong caveat on scope.

DTS is not a mechanism I would use for mass-scale OTT live streaming. In that environment, bandwidth is only one of several factors driving quality adaptation, and a relay switching solely on bandwidth tends to overreact to transient drops. Under IETF rough consensus principles, not using a mechanism is not a reason to object to it. The relevant question is whether DTS harms my use case. It does not. DTS and SWITCH are complementary and independent. I can live with DTS.

My concern is scope. The latest version introduces throughput fractions and set ranks, which go well beyond simple ABR switching. Included as-is, DTS could take up a disproportionate part of the specification. I support Q2 as YES, provided the DTS text enters as a focused, proportionate PR, not a standalone chapter in the middle of the spec.

Two further concerns: 1/ The spec does not define how bandwidth should be measured. Without normative guidance, different edge server implementations will behave inconsistently with the same threshold values; 2/ DTS requires all renditions to be fetched upstream while only one is forwarded downstream, so egress can be a fraction of ingress. Furthermore, the relay must maintain per-connection switching state and continuously evaluate selection logic at every group boundary. This moves MOQT relays away from the lightweight, stateless, horizontally scalable model that makes CDN deployment practical at scale.

None of the above constitutes a blocking objection now. Just cautions I would like the working group to keep in mind.

---

For SWITCH (1) Should the Working Group adopt the contents of this work in some form? YES (2) If yes, should the contents of this work be incorporated into the MOQT draft (as opposed to an extension draft)? YES

SWITCH addresses a concrete use case: OTT live streaming subscribers routinely operate 2�5 groups behind the live edge. This is the normal operating condition. When such a subscriber switches quality, a SUBSCRIBE to the new track delivers from the live edge, leaving a multi-group gap that must be filled. The current protocol offers no clean solution for this. Today's only solution requires four messages, is break-before-make, involves asynchronous state management, and is prone to error under the network conditions (congestion, packet loss) where a quality switch is likely to be triggered.

A new streaming protocol must provide a simple, reliable mechanism for client-side ABR switching. Adoption by the OTT live streaming industry depends on it. The WG charter explicitly states that the protocol must support "rate adaptation strategies based on changing codec rates, changing chosen media encoding/qualities, or other mechanisms" and "selection of desired encoding (language,…