Content steering mechanism for DASH compatible with HLS RSS

[wilaw]

MPEG DASH provides multiple baseURLs, which specify alternate sources for content. However the priority with which these are used varies between player implementations. DVB defines additional weights and priorities. BaseURL switching always occurs in response to a delivery problem. Many content distributors use multiple CDNs to deliver their content and There is currently no means to deterministically steer (or switch) a cohort of players to a particular CDN during playback. THis would be a very useful addition to DASH. HLS has just defined a mechanism for steering content via a remote steering server. Since many distributors need to steer both DASH and HLS content, the most efficient solution would be to be able to steer both DASH and HLS playback from the same steering server. This issues defines such a solution.

To support content steering with DASH, we require one new element and extend an existing element. In the mpd snippet below we note that each baseURL element has a new optional attribute called "pathway-ID". We also note the new mpd@Content-Steering element. His has two attributes - a uri and a default-pathway-ID.

<MPD ...>
         <Content-Steering uri="https://akastreamgen.eastus.cloudapp.azure.com/v8/rss/steering" default-pathway-ID="B"/>
    <BaseURL pathway-ID="A">https://content-source.cdn-one.com/path/to/your/content/</BaseURL>
    <BaseURL pathway-ID="B">https://content-source.cdn-two.com/path/to/your/content/</BaseURL>
    <BaseURL pathway-ID="C">https://content-source.cdn-three.com/path/to/your/content/</BaseURL>
    <Period>...</Period>
</MPD>

Steering server response

{
 "VERSION": 1,
 "TTL": 10,
 "RELOAD-URI": "https://akastreamgen.eastus.cloudapp.azure.com/v8/rss/steering",
 "PATHWAY-PRIORITY": [
  "A",
  "B"
 ]
}

Workflow

1. Player loads manifest and notices the element. It parses out the URI and default pathway ID.
2. Player uses the default pathway ID to select the baseURl that it will use to start playback.
3. Once the player has established a target, stable buffer, it performs a side-load of the content-steering URI.
4. From the steering server response it parses the TTL, reload-URI and pathway-priority list.
5. If the highest item in the pathway-priority list is not the pathway that it is currently using, then it switches over to loading the next media segments from that baseURL. Note that it preserves whatever buffer it may have at the switch point and only loads new content from the nely assigned pathway.
6. After the interval defined by the TTL value, it refreshes the steering information by loading the reload-URI specified in the last steering response.
7. Note that the loading of the steering response occurs at a cadence decoupled from the manifest updates.
8. The reload-URI specified in the last successful steering server response has priority over any content-steering@uri attribute that may be retrieved from a manifest update. Stated differently, the player need only parse the element on the very first manifest load. After that point, it follows the directions of the steering server.

There are edge cases to be considered that are not addressed specifically in this issue:

1. Steering server is non-responsive
2. Min and max TTLs to prevent thrash
3. Complications of switching across DRM protected content
4. What should the player do if it encounters delivery problems with the assigned pathway? Is it still free to utilize another baseURL?

[wilaw]

Reviewed during Live TF call.

• Presence of pathway attribute indicates that this BaseURL is steerable.
• Comment that URI of BaseURL could function as a label in the steering server, so pathway-ID attribute is not needed.

  {
  "VERSION": 1,
  "TTL": 10,
  "RELOAD-URI": "https://akastreamgen.eastus.cloudapp.azure.com/v8/rss/steering",
  "PATHWAY-PRIORITY": [
  "https://content-source.cdn-one.com/path/to/your/content/",
  "https://content-source.cdn-two.com/path/to/your/content/"
  ]
  }

• Apple reason for not doing this was complications of URL templating.

[haudiobe]

@wilaw please provide a reference to the draft RFC on the steering protocol. Question is whether this protocol is sufficient to address also DASH. A protocol that permits steering of DASH and HLS clients to different CDNs.

@wilaw ask on apple list:

• where to publish
• can it be generic enough to be used for DASH/CMAF content as well

[wilaw]

@haudiobe - today Apple just updated and expanded their IETF spec at https://www.ietf.org/archive/id/draft-pantos-hls-rfc8216bis-10.txt to include the formal definition for Content Steering (see Section 7).

