Re: [Moq] Exploring HTTP/3

[Victor Vasiliev <[e-mail]>]

Hi Luke,

As you mention, most of the transport-level techniques that WARP uses
(priorities, etc) are doable with HLS or DASH over HTTP/3 (in fact, I am
aware of some of those being actually implemented in practice).

That said, I believe that HTTP is fundamentally not the right solution
here.  HTTP is really good when you have a resource with an address that's
known in advance and you are trying to fetch that resource (directly or
indirectly) from an entity that is an authoritative source for it.  This
works well for the regular web pages, and this works well for VoD, but as
soon as you stray away from the well-lit path, you suddenly find yourself
doing an increasingly convoluted series of awkward things just to make it
work.  For instance, you mention long-polling, but long-polling is not
necessarily consistently supported by the ecosystem, and you have no
guarantee that an intermediary won't wait until fetching the entire
resource, or deliver chunks unevenly over time.  Similarly, HTTP server
push has been largely unsuccessful.  Same thing with trying to make
Priority header work with the WARP priority scheme.

I think MoQ provides us with an opportunity to build a protocol that
actually makes sense for transporting live media, as opposed to trying to
fit HTTP into the model it's not good at.  Especially when with every
"gotcha" you encounter with HTTP, you lose some of the advantage that made
HTTP seem like an appealing proposition in the first place.

  -- Victor.

On Wed, Feb 8, 2023 at 1: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
>