Re: [Moq] Exploring HTTP/3

[Roberto Peon <[e-mail]>]

Pedantry is not always unappreciated—I got a smile from it.

True—caching impacts latency as 2nd order thing (fewer packets going through places which could potentially be bottlenecks, and reduces path RTT, which allows lower jitter for same channel utilization (or higher utilization for same jitter)).

The 1st order latency impacts come from being able to forward things cheaply and without requiring in-order reassembly everywhere.
-=R

From: Ali C. Begen <ali.begen=[e-mail]>
Date: Wednesday, February 8, 2023 at 5:25 PM
To: Roberto Peon <[e-mail]>
Cc: Luke Curley <[e-mail]>, MOQ Mailing List <[e-mail]>, Victor Vasiliev <[e-mail]>
Subject: Re: [Moq] Exploring HTTP/3
On Wed, Feb 8, 2023 at 15: 47 Roberto Peon <fenix=40meta. com@ dmarc. ietf. org> wrote: Hello Victor! Here is how HTTP/3 could work as an underlying protocol shape for moq, I think. Client makes request P for a playback session for video X,
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd


On Wed, Feb 8, 2023 at 15:47 Roberto Peon <fenix=[e-mail]<mailto:[e-mail]>> wrote:
Hello Victor!

Here is how HTTP/3 could work as an underlying protocol shape for moq, I think.

Client makes request P for a playback session for video X, by stating what it wants onto the “control stream” (i.e. a generic resource name for the video/broadcast/whatever, which does not need to a prioi know anything about what is available).

Server responds to this request that it is replying with the following streams:
- video stream V
- audio stream A
- manifest stream M
.. and keeps the stream open, so it can continue to communicate to the client.

Resources V, A, M are cacheable.
Resource P (the playback request) is not cacheable, since this is an ephemeral “control” (a.k.a metadata) stream.

Client, being informed it is needing V,A,M, requests these if it isn’t already reading from them.
Assuming push exists, and the server did it, this data will already be at the client, and so we’ve saved the latency we needed to save.
Not to pedantic, but you reduced the startup delay aka time to first frame, not the latency. If latency reduction is the goal, pushing is not mandatory. The client can request the upcoming media object to get the lowest latency.

Startup delay vs. latency are orthogonal goals. And IMO the client should pick whatever it likes to have. RFC 6285 for example supports either.
If client wishes to change things, it can send another request to the server for this, referencing the same playback session ID.
The server can then stop sending old or start sending new things, or start sending from a different offset.

This works even when the server is dumb and doesn’t push, and we still can get much of the benefit in that case.

What I think this gets us:
- streaming with single-packet “delay” at relays
- O(1) time/space overheads at relays (about as good as we’ll ever get). This works by having a ‘subscription’ table so when we receive a packet on a stream with subscriptions, we can immediately write a new packet and send it out on the sub’d connection. We’d rewrite the CID,stream ID, and of course reencrypt.
- caching when caching is useful/available
- easy fallbacks
- optional compression of metadata.

What is this missing, requirements-wise?

-=R


From: Moq <[e-mail]<mailto:[e-mail]>> on behalf of Victor Vasiliev <vasilvv=[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 8, 2023 at 3:23 PM
To: Luke Curley <[e-mail]<mailto:[e-mail]>>
Cc: MOQ Mailing List <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Moq] Exploring HTTP/3
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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd
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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/moq<https://www.ietf.org/mailman/listinfo/moq>
--
Moq mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/moq<https://www.ietf.org/mailman/listinfo/moq>
--
-acbegen
Using iThumbs