The only issue I can see with the suggestion to use the pathway ID as the baseURL in DASH. The pathway-ID is defined as " A Pathway ID is a non-empty string containing characters from the set [a..z], [A..Z],[0..9], '.', '-', and ''._". This character restriction would not allow an absolute baseURL to be specified, since :// is not allowed.

[haudiobe]

Discussion 2021/11/19 Solution

• add content steering signal to MPD
• connect BaseURL to content steering protocol
• Options
  • add pathway-id or just an id, but needs to be restricted to the character space of above.
  • convert base-url to pathway-id

Proposed way forward on spec:

• Use MPEG DASH attribute @serviceLocation => @haudiobe check where introduced and used.
• Write a Content Steering protocol extension for MPD => DASH-IF can address this @wilaw

<BaseURL serviceLocation="blue">http://example1.com/a</BaseUrl>
<BaseURL serviceLocation="blue">http://example1.com/b</BaseUrl>
<BaseURL serviceLocation="green">http://example2.com</BaseUrl>

<ContentSteering defaultServiceLocation="blue" queryBeforeStart="true">http://come-to-me-for-steering.com</>

JSON Response reference to HLS spec

 {
   "VERSION": 1,
   "TTL": 300,
   "RELOAD-URI": "http://come-to-me-for-steering.com?video=00012&session=123",
   "PATHWAY-PRIORITY": [
     "blue",
     "green"
   ]
 }

On implementation and interop

• Create an MPD with the element included
• maybe add to live-sim to create steering responses for test
• add to dash.js

[wilaw]

I did write to the IETF HLS Interest group on Nov 19th about the willingness to extend the allowed character set for pathway-ID to include the use of URLs. Apple replied that there were many other characters that would be needed for full URL support, that this extension would break existing clients and that it seemed like DASH IF had a work-around (via ServiceLocation). I agreed and rescinded the request for the additional character support. We can make it work using ServiceLocation.

[haudiobe]

From @wilaw Here is a my proposal for a Content Steering extension to DASH that is compatible with the content steering server response currently defined by HLS. This will allow the interoperable steering of DASH and HLS content by a single steering service, which should reduce the steering complexity for multi-format distributors.

[nicoweilelemental]

Good starting point!

Should we say that the player needs to issue a forced call to the steering server when the stream is playing and the buffer level drops down to 50% of the target buffer? In this situation, using a different baseURL could help.

Could we avoid to hardcode the ContentSteering URL token value (token=2345234525) inside the manifest, and instead get this value from a query string added to the MPD url, with a UrlQueryInfo element? We'd like to avoid customizing manifests for each end user just for the sake of inserting this token inline, which is not scalable.

On the same line, that would be great to have variable support to construct the BaseURL values, in order to for example insert SSAI sessionID as a sub-path of the BaseURL value. I know UrlQueryInfo is not very flexible in terms of you can insert the query string arguments in the manifest, but I think Alex Giladi wanted to look at this problem at the MPEG level, and try to bring more flexibility here.

[sunnyoui]

Good starting point!

Should we say that the player needs to issue a forced call to the steering server when the stream is playing and the buffer level drops down to 50% of the target buffer? In this situation, using a different baseURL could help.

Could we avoid to hardcode the ContentSteering URL token value (token=2345234525) inside the manifest, and instead get this value from a query string added to the MPD url, with a UrlQueryInfo element? We'd like to avoid customizing manifests for each end user just for the sake of inserting this token inline, which is not scalable.

Triggering request without cadence can potentially create an anti-pattern for steering server but requires further discussion.

[technogeek00]

[haudiobe]

TF Meeting Conclusions:

We are agreeing that

• the DASH players job is to use the priority order of the pathway. But the client can pull away if it runs into issues. If the client pulls away, it needs to revalidate with the Content Steering server. May also be good to report back to what extent the client adheres to the rules. May need combination with CMCD.
• The client must never chose pathways that are not in the response and must use pathways in the priority order as they are returned.
• we add rough guidance how long a high priority is black listed. Should be connected to the steering server TTL
• Content Steering is added to URL Query Element list. We need to find a way to not have a hard coded list. It needs to be extensible, in particular also to external.