Subject: Re: [Hls-interest] Allow URI changes

From: Roger Pantos <[email-masked]>
Date: Tue, 01 Sep 2020 11:00:42 -0700

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? 

How many servers do you want to load-balance across? A few? Hundreds?

Do you want to load-balance between multiple CDNs?

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?

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://www.ietf.org/mailman/listinfo/hls-interest

---

From: Philipp <[email-masked]>
Date: Wed, 02 Sep 2020 02:56:48 +0200

Hello Roger,

[2020-09-01 11:00] Roger Pantos <rpantos=[email-masked]>
> 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.)
>

Balance among proxy caches, but calling it a CDN would be extreme. Just
some nginx with a caching reverse proxy config.

> 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.

> 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.

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
> > 
> > --

---

From: Roger Pantos <[email-masked]>
Date: Thu, 03 Sep 2020 13:56:01 -0700

> On Sep 1, 2020, at 5:56 PM, Philipp <[email-masked]> wrote:
> 
> Hello Roger,
> 

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.