Re: [Hls-interest] Allow URI changes

Philipp <philipp+ietf@bureaucracy.de> Wed, 02 September 2020 00:56 UTC

Return-Path: <philipp+ietf@bureaucracy.de>
X-Original-To: hls-interest@ietfa.amsl.com
Delivered-To: hls-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD063A08E5 for <hls-interest@ietfa.amsl.com>; Tue, 1 Sep 2020 17:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiffKJSdVjZL for <hls-interest@ietfa.amsl.com>; Tue, 1 Sep 2020 17:56:54 -0700 (PDT)
Received: from bureaucracy.bureaucracy.de (bureaucracy.bureaucracy.de [IPv6:2a02:180:1:1::517:b8d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6D83A08EC for <hls-interest@ietf.org>; Tue, 1 Sep 2020 17:56:52 -0700 (PDT)
Received: from localhost (localhost [::1]) by bureaucracy.bureaucracy.de (OpenSMTPD) with ESMTP id b13ced8b for <hls-interest@ietf.org>; Wed, 2 Sep 2020 02:56:48 +0200 (CEST)
Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id e89dc9af for <hls-interest@ietf.org>; Wed, 2 Sep 2020 00:56:48 +0000 (UTC)
From: Philipp <philipp+ietf@bureaucracy.de>
To: hls-interest@ietf.org
In-reply-to: <9158AE94-63C1-4A68-BDB7-B0E212661097@apple.com>
References: <7c59d1234eb86e37@hell> <9158AE94-63C1-4A68-BDB7-B0E212661097@apple.com>
Comments: In-reply-to Roger Pantos <rpantos=40apple.com@dmarc.ietf.org> message dated "Tue, 01 Sep 2020 11:00:42 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <29812.1599008208.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 02 Sep 2020 02:56:48 +0200
Message-Id: <fb7f9fd0753bcaeb@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/RfZiiojIdPKgLp2_hizcj6leSS8>
Subject: Re: [Hls-interest] Allow URI changes
X-BeenThere: hls-interest@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions about HTTP Live Streaming \(HLS\)." <hls-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hls-interest/>
List-Post: <mailto:hls-interest@ietf.org>
List-Help: <mailto:hls-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2020 00:56:56 -0000

Hello Roger,

[2020-09-01 11:00] Roger Pantos <rpantos=40apple.com@dmarc.ietf.org>
> Hello Philipp,
>
> > On Aug 29, 2020, at 12:53 PM, Philipp <philipp+ietf@bureaucracy.de> 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.

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
> > Hls-interest@ietf.org
> > https://www.ietf.org/mailman/listinfo/hls-interest
>
> -- 
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest