To avoid deadlock with TCP or TCP-like things, we’d have to guarantee we could always read (what is for QUIC and H3 async) control stuff from the socket, which would require always reading all bytes/frames sent on the socket, always.
I’m unsure if that same text is sufficient (haven’t thought about the conflicting congestion control stuff), but it is certainly a good start. I believe it might be sufficient for effectively tunneling H3 over TCP… probably. Certainly it wouldn’t work without said text. -=R From: QUIC <quic-boun...@ietf.org> on behalf of Lucas Pardue <lu...@lucaspardue.com> Date: Monday, February 26, 2024 at 08:18 To: Roberto Peon <fe...@meta.com>, Stefan Eissing <stefan=40eissing....@dmarc.ietf.org>, Kazuho Oku <kazuho...@gmail.com> Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http...@w3.org> Subject: Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt) Hi Roberto, On Mon, Feb 26, 2024, at 16: 04, Roberto Peon wrote: From a functional point of view, when doing a mapping of H3 to any TCP (or TCP-like) thing, we need to answer the question: How do we deal with the potential of deadlock because ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd Hi Roberto, On Mon, Feb 26, 2024, at 16:04, Roberto Peon wrote: From a functional point of view, when doing a mapping of H3 to any TCP (or TCP-like) thing, we need to answer the question: How do we deal with the potential of deadlock because of TCP’s flow control conflicting with the “higher level” protocol’s without also allowing for OOMs? Seems like it could be possible, but I don’t see an explanation. Good point. Seems like HTTP/2 has the same problem, and gives some consideration text in Section 5.2.2 [1]. Do you think adding similar text to QUIC on streams covers it? Cheers Lucas [1] - https://www.rfc-editor.org/rfc/rfc9113.html#name-appropriate-use-of-flow-con<https://www.rfc-editor.org/rfc/rfc9113.html#name-appropriate-use-of-flow-con> -=R From: QUIC <quic-boun...@ietf.org> on behalf of Stefan Eissing <stefan=40eissing....@dmarc.ietf.org> Date: Friday, February 16, 2024 at 01:20 To: Kazuho Oku <kazuho...@gmail.com> Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http...@w3.org>, Lucas Pardue <lu...@lucaspardue.com> Subject: Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt) !-------------------------------------------------------------------| This Message Is From an External Sender |-------------------------------------------------------------------! > Am 16.02.2024 um 09:24 schrieb Kazuho Oku <kazuho...@gmail.com>: > > Hello QUIC and HTTP enthusiasts, > > We, Lucas and I, have submitted two drafts aimed at broadening the reach of > HTTP/3 - yes, making it available over TCP as well. We are eager to hear your > thoughts on these: > > QUIC on Streams: A polyfill for operating QUIC on top of TCP. > https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams<https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams> > > HTTP/3 on Streams: How to run HTTP/3 unmodified over TCP, utilizing QUIC on > Streams. > https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-streams<https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-streams> > > As the co-author of the two drafts, let me explain why we have submitted > these. > > The rationale behind our proposal is the complexity of having two major HTTP > versions (HTTP/2 and HTTP/3), both actively used and extended. This might not > be the situation that we want to be in. > > HTTP/2 is showing its age. We discussed its challenges at the IETF 118 side > meeting in Prague. > > Despite these challenges, we are still trying to extend HTTP/2, as seen with > WebTransport. WebTransport extends both HTTP/3 and HTTP/2, but it does so > differently for each, due to the inherent differences between the HTTP > versions. > > Why are we doing this? > > Because HTTP/3 works only on QUIC. Given that UDP is not as universally > accessible as TCP, we find ourselves in a position where we need to maintain > and extend not only HTTP/3 but also HTTP/2 as a backstop protocol. > > This effort comes with its costs, which we have been attempting to manage. > > However, if we could create a polyfill for QUIC that operates on top of TCP, > and then use it to run HTTP/3 over TCP, do we still need to invest in HTTP/2? > > Of course, HTTP/2 won’t disappear overnight. > > Yet, by making HTTP/3 more universally usable, we can at least stop extending > HTTP/2. Interesting. This gives a much easier deployment path for HTTP/3 and extensions. I have been reluctant to bring HTTP/3 to Apache httpd because the cost/benefit aspect is so unfavourable. I see no problem in bringing HTTP/3 over TLS into our server. Cheers, Stefan PS. We should probably not call this "TCP3".
