Why do we need a dedicated SWITCH message?

[acbegen]

To date, numerous discussions have been held to understand and devise meaningful solutions for track switching in MOQT. The following is the list of open issues tagged with the ABR label.

• Sender-side ABR #259
  The challenge involves a publisher providing multiple quality versions of the same content (e.g., 360p and 720p video), where the subscriber needs to receive only the best quality version they can handle. The argument is that the publisher knows what it can send and should decide what to send.

• Is there a way for client to ask relay to probe for bandwidth  #370
  Previously, we implemented this through a probing track and whenever the subscriber needed a probing test, it would subscribe to this track.

• Should any priority values indicate "Less than best effort"? / How do you upswitch without causing user harm? #471
  In client-side ABR streaming, the decision to switch to a higher quality stream can lead to excessive bandwidth usage, potentially causing network congestion and degrading the overall user experience. To address this, the proposed solution introduces a "Less than Best Effort" (LBE) mechanism. With LBE, higher-quality (but lower-priority) content is transmitted only if the congestion window (CWND) remains below a specified threshold, such as 1.5 times the Bandwidth-Delay Product (BDP). This approach ensures that LBE data does not compete with or crowd out higher-priority traffic, thereby maintaining network stability and prioritizing essential data delivery.

• Add a timestamp extension #475
  There's no effective way to keep two subscriptions with identical priority in sync, which becomes problematic when one subscription experiences delays (such as during transcoding), potentially causing them to drift out of sync and impact the quality of experience, especially for low-latency use cases.

• Allow padding streams #534
  The author proposes allowing for at least padding unidirectional streams, which can then be used for probing.

• Track switching at the live edge using MOQT's current messages? #1101
  The issue raises concerns about how to achieve a smooth, gapless switch between two synchronized media tracks in MOQT, such as switching video quality (ABR) or audio languages, using the existing SUBSCRIBE and SUBSCRIBE_UPDATE methods, possibly with track priorities. The goal is to avoid both interruptions and duplicate delivery of the same content during the switch, particularly for live streaming. Previous attempts to address this issue with track priorities have led to conflicting approaches, highlighting ambiguities and limitations in the current protocol. The discussion aims to identify and address these shortcomings and initiate work on protocol improvements to enable reliable and seamless track switching.

What we have now:

As advocates of client-side ABR and server-assisted ABR techniques, we implemented the following:

• The first ABR demo that used client-side information, such as client bandwidth measured on the client side and some congestion signals, such as late-arriving MOQ groups.
• Bandwidth probing from the relay to assist the client in doing ABR.

We also proposed a solution to merge subscribe and unsubscribe operations and do an atomic track switch on the relay and published our results here (Stockholm interim slides). Our results showed advantages of letting the (edge) relay control the switching process.

We believe that a SWITCH message in MOQT is necessary to address the track switching problem properly and pave the way for developing robust ABR implementations.

This message ensures smooth transitions between alternative tracks, eliminating any gaps or overlaps in content download and transmission during the switch. It also handles cases where the groups/objects are not necessarily arriving at the relay at the same time.

A demo showing ABR with the current messages and parameters is available here. The same demo, featuring a SWITCH message, will be available soon.

[acbegen]

@gwendalsimon and @wilaw had also presented this in the interim last year.

[afrind]

Is this issue asking for a specific document change that is not already tracked by one of the linked issues, or the mailing list? Can we close it and move the discussion to one of them, or close one of them and keep the discussion here?

[acbegen]

Is this issue asking for a specific document change that is not already tracked by one of the linked issues, or the mailing list? Can we close it and move the discussion to one of them, or close one of them and keep the discussion here?

This is asking for a SWITCH message. I'd hope it was clear. The current toolset is not sufficient, that's the argument.

[acbegen]

Can we close it and move the discussion to one of them, or close one of them and keep the discussion here?

If @tobbee is OK, we can close #1101 and track the issue here.

[ianswett]

