Re: [Hls-interest] Streaming Video Alliance Comments on HLS Content Steering Proposals

[Kevin Staunton-Lambert <[e-mail]>]

Presumably if D for whatever reason becomes the active pathway what happens if the original preferred pathway A then comes good again? 

Maybe you can force D to fail - and so the group resets to A (or the RSS preferred), but a dynamic mechanism where the RSS is re-requested would be better because causing D to fail is somewhat risky 

I was thinking instead of complexity around adding support for RSS perhaps the master manifest could itself just be made dynamic by flagging to re-request master playlist when MSN>=X and expire (i.e switch over) when MSN==Y

This mechanism should simplify SSAI solutions too where effectively the player resets at a given MSN (introducing a concept of a full discontinuity where the codec and bitrate could safely change at that splice)

Kev

>> On 13 Apr 2021, at 6:44 am, Law, Will <[e-mail]> wrote:
>> 
> 
> Hi Roger
>  
> Re “. The biggest casualty of that approach is the ability to add new pathways during playback.”
>  
> Content distributors cannot add new CDNs on a whim. At a minimum there are contracts to be signed, keys and signing-secrets to be shared and QA tests to be performed. This implies that the universe of possible CDNs is known before an event and before the main playlist is generated. What is a practical requirement however is that a distributor may not want to use all their available CDNs all the time and may want the flexibility to change the mixture and prioritization midway through an event. This I believe can be accommodated with RSS.
>  
> Imagine a distributor has 4 pathways they can use, A,B, C and D. D is very expensive and they prefer not to use them at all, unless they absolutely have to when the other 3 pathways are all failing to perform. The main playlist could be generated with the redundant variants (A ..D) listed in order. The steering manifest would only return A,B,C at the start of the event. There would be no traffic on D since that pathway is not advertised by the steering server. If at some midpoint due to performance or economic reasons they wished to shift all the traffic to D, they could so by instructing the steering response to now only return an option for D. All steering-aware clients would shift to D. This is the same effect as adding a new pathway, the only nuance being that the pathway had to be described in the main playlist even if it is never used.
>  
> The above behavior assumes steering-aware clients. Legacy clients (steering un-aware) would see the redundant offerings and would select the first available. By listing D last, the distributor would ensure that legacy traffic only reached D if A,B,C had all failed and that is probably the desirable outcome under those conditions.
>  
> Cheers
> Will
>  
>  
>  
>  
>  
> From: Roger Pantos <rpantos=[e-mail]>
> Date: Monday, April 12, 2021 at 11:43 AM
> To: Jason Thibeault <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [Hls-interest] Streaming Video Alliance Comments on HLS Content Steering Proposals
>  
>  
> 
> 
> On Apr 7, 2021, at 9:21 PM, Jason Thibeault <[e-mail]> wrote:
>  
> Streaming Video Alliance (SVA) Comments on HLS Steering Proposal
> 
> The Streaming Video Alliance is a group of companies spanning the streaming video value chain. These companies are dedicated to solving the critical challenges facing online video to improve consumer adoption. Alliance members have reviewed the HLS Content Steering Proposal 1.1b1 and the subsequent Redundant Stream Steering Proposal (RSS) and provided comments on both from the perspectives of our diverse membership (content providers, CDNs, ISPs, open caching networks, multi-CDN management systems, encoding systems, advertising insertion systems, video analytics systems, and video player developers).
>  
> Hello Jason (and everyone else in SVA), glad to have you in the discussion.
>  
> You’ve raised some interesting issues. On the one hand, I think that most could be addressed by the current scheme — per-CDN query parameters could be communicated from the master playlist to the steering server via the content-steering URI, new URI replacement rules could be introduced to allow sub-path customization, etc.
>  
> On the other hand, there is simplicity to simply tagging redundant variants with a pathway ID that is appealing. The biggest casualty of that approach is the ability to add new pathways during playback.
>  
> We’ve got some discussions going on internally. I expect to come back with a more concrete response shortly.
>  
>  
> Roger.
> 
> 
> 
> ---- SEPARATION OF CONCERNS ----
> * It is typical in multi-CDN deployments for different entities to provide distinct parts of the solution. Manifests may be generated and manipulated by multiple provider’s services, media segments may come from other provider’s service, and CDN recommendation intelligence may come from yet another service.
> 
> * The HLS Content Steering Proposal blurs the clean delineation of responsibilities across these services, putting responsibility on the Steering Service to generate CDN-specific path prefixes (and possibly tokens).  A cleaner separation of concerns could be achieved by limiting the steering service’s scope of responsibility strictly to recommending pathways in a preferred order (as described in the Redundant Stream Steering Proposal).
> CDN-Specific Tokens
> 
> * Our most significant concern was initially about the inability to have CDN-specific suffixes on the steering templates, precluding the real-world situations where different tokenization schemes are used by different CDNs.
> 
> * While the addition of QUERY-PARAMS appears to address this problem when tokens are expressed as query parameters, it still requires that the steering server generates CDN tokens (see above: Separation of Concerns) and it doesn’t address tokens that may be inserted anywhere in the path as path parameters or segments.
> 
> ---- IMPACT ON OPEN CACHING REQUEST ROUTING & EXISTING MULTI_CDN SOLUTIONS ----
> 
> * Open Caching Request Routing schemes (relying on several IETF’s CDNI RFCs) can be configured to inspect and rewrite either main or media manifests to direct traffic to downstream CDNs.
> 
>    - The HLS Content Steering Proposal may preclude the rewriting of media manifest URLs in the main manifest, as the steering server also has responsibility for generating media manifest URLs.
>    - The HLS Content Steering Proposal adds complexity to request routing based on HTTP redirect, as envisaged in IETF CDNI and SVA. It may, for example, require steering server requests to be redirected to an open caching controller for rewriting of URL prefixes.
>    - To better support Open Caching redirect routing, the PREFIX attribute in the steering manifest should be optional. For example, If the current non-penalized pathway is the first in the list for which there is no PREFIX attribute, the client would form the URL of variant streams attached to the corresponding template in the conventional manner  (e.g. using the relative URI).
> 
> * It should be noted that some multi-CDN solutions use DNS on media segment hostnames to implement mid-stream CDN switching that is transparent to the player. The HLS Content Steering Proposal’s focus on alternate manifests will not break these types of solutions, but integration with such solutions could be challenging.
> 
> * Compatibility can be maintained with client-side multi-CDN management systems if HLS Video players allow client application override of the steering server pathway recommendation (see Player Behavior section below).
>  
> ---- SERVER-SIDE AD INSERTIONS ----
> 
> * SSAI systems typically generate ad loads at the time of the main manifest request and persist session identifiers that need to be passed to media manifests so that identical ad loads can be stitched into each rendition. The addition of QUERY-PARAMS should be sufficient for allowing session IDs to be passed on media manifest URLs.
> 
> ---- PLAYER BEHAVIOR ----
> 
> In reviewing the HLS Content Steering Proposal, the SVA suggests the following additions to the Player Behavior section:
> 
> * HLS Video Players should generate events whenever a pathway is selected, exposing the PATHWAY-ID so that Video QoS systems can log CDN changes.
> 
> * HLS Video Players should generate events whenever requests are made to the steering server, enabling Video QoS systems to log details from the steering manifest such as TTL and Pathways on successful requests, and error information on failed requests.
> 
> * For compatibility with existing client-side multi-CDN management systems, HLS Video Players should expose an API that allows access to the existing Pathway list and to force a pathway change (overriding the server-directed steering).
> 
> --------------------------------------------------------------------
> 
> SVA SUPPORT FOR THE HLS REDUNDANT STREAM STEERING PROPOSAL (RSS)
> 
> The SVA supports the Redundant Stream Steering Proposal for the following reasons:
> 
> * RSS embraces and extends redundant playlists (the existing HLS approach for supporting multiple CDNs), and is backward compatible with any player that supports redundant playlists.
> 
> * RSS provides a cleaner separation of concerns and simplifies the responsibilities of the Steering Service, as it no longer participates in generation of manifest URLs or tokens.
>  
> * RSS simplifies the HLS Stream Steering scheme by eliminating the steering templates, prefixes, query parameters, and any code complexity associated with supporting the template substitution.
> 
> * RSS avoids the token-generation challenges that have been identified, as token generation for media manifest URLs remains in the main manifest.
>  
> -------------------------------------------------------------------
>  
> This document can also be found on the Streaming Video Alliance website at https://www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/
>  
> ----------
> 
> Jason Thibeault
> Executive Director
> Streaming Video Alliance
> [phone]
> https://www.streamingvideoalliance.org
> Contributing Editor, Streaming Media Magazine
> https://www.linkedin.com/in/thejasonthibeault
> -- 
> Hls-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest
> 
>