>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. -=R From: QUIC <[email protected]> on behalf of Stefan Eissing <[email protected]> Date: Friday, February 16, 2024 at 01:20 To: Kazuho Oku <[email protected]> Cc: IETF QUIC WG <[email protected]>, HTTP Working Group <[email protected]>, Lucas Pardue <[email protected]> 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 <[email protected]>: > > 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".
