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

While I agree that Alt-Svc may be the to better solution looking forward,
we still need to resolve the issue for existing HTTP redirect
architectures, mainly for HLS as it is still the dominating video streaming
protocol, but for DASH also.
HTTP redirect is widely in use and clients that don't conform with the
relative resolution, as it seems to be the case, degrades qoe and cause a
significant performance hit on CDN load balancers.

If there is agreement that in case the playlist is requested separately,
and it is not embedded within another encapsulating entity, then the
playlist base URI is the final retrieval URI, after redirect, it would be
great if there could be some clarifications that establish this
understanding.

We could then work with player software developers to adjust their code
accordingly.
If there are gaps in browser XMLHttpRequest or fetch, we can also
articulate how this should be bridged.

Thanks,
Ori




On Tue, Nov 6, 2018 at 3:23 AM Ryan Hamilton <rch@google.com> wrote:

> On Mon, Nov 5, 2018 at 2:23 PM, Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> Hey Patrick,
>>
>> Some replies inline.
>>
>> On Mon, 5 Nov 2018, 02:01 Patrick McManus <mcmanus@ducksong.com wrote:
>>
>>>
>>>
>>> On Sun, Nov 4, 2018 at 3:59 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>> chrome should speak for themselves if they like, but my understanding
>>> from previous comments is that they intend to fix this as part of the work
>>> for supporting HQ at least for h2. (h1 has always been a little concerning
>>> there as it uses the host and port implicitly)
>>>
>>
>> My understanding is that Chrome host-based Alt-Svc is supported in gQUIC
>> but not for H2 ( from a Google Groups thread "layering of socket pools
>> makes implementing this for HTTP/2 significantly more complex"). If that
>> complexity has been overcome it would be good news, it would be nice to
>> have a public statement to that effect.
>>
>
> Alas, this is still the case.
>
>> I bring this up because its the only thing that I know of that satisfies
>>> both relative references against the derived location _and_ fallback to the
>>> original location in the case of reachability failure (which relative
>>> references to the redirected url do not) - which is a nice pattern.
>>>
>>
>> Totally agree, I think there is untapped potential. Especially when
>> combined with ORIGIN and Secondary certs.
>>
>> I could imagine some deployment that offers several alternatives, to
>> avoid falling back to the broker. Although I don't think implementations
>> would presently work that way.
>>
>> DASH also offers a feature to specify multiple origins in the manifest
>> itself, with the client choosing them in an ordered way. There's
>> potentially some interesting interplay with Alt-Svc here.
>>
>> Lucas
>>
>>>
>

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
orif@qwilt.com