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)

[Willy Tarreau <[e-mail]>]

Hi Kazuho, Lucas,

On Fri, Feb 16, 2024 at 05:24:59PM +0900, Kazuho Oku wrote:
> 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

These are super interesting! I've expressed interest in the past in trying
to port H3 to TCP though I didn't have all the gory details of the protocol
by then. More recently I discussed this possibility a few times with my
coworkers who implemented and maintain QUIC in haproxy, as a cleaner
"backend" protocol.

What I'm seeing with haproxy is that we generally have H1/H2/H3 for the
front connection, and H1 most often for the connection going to the
server. The reason is that H2 is not very interesting there because:
  - it doesn't support multiple client multiplexing well over the same
    connection due to head of line blocking, unless you use a super
    small window ;

  - the max streams supported by the server isn't known upfront and
    can sometimes require to retry failed requests, or to be very
    conservative on the number of parallel requests until you get
    the server's SETTINGS. Of course you can put that in a config, but
    with some automated deployments you just don't know.

  - the default max frame size is not efficient enough to perform zero-copy
    transfers, and increasing it is just going to make HoL worse.

H1 on the other hand has the problem of not being able to abort a retrieval
without breaking the connection. One option could consist in dealing with
single-stream H2 with large frames but that's not necessarily what servers
will do. I've been thinking that using single-stream H3 connections would
be a better option for this. It would keep the efficiency of HPACK and
QPACK header compression (even if for reused connections it's less
efficient), and some lightweight framing that could possibly improve
transfer efficiency and aborts (this is still to be verified).

And of course, dealing with a better offset-based in instead of credit-based
flow-control is appealing. So for me, H3 over TCP could be a nice upgrade
to H1 on the backend with less hassles than H2, and QUIC over TCP could
probably just replace H2 on the backend. Also some of the TTFB benefits
of QUIC over UDP (0-RTT etc) are irrelevant on the backend because there
you mostly keep many connections open for a long time. I'm very interested
in seeing what it could become!

Cheers,
Willy