Re: [Moq] Exploring HTTP/3

[Lucas Pardue <[e-mail]>]

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
>