Re: [Moq] Exploring HTTP/3

[Luke Curley <[e-mail]>]

I've never used it before, but I know Youtube supports HLS for
contribution. Use PUT instead of GET and you have a publisher. I don't
think it would be too hairy, although it would require switching from push
to pull at an origin.

And yeah, I agree that browsers are the main obstacles when pushing media,
but that doesn't change too much with WebTransport. We still need a way to
set the priority when pushing a WebTransport stream, much like we would
need a way to set the priority when issuing a HTTP PUT. I suppose it's
easier to modify WebTransport since it's in development.

On Wed, Feb 8, 2023 at 11:08 AM Lucas Pardue <[e-mail]>
wrote:

> Hi Luke,
>
> For distribution, I think HTTP can probably be massaged into meeting the
> needs of the group. That was a thought I had when reading your early WARP
> drafts. I would review something if you put it out.
>
> However, I think things get trickier when we consider the charter text
> "The solution will be implementable in both browser and non-browser
> endpoints.". The browser part makes things tricky. It probably rules out
> non-kludgy HTTP/[2,3] server push solutions for distribution (because
> there's no API for push, and resource transfer optimization via push is
> seemingly getting overtaken by 103 early hints now). So I agree avoiding
> push is probably a good way to go.
>
> Browser and HTTP contribution seem more thorny. I don't work for a browser
> but I'm not sure a client has sufficient controls over browser behaviours
> to send HTTP content in a way that some of the WG goals might need.*
> WebTransport provides a lot of toolkit, it might not be perfect, but it
> seems closer to hand than the idea that a client might be able to influence
> local upload prioritization deep in the browser stack (as just one
> example).
>
> Cheers
> Lucas
>
> * Over in the HTTP WG, we had a short thread on prioritization of
> concurrent uploads, see
> https://github.com/httpwg/http-extensions/issues/2242. RFC 9218
> priorities always left the door open to allowing clients to use priority
> for "local decision making", so its feasible. I just didn't hear much
> support for implementing upload prioritization for resumable uploads, but
> maybe a media use case might change that. Not sure.
>
>
>
> On Wed, Feb 8, 2023 at 6:33 PM Luke Curley <[e-mail]> wrote:
>
>> Hey MoQ,
>>
>> As I mentioned in a recent email:
>>
>> > The best part about HLS/DASH is the HTTP ecosystem. That includes CDN
>> support, optimized software, and general interoperability. We lose a lot of
>> this by creating a custom pub/sub mechanism.
>>
>> > The worst part about HLS/DASH is the latency. This is caused by
>> head-of-line blocking (buffering) and the client being in charge
>> (requesting playlists and segments). The Warp draft tackles these problems
>> with QUIC prioritization (delivery order) and WebTransport push
>> respectively.
>>
>>
>> I think it's possible to address the problems with HLS/DASH without
>> forgoing HTTP.; WebTransport push is not the only option. At one point I
>> drafted Warp over HTTP/3, but abandoned it because it's more complicated
>> and Twitch doesn't need 3rd party CDN support.
>>
>> Warp's OBJECT frames are strikingly similar to HTTP/3's HEADER+DATA
>> frames, and unironically we're considering using qpack to compress the
>> OBJECT headers. I propose each Warp object would be a HTTP resource
>> instead. This parallels discussion at the interim suggesting we need a way
>> to GET old media for DVR.
>>
>> Head-of-line blocking can be avoided using QUIC (or HTTP/2)
>> prioritization with the Priority
>> <https://datatracker.ietf.org/doc/html/rfc9218> header. The client would
>> request each source with a priority based on the contents. For example,
>> request the newest audio segment with urgency=7 while the older video with
>> urgency=4. There's some warts especially involving relays but it's not
>> unsolvable.
>>
>> The latency caused by requests can be avoided by long polling. The
>> purpose of WebTransport push is to avoid the round trip between when the
>> client is informed about new media until it requests it. Twitch uses
>> long-polling with HLS today to accomplish the same thing, preflighting the
>> next request based on a deterministic URL. Prioritization lets you
>> preflight multiple concurrent requests without the risk of them fighting
>> for bandwidth.
>>
>> Alternatively, some variation of HTTP push could avoid request latency.
>> I've said this before, but QUICR looks a lot like a hypothetical HTTP
>> subscription since it's based soley on the URL. Nobody likes HTTP push, let
>> alone extending it, but technically we're building something similar. I
>> would not recommend this direction.
>>
>> I'm mostly worried about how browsers/servers will handle a request per
>> frame. I still strongly recommend breaking media into layers anyway; I'm
>> still not convinced that networks need the ability to drop individual
>> frames. For example, non-reference frames could be bundled together into
>> same HTTP resource, and prioritized lower than reference frames.
>>
>>
>> But in theory that's all we need. I can write up a draft if the WG thinks
>> it would be fruitful to explore this direction. It could be a DASH
>> extension, although it's still important to address the contribution side
>> of the coin (ex. push using HTTP PUT).
>> --
>> Moq mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/moq
>>
>