SWITCH for Client-side ABR

[gwendalsimon]

Fixes #1354 ... which addressed six previous issues.

Credits to @wilaw and @acbegen

[sharmafb]

If the new request id corresponds to an existing established subscription, isn't it possible that the relay may need to send a SUBSCRIBE_UPDATE in order to broaden the range of that subscription? This could happen if, for instance, the SWITCH statement has a SUBSCRIPTION_FILTER that is broader than any existing subscriptions being made to the relay.

[yekuiwang]

I think the answer is yes. It is also possible that the SWITCH has a SUBSCRIPTION_FILTER that is narrower, in which case an SUBSCRIBE_UPDATE is also needed (to narrow the range of that subscription).

[gwendalsimon]

Yes, the procedure here is the same as for a new received subscription, with aggregation of subscription. It is detailed here (Sec 8.4). We should change the wording to link to this section.

[sharmafb]

How would a relay identify that two tracks are "switchable" because they contain equivalent content?

[yekuiwang]

In my understanding the relay knows that from the SWITCH (without the SWITCH the relay does not know as relays don't have access to catalog payload information).

[sharmafb]

But what If I'm a user, and I request switch(track_a, track_b), where track_a and track_b don't use equivalent data, and aren't even synchronized in terms of group ids?

[yekuiwang]

But what If I'm a user, and I request switch(track_a, track_b), where track_a and track_b don't use equivalent data, and aren't even synchronized in terms of group ids?

Good point. There should probably be a constraint on the two tracks in a SWITCH, to disallow this.

[acbegen]

But what If I'm a user, and I request switch(track_a, track_b), where track_a and track_b don't use equivalent data, and aren't even synchronized in terms of group ids?

It is the subscriber's responsibility to know that these two tracks are switchable (for example, as part of a CMAF switching set). Being a CMAF switching set, it has sufficient requirements to ensure a seamless switch. If you are not aiming for such a seamless switch, then just use sub/unsub.

[acbegen]

But what If I'm a user, and I request switch(track_a, track_b), where track_a and track_b don't use equivalent data, and aren't even synchronized in terms of group ids?

Good point. There should probably be a constraint on the two tracks in a SWITCH, to disallow this.

The relay does not need to check whether these two tracks are actually "switchable." The group IDs may not be aligned for different reasons and if the relay cannot complete the switch, it will return an error anyway. So, I don't think there is a need for a "disallow" check.

[gwendalsimon]

But what If I'm a user, and I request switch(track_a, track_b), where track_a and track_b don't use equivalent data, and aren't even synchronized in terms of group ids?

Good point. There should probably be a constraint on the two tracks in a SWITCH, to disallow this.

The relay does not need to check whether these two tracks are actually "switchable." The group IDs may not be aligned for different reasons and if the relay cannot complete the switch, it will return an error anyway. So, I don't think there is a need for a "disallow" check.

Indeed, we can add some wording to say that if the Relay fails to identify a next common boundary group between the two tracks, it can return an Error. Note that this could be leveraged by those who do not want to implement SWITCH to just reply negatively to any SWITCH message, even if these tracks are switchable.

[tobbee]

Since we later say the mechanism achieves a continuous sequence of groups, I think we should spell out that tracks with equivalent content need to have aligned group IDs.

[tobbee]

Great to get a PR for adding an atomic SWITCH statement. I think it is really needed.

Switching at the same Group ID should be enough to get a HLS/DASH-similar segment-based ABR switch.

[tobbee]

Since we later say the mechanism achieves a continuous sequence of groups, I think we should spell out that tracks with equivalent content need to have aligned group IDs.

[tobbee]

I think it is implicit here that the new track is assumed to have forward state =0, and that it will change to forward=1 at the switch point, without a forward=1 flag sent in the subscribe message. It may be worth pointing out this detail.

For the old track, it is desribed later on that that forward will be set to 0.

[ianswett]

I would prefer a mechanism that supports at least simple server-side ABR as well as client-side ABR, and I think that's possible without much extra work.

[wilaw]

I would prefer a mechanism that supports at least simple server-side ABR as well as client-side ABR, and I think that's possible without much extra work.

I do not think that is a good approach. I support server-side switching, but it has some fundament differences with what is being proposed here. Mixing the two behaviors into the same message is going to complicate switching. Current SWITCH is executed once and requires only two inputs - the track you switch from and track you switch to. A server-side switch would have to be persistent and it requires threshold values at which the switches should be made.

Server-side switching has many similarities to a persistent, conditional filter - it lets one track through at a time based on the estimated throughput. And we already have a proposal to filter TOP N tracks. It is persistent. If we extended the FILTER proposal to allow switching based on estimated-throughput (in addition to the current extension header) and we set N to 1, then we would have server-side ABR. That seems architecturally a cleaner approach to implementing server-side switching with MOQT than overloading a message designed to implement clean client-side switching.

[suhasHere]

If i recall from a few ietf meetings on this topic, Absolute Joining Fetch was added to support this exact functionality . I am specifically referring to this slide here:

https://docs.google.com/presentation/d/1YPLTpHjrJpNUtjvw58fAvE2NhiWHjuptDwTcjaRvVcI/edit?slide=id.g331a8043eb5_0_156#slide=id.g331a8043eb5_0_156

As per consensus call, we decided to add Absolute Joining Fetch. May be this is already discussed, is there a reason that will still not work or are we advocating that absolute joining fetch needs to be removed ?

[gwendalsimon]

If i recall from a few ietf meetings on this topic, Absolute Joining Fetch was added to support this exact functionality . I am specifically referring to this slide here:

https://docs.google.com/presentation/d/1YPLTpHjrJpNUtjvw58fAvE2NhiWHjuptDwTcjaRvVcI/edit?slide=id.g331a8043eb5_0_156#slide=id.g331a8043eb5_0_156

As per consensus call, we decided to add Absolute Joining Fetch. May be this is already discussed, is there a reason that will still not work or are we advocating that absolute joining fetch needs to be removed ?

You are right, we introduced Absolute Joining FETCH to implement a switch at the next transition group for subscribers who are behind the live stream. We note however:

• The whole process is circumvoluted (slide 11) For a simple SWITCH, it requires the subscriber to send 4 messages, with risk at every step
• At some point of the switch, the link between relay to subscriber has 3 ongoing data flows (the subscribe of old track, the subscribe of new track, and the fetch). It is very bad especially for those who switch due to network congestion. At the time we presented this solution, it was said that priorities can handle this concurrency of flows but Track switching at the live edge using MOQT's current messages? #1101 showed that, in practice, it is not possible
• The Subscriber does not know the status at the Relay, in particular it does not know whether the Absolute Joining FETCH is about Objects that are cached at the Relay or not. In practice, it happens that the Subscriber asks for Absolute Joining FETCH at the next group (which is not gap-friendly btw) and the Relay takes too much time to get it, or cannot get it at all.

Overall this solution UNSUBSCRIBE+SUBSCRIBE+Absolute Joining FETCH+SUBSCRIBE_UPDATE is overly complicated for a single operation and not efficient in practice.