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 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 <quic-bounces@ietf.org> on behalf of Stefan Eissing <stefan=40eissing.org@dmarc.ietf.org>
> *Date: *Friday, February 16, 2024 at 01:20
> *To: *Kazuho Oku <kazuhooku@gmail.com>
> *Cc: *IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucas@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 <kazuhooku@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 
> > 
> > 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".