Don't exclude a @serviceLocation for a time-limited period equal to the last steering server TTL

[edouardbe]

Hi team,

Nice job so far on the content steering. I have a comment on the exclusion period of a serviceLocation. In many cases, it's irrelevant to call the steering server every x minutes. The basic use case is to have a fallback CDN if the primary CDN is failing, and expect the player to switch back to the primary CDN if the primary CDN is back. In this very simple scenario, it's necessary to call the steering server only once at startup to provide the primary and fallback CDN. Then, it's useless to request the steering server and get the exact same steering manifest every x minutes, especially if it's just to define the exclusion period of the serviceLocation. Either give a way to define the exclusion period independently from the steering TTL, or put a default value.

Apple does not align the exclusion period with the TTL. It's about 3 minutes, by test.

Regards
Ed
[email protected]

[wilaw]

Hi Ed - thanks for reviewing the spec.

The basic use case for content steering is not to introduce a fallback CDN. That is what BaseURL is for. If you simply want to have a fallback CDN, then introduce two baseURLs , one pointing at CDNA and the other at CDN B and don't add any ContentSteering element.

If you want to use ContentSteering none-the-less to enforce this type of simple fallback behavior, then you can do it by having a very high TTL in the steering server response, one that it higher than the expected playback duration of the content. Setting TTL to 31536000 (one year) for example, would effectively cause the client to only call the steering server once per playback session.

[edouardbe]

Hi Wilaw.

The issue with what you propose here "If you simply want to have a fallback CDN, then introduce two baseURLs , one pointing at CDNA and the other at CDN B and don't add any ContentSteering element" is that we loose the control on the CDN used to stream. What you describe will help to fallback to CDN B but it won't return to CDN A if CDN A i recovered. That's exactly why we did not implement this in HLS with duplication of the qualities per CDNs. We want to keep control.

The second option you propose with a high TTL is not working neither, as you mentioned the CDN A will be excluded during the TTL value. We want the CDN A to be used when recovered after some minutes, independently of the TTL value for the content steering manifest. That's why HLS is not using the TTL of the content steering manifest for the exclusion period. Those 2 aspects of the feature are independent.

Regards
Ed

[wilaw]

One question - the Apple exclusion period is not defined within the steering server response. Hence it seems to be an arbitrary interval set by each client. The Apple HLS spec is quite vague on this point. In section 7.4.4 it says "If the client decides that the Pathway has been penalized long enough that it may have recovered, it SHOULD un-penalize the Pathway and perform a Content Steering evaluation". How in the HLS ecosystem do they achieve deterministic behavior over a cohort of HLS players, when each player can define its own definition of what is "long enough"?

[edouardbe]

Hi @wilaw. You're right, Apple does that without letting us specifying the duration of the prnalization. By experimentation it's about 3 minutes. I don't need at this stage something more configurable, 3 minutes is ok. Then, up to the team to make something better for Dash then HLS.

Regards
Ed

[haudiobe]

We have published the spec: https://www.etsi.org/deliver/etsi_ts/103900_103999/103998/01.01.01_60/ts_103998v010101p.pdf

Please check of there is any remaining issue and if so, please provide a new issue. We will recheck and possibly add this update to the next release. Your feedback is welcome.

[haudiobe]

In 20-c we say: "it shall exclude that @serviceLocation for a time-limited period equal to the last steering server TTL that it received."

We are also interested on why decoupling TTL and penalty period is a specific use case.

We are happy to collect feedback if this requirement causes issues in practical deployments, If so please file a new issue that explains the problem. Thank you

[haudiobe]

Closing as no more comments received. File new issue if needed.