[Moq] Exploring HTTP/3

[Luke Curley <[e-mail]>]

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).