Re: [Moq] Exploring HTTP/3

Hey Luke,

Just FWIW, I'm super-interested in adapting HTTP to accommodate pub/sub and similar patterns; there's a lot of value in having an agreed way to do this not only for media, but other use cases. I wrote about this a while back,[1] and I'm still open to a lot of different paths to this goal; most recently, the possibility of selectively breaking assumptions in HTTP's message exchange pattern.

Lucas brings up a central point -- without browser support, our design space is very constrained. However, I suspect that a general-purpose design that has significant support would at least get consideration from them; they know that Server Push wasn't up to scratch, and that something needs to fill that hole at least partially (although the use cases they're interested in are very different).

Happy to chat with anyone about figuring this out.

Cheers,

1. https://www.mnot.net/blog/2022/02/20/websockets

> On 9 Feb 2023, at 5: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 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
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq

--
Mark Nottingham   https://www.mnot.net/