Re: [Hls-interest] Allow URI changes

[Roger Pantos <[e-mail]>]

Hello Philipp,

> On Aug 29, 2020, at 12:53 PM, Philipp <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest