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

[Ori Finkelman <[e-mail]>]

Hi Patrick,
Thanks for the feedback.
Alt-Svc  can serve as a good solution instead of redirect.
Nevertheless, for those applications that do use HTTP redirect, I tend to
think that a clear guidance on the relative reference resolution would be
in place, and the more advanced behavior like failover can be specified as
best practices instead of a standard.

Thanks,
Ori

On Sun, Nov 4, 2018 at 5:35 AM Patrick McManus <[e-mail]> wrote:

> Hi Ori,
>
> As Chair:
> Thanks for the draft and the note.. please submit any/all drafts to the
> datatracker as soon as it reopens (which I believe is Monday morning).
>
> As far as I understand your topic, your primary concern is that you are
> looking for a clarification on what the base URI used to resolve a relative
> URI is when there has been a redirect involved.. specifically in your case
> the relative URI is in a manifest file and the manifest was obtained via
> 302 - is the base URI from the original manifest URI or the one that was
> given in the 302 location?
>
> Given that a major focus of our meeting will be on http-core, and this
> seems like a clarification of core semantics let's just discuss it there.
> Mark and I have huddled and we think
> https://github.com/httpwg/http-core/issues/38 seems like the right place.
> We'll have discussion time at the meeting and of course, the list is always
> a fine place for that kind of discussion too.
>
> As Individual:
>
> * its against the terminal (i.e. redirected) uri - though I had trouble
> finding language to quote on it.. so some guidance seems like a good idea
> at first glance
>
> * alternative services might also fit your use case - rfc 7838 .. in
> particular they have better fallback behavior if you want to revert to the
> original URI in case of reachability.
>
> -Patrick
>
>
>
>
> On Sat, Nov 3, 2018 at 8:12 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]