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

[Phil Cluff <[e-mail]>]

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=
[e-mail]> 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,
>
> 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
> [e-mail].
>
>
>
>
> cheers,
>
> Roger Pantos
> Apple Inc.--
> Hls-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest
>


-- 
Phil Cluff | Product Lead | [phone] | [e-mail]