Re: HTTP redirect for HTTP Adaptive Streaming (HAS) in CDN use cases

Ori,

Thanks for sharing this, and the authors for writing this up. What's
captured in the document broadly matches my experiences in this space.

The problems can be real. A broker server, dimensioned to handle a low rate
of playlist requests, may end up getting overwhelmed with client media
requests. This is hard to predict because client implementations are
diverse; new things come along, and existing ones may regress. I am aware
of non-IETF efforts that attempt to characterise client behaviour like
this, and it wouldn't surprise me if the effort is duplicated across
different content or service providers.

I support discussion that can address this issue but have no strong opinion
on the final solution at this time.

Lucas

On Sat, Nov 3, 2018 at 1:13 PM Ori Finkelman <orif@qwilt.com> wrote:

>
> [Resending as I have sent to the wrong list]
>
>
> Hello ,
>
> HTTP redirect, usually using 302 Found, is widely used in video CDN for
> HTTP Adaptive Streaming (HAS) protocols, specifically for HLS and DASH.
> Using HTTP redirect instead of the more commonly used delegation by CNAME
> is a much more powerful and flexible solution.
>
> At a high level, the required behavior is that after getting an HTTP
> redirect to a playlist address that takes the client to a CDN cache, if the
> playlist contains
> relative references to the media segments, the client should be "sticky"
> and request the subsequent media segments directly from the cache without
> the need
> for repeated redirects that would add undesired latency and harm QoE.
> However, due to misinterpretations of the RFC in some cases, and
> contradiction between this requirement and the existing RFC in other cases,
> we face many
> issues with clients that behave differently in the case of HTTP redirect,
> when relative references are being used.
> A discussion of this use case can also be found in section 2.2.1 of
> RFC6983 <https://tools.ietf.org/html/rfc6983#section-2.2.1>.
>
> The Streaming Video Alliance (SVA) and DASH Industry Forum (DASH-IF) are
> attempting to resolve these issues and create clear guidelines describing
> how video players,
> browsers and streaming applications should behave in such HTTP redirect
> cases.
>
> The attached I-D includes a detailed description of this issue, examples
> with our understanding of the current behavior and proposals for
> alternative approaches for solution.
> We were hoping that the members of HTTPBIS working group could share their
> views regarding the preferred  approach in order to resolve this issue.
>
> If there is interest and some available time I can prepare a quick slide
> deck for the httpbis meetings next week.
>
>
> Best regards,
> Ori
>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> orif@qwilt.com
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> orif@qwilt.com
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> orif@qwilt.com
>