Re: [Moq] Proposal for "QUIC on Streams"

[Lucas Pardue <[e-mail]>]

Hi Ted, Cullen, 

On Mon, Feb 26, 2024, at 17:04, Cullen Jennings wrote:
> 
> There is a push to make QUIC over UDP work all the places where raw UDP was blocked which reduces the need for fallback. QUIC over UDP, by having sessions, solves many of the reasons why people say they block UDP but not TCP. 
> 
> I would rather just focus our energy on making MoQ work over QUIC over UDP. That is the high runner use case. Once we have that sort of done, then I would be in favor of looking at ways to do fallback. 

That seems absolutely logical to me. Let's get one thing done first.

I suspect for MoQ the principal issues with QUIC on Streams will come from the requirements related to "unreliable" delivery, whether that's achieved by stream resets or datagrams. It's not possible, as standard, to reclaim data stuffed into a TCP socket, leading to needing things like TCP_NOTSENT_LOWAT [1].

However, that problem only really exists where there is a bandwidth bottleneck and/or a lossy path. I can imagine scenarios where a closed circuit has a higher quality path and therefore doesn't need these features so much. There, QUIC on Streams offers potential for performance advantage, rather than to be viewed as a fallback, because you defer packetization, loss recovery and congestion control to something else. For instance, if there's a publisher and relay on the same box, a simple pipe would be enough to allow QUIC frames to be exchanged.

Cheers
Lucas

[1] - https://lwn.net/Articles/560082/

> 
> 
>> On Feb 16, 2024, at 2:40 AM, Ted Hardie <[e-mail]> wrote:
>> 
>> Lucas and Kazuho have proposed a mechanism to bring QUIC to any transport that provides the stream mechanics that it needs; see the proposal here:  https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams and the discussion ongoing on the QUIC list.  To simplify a great deal, this runs QUIC on TLS over TCP when UDP is not available. 
>> 
>> It would be interesting for folks building MoQ systems to consider whether this would provide adequate fallback for MoQ when QUIC's current stack is blocked by UDP failures. 
>> 
>> There is a companion draft on running HTTP/3 over QUIC on Streams, https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-on-streams-00.txt (see also draft-ietf-webtrans-http2).  I don't think this would be required to implement MoQ, but its requirements will probably largely drive the discussion on QUIC on streams.
>> 
>> regards,
>> 
>> Ted
>> -- 
>> Moq mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/moq