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 > > -=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 > > > > 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 > > > > 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".
