Re: [Moq] Exploring HTTP/3

[Bernard Aboba <[e-mail]>]

This forwarding scheme makes assumptions that should be made explicit. For
example: can a connection carry multiple streams with different
subscribers?

On Thu, Feb 9, 2023 at 10:01 Roberto Peon <fenix=[e-mail]>
wrote:

> I believe relaying could/should be done down at the QUIC processing layer,
> instead of requiring it to be done at L7.
> I’d hope this to be true of moq, regardless of using HTTP or not, to be
> clear.
>
> Assuming we use the higher-level protocol I suggested below, relays
> would/could then look like this python pseudocode, with O(1) memory and
> time, assuming the couple of lookups are O(1), and log(n) if not:
>
> while True:
>
>   quic_packet, addr = sock.recvfrom(port)
>   cid = quic.getCID(quic_packet)
>   decrypted_quic_packet = quic.decrypt(cid, data)
>   did_fast_path = False
>
>   try:
>     streams_in_packet = quic.getStreams(decrypted_quic_packet)
>     if len(streams_in_packet) == 1: # generally one when doing media.
>
>       try:
>
>         subs = subscribers[cid]
>         decrypted_packet_copy = decrypted_quic_packet
>         for sub_cid, sub_sid in subs:
>           if quic.allowedToSend(sub_cid, sub_sid) and
> h3.noHeadersFrame(sub_cid,sub_sid,decrypted_quic_packet):
>             quic.rewriteCid(decrypted_quic_packet_copy, sub_cid)
>            quic.rewriteSid(decrypted_quic_packet_copy, sub_sid)
>             quic.encryptAndSend(sub_cid, sub_sid,
> decrypted_quic_packet_copy)
>             didFastPath = True
>       except KeyError:
>
>           pass
>   except ErrorDecodingPacket:
>
>    pass
>   quic.slowPathProcessing(decrypted_quic_packet, didFastPath) # do HTTP3
> L7 processing, normal quic stuff.
>
>
> HTTP3 things could use this fast-path so long as the mapping of
> entity->stream was mostly static during a connection.
>
> -=R
>
> *From: *Ali C. Begen <ali.begen=[e-mail]>
> *Date: *Wednesday, February 8, 2023 at 6:31 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 18: 26 Roberto Peon <fenix=40meta. com@ dmarc.
> ietf. org> wrote: 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
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an External Sender *
>
> ZjQcmQRYFpfptBannerEnd
>
>
>
>
>
> On Wed, Feb 8, 2023 at 18:26 Roberto Peon <fenix=[e-mail]>
> wrote:
>
> 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.
>
> Thats where chunked transfer encoding / delivery works well. It can be
> made better though if CMAF chunking and HTTP  chunking worked better
> together. Maybe thats a topic we could tackle. They are independent from
> each other and from what i can see every implementation is different.
>
>
>
>
>
>
> -=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]>
> 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
>
> --
>
> -acbegen
> Using iThumbs
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>