Subject: [Hls-interest] 1.1b1 update to HLS Content Steering preliminary spec

From: Roger Pantos <[email-masked]>
Date: Fri, 05 Mar 2021 09:18:07 -0800

As discussed on hls-interest, we’ve updated the HLS Content Steering spec to address concerns with the first version. The 1.1 design is fully backward-compatible to older clients, and allows all pathways to carry the exact same Master Playlist,

The new approach has some limitations that I’d like to highlight:

(1) Only the front part of a URL can be replaced by a pathway switch. If you distribute content to multiple endpoints and rely on per-endpoint query parameters, filenames, URL fragments, etc. please let us know what you’re doing.

(2) The PATHWAY-ID is now optional so the Master Playlist can be identical across Pathways. If it is absent, the first steering manifest request will not indicate that client’s current pathway. 

Comments are welcome, either to hls-interest or directly to us at [email-masked].

cheers,

Roger Pantos
Apple Inc.

---

From: Phil Cluff <[email-masked]>
Date: Tue, 16 Mar 2021 14:23:41 +0000

Hey Roger,

Thanks for the update, while I like the stronger back-compatibility of this
approach, but I think the other limitations it introduces are significant.
Specifically, it would limit the ability for many in the industry
(including my current and previous employer) to use this approach with
modern multi-CDN setups when leveraging token authentication in query
parameters.

As you highlighted, with this approach, it's not possible to change the
suffix (query string) of the segment URLs. This means that if the two
delivery paths you're using are on two independent CDN vendors, and you're
using any form of query string based token auth, both CDNs have to use the
same query parameters and signing implementations. Unfortunately today,
it's effectively impossible to use a single signing method, and query
parameter names and values for tokens across all the major CDNs vendors.
While some vendors may have some level of customizability that may make 2
token auth approaches interchangeable, to achieve this in a wider market is
simply impossible.

Take the following two implementations for example:

AWS Cloudfront uses 3 query parameters, with no customizability: Expires,
Signature, and Key-Pair-Id -
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html

Akamai uses a single parameter, which you can control the name of (usually
"token") or alike -
https://learn.akamai.com/en-us/webhelp/object-delivery/object-delivery-implementation-guide/GUID-EB3329D1-C7C5-4F23-9B69-1B1FBFEBF436.html
 https://github.com/akamai/EdgeAuth-Token-Node

While you can in theory add both tokens to the URL, from a practical
standpoint this becomes really complicated as each signing method also has
to take into account the signing params of the other CDNs, and it becomes
very bloated as soon as you're using more than 2 token auth strategies.

If the aim of this work is to enable 2 disparate encoding paths through the
same CDN vendor, this approach works fine, but if it's to enable more
redundant multi-CDN behaviour, without sacrificing token auth, then we need
to be able to customise the query string on a per-pathway basis, using
something like the SUFFIX as discussed in the previous threads.

It's also worth mentioning that I think SUFFIX needs some design work
though, as it'd be important to add/replace/remove query parameters
selectively, rather than in bulk, as some query parameters may be critical
to functionality, and may vary segment-to-segment, but are unrelated to
authentication.

Thanks.

On Fri, Mar 5, 2021 at 5:18 PM Roger Pantos <rpantos=
[email-masked]> wrote:

> As discussed on hls-interest, we’ve updated the HLS Content Steering spec
> to address concerns with the first version. The 1.1 design is fully
> backward-compatible to older clients, and allows all pathways to carry the
> exact same Master Playlist,
>
> (1) Only the front part of a URL can be replaced by a pathway switch. If
> you distribute content to multiple endpoints and rely on per-endpoint query
> parameters, filenames, URL fragments, etc. please let us know what you’re
> doing.
>
> (2) The PATHWAY-ID is now optional so the Master Playlist can be identical
> across Pathways. If it is absent, the first steering manifest request will
> not indicate that client’s current pathway.
>
> Comments are welcome, either to hls-interest or directly to us at
> [email-masked].
>
>
>
>
> cheers,
>
> Roger Pantos
> Apple Inc.--
> Hls-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hls-interest
>

-- 
Phil Cluff | Product Lead | +44 7983 406 937 | [email-masked]

---

From: Roger Pantos <[email-masked]>
Date: Wed, 24 Mar 2021 10:43:43 -0700

Hi folks. An update to this:

> On Mar 5, 2021, at 9:18 AM, Roger Pantos via HLS-Announce <[email-masked]> wrote:
> 
> <HLS Content Steering Proposal v1.1b1.pdf>

Based on feedback we’ve received, we’re considering adding some syntax to the Steering Manifest to control query-parameter replacement. Specifically, we would add the following to the Template object (alongside PREFIX):

"QUERY-PARAMS": object		// OPTIONAL, HTTP query parameters map

The QUERY-PARAMS of a Template Replacement Values object, if present, defines a dictionary of Pathway-specific HTTP query parameters to be set on every URI that uses that template. Every key/value pair in the dictionary whose value is non-empty will be added to the URL as a query component of the form key=value, replacing any existing query component with the same key. Every key/value pair in the dictionary whose value is the empty string ""  will cause the query component with that key to be removed from the URI. Both keys and values MUST be appropriately percent-encoded. 

If a Steering Manifest contains a Pathway object for the PATHWAY-ID of the EXT-X-CONTENT-STEERING tag, any query parameters specified by QUERY-PARAMS dictionaries within that Pathway object MUST appear in all Master Playlist URIs that use the corresponding template(s).

This allows providers to supply per-pathway query parameters for applications like authorization tokens.

Note that this could end up being a Steering Manifest version 2 feature, depending on our development timeline.

Roger.