Subject: [Hls-interest] Another use case for future content steering support in HLS.

From: Ofer Shem Tov <[email-masked]>
Date: Sun, 6 Sep 2020 15:26:06 +0300

Hi,

We have another use case for allowing segment URI changes. We have a
'multi-cdn' feature that selects CDN based on many parameters such as
quality, price, etc. For VOD this is done before each session. For live we
can switch CDN in the middle of a session but we need to keep the old CDN
for the segments already sent to the player and provide URIs to the new CDN
only to new introduced segments. This makes the switch slower and also
depending on the window size, forcing us to keep a smaller window size.
Allowing to change URIs will improve the switching speed for us. We will be
happy to share more details.

Thanks

Ofer Shem Tov
Verizon Media
Media Platform

On Fri, Sep 4, 2020 at 10:01 PM <[email-masked]> wrote:

> Send Hls-interest mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Hls-interest digest..."
> Today's Topics:
>
>    1. Re: Allow URI changes (Roger Pantos)
>
>
>
> ---------- Forwarded message ----------
> From: Roger Pantos <[email-masked]>
> To: Philipp <[email-masked]>
> Cc: [email-masked]
> Bcc:
> Date: Thu, 03 Sep 2020 13:56:01 -0700
> Subject: Re: [Hls-interest] Allow URI changes
>
>
> > On Sep 1, 2020, at 5:56 PM, Philipp <[email-masked]> wrote:
> >
> > Hello Roger,
> >
> > [2020-09-01 11:00] Roger Pantos <rpantos=[email-masked]>
> >> Hello Philipp,
> >>
> >>> On Aug 29, 2020, at 12:53 PM, Philipp <[email-masked]>
> wrote:
> >>>
> >>> Hi
> >>>
> >>> I currently write a HLS Loadbalancer. The idea is to change the URI of
> >>> the Media Segments, to select which client should load the Media
> Segments
> >>> from which server. This might lead to change the URI of Media Segments
> >>> for two causes:
> >>>
> >>> 1. Policy changes
> >>> It might be necesarry change the server of a client during runtime of
> >>> the stream. Yes the server could track the last segment number he
> >>> deliverd to a client. This might lead to playback issues, depending on
> >>> the reason the policy changed. Also this directly leads to the secound
> >>> cause.
> >>>
> >>> 2. Lost of client tracking
> >>> There are some edge cases the server don't recognice the client. In
> this
> >>> case the server might give the client an other URI for the same Media
> >>> Segment.
> >>>
> >>> Unfortunately section 6.1.2 don't allow to change the URI of a Media
> >>> Segment and sections 6.3.4 say a client should halt playback if he
> >>> detects a changed URI.
> >>>
> >>> I propose for the next version of the standard, to allow the server to
> >>> change the URI and force the client to handle a changed URI in a sane
> >>> way. So the client must not reload already loaded segments and must not
> >>> stop loading already started downloads, but should use the new URI for
> >>> new or restarted downloads.
> >>
> >> Features like this (which we refer to as Content Steering) are
> something that we are interested in exploring for HLS. To help us
> >> understand your requirements, I have a few more questions for you.
> (Feel free to email me privately if you prefer.)
> >>
> >> Is the load balancer that you’re working on designed to balance among
> HTTP proxy caches (i.e. as part of a CDN), or in front of the origin?
> >
> > Balance among proxy caches, but calling it a CDN would be extreme. Just
> > some nginx with a caching reverse proxy config.
> >
> >> How many servers do you want to load-balance across? A few? Hundreds?
> >>
> >> Do you want to load-balance between multiple CDNs?
> >
> > We want to balance between a few proxies. The problem we have is that we
> > don't know if our uplink has the capacity for all users. But we have
> > some sponsors which can provide proxies for additional bandwidth. Also
> > we want a possibility to handle some network issues.
> >
> >> In your case (2), I’m not sure I understand the purpose of providing a
> different Media Segment URI for a client that the server does
> >> not recognize. Can you elaborate?
> >
> > It's not on purpose to change the URI, it's by accident. Also by
> > recognize a client I mean recognize a specific instance playing the
> > stream, not which software is used.
> >
> > Currently I use cookies to track a client. New clients get the next
> > proxy in the list of proxies which have capacity left. Also I set a
> > cookie containing the proxy. If a client provides this cookie he will
> > get the same proxy again. But some software has no cookie support (or
> > it's disabled). If a client don't provide his cookie, he is handled like
> > a new client and the URIs may change.
> >
> > I could add some tracking based on the IP and the port. This still don't
> > solve the problem, because a client may reconnect with a different port
> > or IP for several reasons.
>
> Okay, that all seems reasonable.
>
> I don’t think that we can allow unrestricted modification of
> already-published segment URLs without incurring a pretty big hit on
> existing client implementations. But this kind of setup seems to be well
> within the bounds of what we should consider for future content steering
> support in HLS.
>
>
> thanks,
>
> Roger.
>
> >
> > Philipp
> >
> >> HLS extensions aside, a fairly typical strategy is to put a Virtual IP
> (VIP) at the front end of your origin service (i.e. an L7 or
> >> L3 VIP inside the datacenter). This enables load balancing fairly
> independently of HTTP. On the wider network it’s pretty common to
> >> make use of some kind of DNS / GSLB, at least for the initial content
> direction.
> >>
> >>
> >> regards,
> >>
> >> Roger Pantos
> >> Apple Inc.
> >>
> >>>
> >>> Philipp
> >>>
> >>> --
> >>> Hls-interest mailing list
> >>> [email-masked]
> >>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
> >>
> >> --
> >> Hls-interest mailing list
> >> [email-masked]
> >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
> >
> > --
> > Hls-interest mailing list
> > [email-masked]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
>
>
> Hls-interest mailing list
> [email-masked]
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
>

-- 
<http://www.verizonmedia.com>

Ofer Shem Tov

Distinguished Software Dev Engineer
Media Platform

M +972548842664
2A Jabotinsky St.
Amot Atrium 36th Floor
Ramat Gan

<http://www.facebook.com/verizonmedia>   <http://twitter.com/verizonmedia>
<https://www.linkedin.com/company/verizon-media/>
<http://www.instagram.com/verizonmedia>