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

[Ori Finkelman <[e-mail]>]

Thanks Lucas and Thomas for your inputs.
Thomas, it's a good point, we will have to address the case of multiple
endpoints, we will address it in the next version once we get some inputs
from HTTPbis on the preferred direction.

All, my apologies for distributing by mail, we will submit on Monday
morning as soon as the submission tool is open.
Attached is a newer revision with minor typo fixes.

Thanks,
Ori






On Sat, Nov 3, 2018 at 3:33 PM Lucas Pardue <[e-mail]>
wrote:

> 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 <[e-mail]> 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: [phone] | Mobile: [phone] |
>> [e-mail]
>> --
>>
>> *Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
>> [e-mail]
>> --
>>
>> *Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
>> [e-mail]
>>
>

-- 

*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
[e-mail]