Re: [Moq] Exploring HTTP/3

[Spencer Dawkins at IETF <[e-mail]>]

Just chiming in,

On Thu, Feb 9, 2023 at 12:12 PM Bernard Aboba <[e-mail]>
wrote:

> 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.
>>
>
I can't comment on what the working group thinks about MQ relay
functionality (see previous emails sent this week, and last), but I'm still
trying to understand how many relays will be strictly relaying one
broadcast, and how many relays will also be performing additional
functionality we've identified (caching, rate adaptation, transmuxing,
etc.).

It will be easier to optimize for the common case, if we know what the
common case is.

Unless we're figuring out a QUIC in/QUIC out caching architecture, for
instance, I'd think relays caches would be popping up to HTTP anyway,
wouldn't they?

Best,

Spencer


> 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
>>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>