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

Ofer Shem Tov <ost@verizonmedia.com> Sun, 06 September 2020 12:26 UTC

Return-Path: <ost@verizonmedia.com>
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 A11F63A0D92 for <hls-interest@ietfa.amsl.com>; Sun, 6 Sep 2020 05:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizonmedia.com
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 A2X253qAh9wU for <hls-interest@ietfa.amsl.com>; Sun, 6 Sep 2020 05:26:20 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A083A0D95 for <hls-interest@ietf.org>; Sun, 6 Sep 2020 05:26:19 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id r9so11458418ioa.2 for <hls-interest@ietf.org>; Sun, 06 Sep 2020 05:26:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizonmedia.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RYfwP/C23JiFMnpzHFfj68SDMI0Gd0uc5AcMHpURF8Y=; b=TaclO7EdgoX4yA5XZec3c6voIWkLg8Q0ARnbjAGs/LkxiOzJmjj62nuCZWgMbJnJtv rHFj0tKUBamW05prsoxMKTAaiJvfoh1D37vv2nNY/LyhfsIPdQFFaLcwyZR50UFUgYY1 tbEsrcRzQ+P5rgq1PobjETbTYjLyejMrOpKd80WCBLGdI/4QTaQcBUg+e+y9jOn+f4dt K92yswGDneTM+3rb8UBLC37+gba1LjZZqOv2Z5XzZMJPbabmhqYY0ToOLH7ca4EVx3gY wN0XIk424KqyKp29GuJgT7fL8L9XQNNHWV4oPT22Fl+q++guFuYshC1zsawBQ7qb/Ngv 4rJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RYfwP/C23JiFMnpzHFfj68SDMI0Gd0uc5AcMHpURF8Y=; b=Hi5oCAAgu1xRtCrFocY0cI3or7/mOcEWI8bt8hWueO2An6cBUEBCrWQSIeu7AB5SoY UQy+u3rjB3h8Te+OP2DX25/lDlfHKWX8tpekSPw5WZTas9XI4jt54YCtVLMjmvl9Mwu0 dDJMpKuA6CuCZOGTYM7pJXo7yXXY1FeyKIGhaRikE53Ck2seu11kwTqS+nvORXiS+DEx CiLB4vme9IH6HfGStezYTLdILgMpU5qoSk+E/MSPGKd6Vr3P/sUqUagQJeoDo0gSBYKm 8iehBKpmGjlnntMIA7p7+AApIzK2t+27y3/79ju0lV+o5y/Ab11DqEcqmujmGw2wbbg9 Us4g==
X-Gm-Message-State: AOAM530glRWeBiPiftFf3/zZ7KtKOkEfRk2YplHb9+tr2L1c+PkoAD+2 opH0wdMxIb+F1Z5KSl2bqWNsHDADzQeG5mppESqdHk0CqTBTmg==
X-Google-Smtp-Source: ABdhPJycUvv3iljr6IkqOHPd56tXUGOVzv1L0VRXt9HSivO1cpjBnoa3LyOnqI3oFt6Aw3W8XTgfls/fUH7eRRAL81U=
X-Received: by 2002:a05:6602:25c9:: with SMTP id d9mr13943287iop.150.1599395178427; Sun, 06 Sep 2020 05:26:18 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.66.1599246009.15014.hls-interest@ietf.org>
In-Reply-To: <mailman.66.1599246009.15014.hls-interest@ietf.org>
From: Ofer Shem Tov <ost@verizonmedia.com>
Date: Sun, 06 Sep 2020 15:26:06 +0300
Message-ID: <CAHEE8LrgU5J3C9XrhKNEz04TdMJmH78LcY3DVq8HYTWsgQcn9g@mail.gmail.com>
To: hls-interest@ietf.org
Content-Type: multipart/alternative; boundary="000000000000776a1505aea435b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/UeHWxSf-w08lu6-8ph1Z7AIZjRE>
Subject: [Hls-interest] Another use case for future content steering support in HLS.
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: Sun, 06 Sep 2020 12:26:23 -0000

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 <hls-interest-request@ietf.org> wrote:

> Send Hls-interest mailing list submissions to
>         hls-interest@ietf.org
>
> 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
>         hls-interest-request@ietf.org
>
> You can reach the person managing the list at
>         hls-interest-owner@ietf.org
>
> 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 <rpantos@apple.com>
> To: Philipp <philipp+ietf@bureaucracy.de>
> Cc: hls-interest@ietf.org
> 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 <philipp+ietf@bureaucracy.de> wrote:
> >
> > 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.
>
> 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
> >>> Hls-interest@ietf.org
> >>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
> >>
> >> --
> >> Hls-interest mailing list
> >> Hls-interest@ietf.org
> >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
> >
> > --
> > Hls-interest mailing list
> > Hls-interest@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!Op6eflyXZCqGR5I!SAbV4MTNXKZUbr0p-gwkvMTH-9ysnWAqcqGsni5Gk5ix3fE_bksKVDsV5GeKlsER$
>
>
> Hls-interest mailing list
> Hls-interest@ietf.org
>
> 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>