[Hls-interest] Allow URI changes

Philipp <philipp+ietf@bureaucracy.de> Sat, 29 August 2020 19:53 UTC

Return-Path: <philipp@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 021C93A0FAB for <hls-interest@ietfa.amsl.com>; Sat, 29 Aug 2020 12:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 ClfE4nTsZjWA for <hls-interest@ietfa.amsl.com>; Sat, 29 Aug 2020 12:53:30 -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 03D563A0FAA for <hls-interest@ietf.org>; Sat, 29 Aug 2020 12:53:29 -0700 (PDT)
Received: from hell (localhost [::1]) by bureaucracy.bureaucracy.de (OpenSMTPD) with ESMTP id 3799a8c9 for <hls-interest@ietf.org>; Sat, 29 Aug 2020 21:53:25 +0200 (CEST)
Received: from localhost (hell [local]) by hell (OpenSMTPD) with ESMTPA id 23fa874d for <hls-interest@ietf.org>; Sat, 29 Aug 2020 19:53:25 +0000 (UTC)
From: Philipp <philipp+ietf@bureaucracy.de>
To: hls-interest@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18147.1598730805.1@localhost>
Date: Sat, 29 Aug 2020 21:53:25 +0200
Message-Id: <7c59d1234eb86e37@hell>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/plfSyPmoVyvgv6AkFWmMH5iQog0>
Subject: [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: Sat, 29 Aug 2020 19:57:58 -0000

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.

Philipp