Re: [Moq] Exploring HTTP/3

On Wed, Feb 8, 2023 at 10:33 AM Luke Curley <kixelated@gmail.com> 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.
>

Just want to clarify on QUICR. QUICR doesn't recommend URLs as the names.
It is pretty open in the way the names can be represented as long as there
is a way to get to the object cached without conflicts when an
intermediary, like CDN, is serving multiple tenants/customers.

>
> 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
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>