I re-read your draft (https://www.ietf.org/archive/id/draft-gurel-moq-track-switching-01.html) and if we're going to add something, I would prefer the 'altTrackGroup' approach that allows me to group more than 2 Subscriptions as alternatives to one another, since that enables a key aspect of Server/Sender Side ABR.

When there are only 2 Subscriptions in the Group, it would be equivalent to the SWITCH message I believe?

[yekuiwang]

WARP has the "altGroup" catalog field that indicates tracks that form an alternative group. I guess herein you want that information accessible by relays, and thus something more is needed?

[acbegen]

I re-read your draft (https://www.ietf.org/archive/id/draft-gurel-moq-track-switching-01.html) and if we're going to add something, I would prefer the 'altTrackGroup' approach that allows me to group more than 2 Subscriptions as alternatives to one another, since that enables a key aspect of Server/Sender Side ABR.

Yup.

When there are only 2 Subscriptions in the Group, it would be equivalent to the SWITCH message I believe?

Exactly. Since the subscriber would pick one track among that group at a time, this works.

[acbegen]

WARP has the "altGroup" catalog field that indicates tracks that form an alternative group. I guess herein you want that information accessible by relays, and thus something more is needed?

Yup, the relay needs to be told that info, as it would not understand the catalog.

[gwendalsimon]

Just to re-explain one of the key problems. It happens when a Subscriber is "far from live", i.e. at a given time the Subscriber is receiving an Object that the Relay received some time ago. Furthermore, the Relay has received one or more Objects since.

Example:
a Relay receives one new Group per second. It receives 28, 29, 30, 31...
a Subscriber is aligned with the Relay until group 28, and then it experiences some network troubles, its bandwidth is only half of the video bit-rate. It has a buffer of say 8 seconds of video, so it can survive. After 4 seconds of bad experience, the Subscriber observes buffer depletion and would like to switch. The Relay just received Group 32, while the Subscriber is receiving Group 30.

The subscribe/unsubscribe option does not work:
Subscribe to track B starts with Group 33 - 34 - ...
Unsubscribe track A 33 means that the the Subscriber must still receive Groups 31 and 32
It is awful: 1/ the switch operation generates an increase of the amount of data on the line, 2/ the switch happens too late,

So, no @ianswett I disagree with your claim that "Track switching in the future is quite good". I also disagree with "By sending the SUBSCRIBE+SUBSCRIBE_UPDATE at the same time with an explicit Group ID in the future, prioritization is easy". In my example, the Subscriber would send a Subscribe track B group 31, ... which would generate an error at the Relay. And no, prioritization is not easy. #1101 explained that we tried to find some way to address the problem with priorities but we did not find the way. Prioritizing track A during two whole groups will generate an accumulation of track groups at Relay and little chance to catch up for the Subscriber.

The solution that @wilaw and I have presented a long time ago is to Subscribe track B, get largest group, realize the gap, emit a joining FETCH at the next group, unsubscribe track A asap... but, as we mentioned at that time, it includes a number of pitfalls: 1/ it is overly complicated, 2/ it requires the Relay to be fast to get past objects (especially if was not previously subscribed to track B), 3/ it requires the Subscriber to guess the location ID in the future, 4/ it inevitably generates some objects in the line at the same time, with prioritization issues.

[kixelated]

Alternatively, what if the client was subscribed to a timeline track with the highest priority?

The player could them know how far behind the live broadcast it is and choose a concrete switch point (SUBSCRIBE_UPDATE + SUBSCRIBE). This approach would work with unaligned groups, unlike SWITCH. It would also be able to tell the difference between broadcaster congestion and viewer congestion: if the timeline stops making progress then switching down a rendition won't help.

A GROUP_END message (separate from the data streams) with the number of objects would accomplish something similar. It would also help the subscriber/relay know how much of the group was dropped (and may need a FETCH), because the current group FIN status is literally the first object that can be dropped.

[kixelated]

And I'm not saying that SWITCH is a bad idea, but it feels off that the player doesn't know the live playhead yet has still come to the conclusion that a SWITCH is necessary. Plus I really want to support unaligned groups.

[gwendalsimon]

Alternatively, what if the client was subscribed to a timeline track with the highest priority?

The player could them know how far behind the live broadcast it is and choose a concrete switch point (SUBSCRIBE_UPDATE + SUBSCRIBE). This approach would work with unaligned groups, unlike SWITCH. It would also be able to tell the difference between broadcaster congestion and viewer congestion: if the timeline stops making progress then switching down a rendition won't help.

It addresses one of the points (identifying gap between Relay's live and Subscriber's status). But it does not say whether the Relay has an ongoing subscription to the target Track, nor if the Relay cached the past objects of track B. If not to any of these questions, the Relay will take more time to get the requested Objects from the Publisher, and may generate other problems.

Note that this problem can be addressed by preemptively subscribe to track B with forward=0 (and "force" the Relay to cache some recent objects of this track). I would argue that 1/ sometimes bandwidth drops unexpectedly. In my example, the Subscriber was perfectly fine until Group=28, so no reason to warm up a second track; 2/ if every Subscriber requests both up and down tracks just in case of a possible switch in the future, it would be a bad design with respect to network consumption and Relay resource management.

And overall, forcing timeline subscription + extra-track warm-up + switch point choice management. It does not address the "overly complicated" point.

With a SWITCH message, the Subscriber offloads the switch responsibility to the Relay, who has a better view of the system. The Relay knows both Subscriber status (from the SWITCH message) and its own status. It knows what it has in cache; it knows track group alignment; it knows the size of the groups in both tracks.

[kixelated]

And overall, forcing timeline subscription + extra-track warm-up + switch point choice management. It does not address the "overly complicated" point.

Oh absolutely. I don't think warming the CDN is necessary, especially at this stage of the draft. At best is a minor optimization that should be backed by production experiments before entering an RFC.

Joining FETCH should absolutely be replaced with subscriptions that start at group boundaries. It's so gross writing a subscriber right now.

You're (probably) going to want the timeline track anyway for cross-rendition metadata.