Hi everyone,

I'm Amaury one of the maintainer of the haproxy QUIC stack. We recently
had an interest on the QUIC on Streams draft. As a remainder, this is a
stripped version of QUIC designed to operate on top of TCP.

https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams

I just recently implemented support for it on haproxy as an experimental
work. Interoperability was tested using quic-go as client. It was pretty
much straightforward as we already had in our code a separation between
the transport and multiplexing layers. Besides, the HTTP/3 part is left
untouched by the draft. One limitation though is that I wasn't able to
test flow control, as quic-go client did not seem to refill our window
during our tests.

This new protocol seems really promising as it could extend QUIC usage
in new environments, where a full stack seems too much of a burden for
less gains, or simply because UDP is a no-go. For example, it could be
the case in datacenters, or even host-local communication between
containers. On haproxy side, we are still hesitant to support QUIC on
the backend side due to the amount of work, but a QUIC on Streams
implementation would be a first easier step in this direction. Another
point is that QUIC on Streams has the benefit to rely on standard TLS,
which means its deployment won't be restrained by incompatibilities with
SSL libraries

For these reasons, I hope that QUIC on Streams will gain more interest
in the future and I'm willing to help on that if necessary.

For those of you who wish to implement QUIC on Streams support and want
to use haproxy as a server, first check out the branch
'20250214-quic-on-streams' from our repo. A QUIC on Streams listener can
be defined in haproxy configuration using this syntax :

  bind :20443 proto qos ssl crt /home/amaury/infra/ssl/cert.pem

Thanks,

PS: Just saw that a new draft for HTTP/3 over WebTransport has been
proposed this morning. Another proof that there is interest to have a
subset of the QUIC/H3 ecosystem running on top of TCP. Let's hope new
discussions will arise so that a common solution could be found.

-- 
Amaury Denoyelle

Reply via email to