Re: [Moq] Exploring HTTP/3

["Ali C. Begen" <[e-mail]>]

On Wed, Feb 8, 2023 at 15:47 Roberto Peon <fenix=[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]> on behalf of Victor Vasiliev <vasilvv=
> [e-mail]>
> *Date: *Wednesday, February 8, 2023 at 3:23 PM
> *To: *Luke Curley <[e-mail]>
> *Cc: *MOQ Mailing List <[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]> 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
>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>
-- 
-acbegen
Using iThumbs