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)

[Roberto Peon <[e-mail]>]

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