]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MINOR: quic: use stream elasticity value for initial advertisement
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Mon, 18 May 2026 06:27:32 +0000 (08:27 +0200)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Wed, 20 May 2026 07:52:50 +0000 (09:52 +0200)
commitd21ec4c707270d5b52df5e77b25f8774f6542ac1
tree36d8d28e7d61c0306eafffe9ee0155f4c428c7ca
parente4adba6e6410dcfce72c9fbdb20ed32c45e663ef
MINOR: quic: use stream elasticity value for initial advertisement

When stream elasticity is active, the maximum number of concurrent bidi
streams advertised via transport parameters is now reduced depending on
the connection load. This is implemented via conn_calc_max_streams()
which returns the value to use.

This is not applied on listeners with enabled 0-RTT. Indeed, for such
connections, clients are expected to reuse the previously seen transport
parameters. The server on the other hand must not decrease several
values on the newly advertised params, in particular for the maximum
number of concurrent bidi streams. The simplest way to prevent 0-RTT
failure is to not mix stream elasticity with it.

Note that the 0-RTT limitation is only applied for the initial value :
during the connection lifetime, stream elasticity can still be used by
the MUX to dynamically reduce the stream window. This will be
implemented in a future patch.
doc/configuration.txt
src/proxy.c
src/quic_tp.c