On Mon, Jun 09, 2025 at 11:31:17AM +0300, Marko Karppinen wrote: > Hi everyone, I'm looking at finally enabling http/3 across our > infrastructure since haproxy 3.2.0 ticked some boxes for us on that > front. There's one issue remaining: > In our setup, we load balance HTTP traffic by ECMP to an anycast IP > shared by a fleet of haproxy servers. One issue with this is that when > the set of available servers change, the packets of existing > connections may end up on servers not prepared to handle them. > For h1 and h2, we've implemented hitless server retirement on the > operating system level, by recognizing invalid TCP packets and > forwarding them over multicast to the other servers in the same edge > location. The server that actually has a session with the client can > then pick up the packets and complete the response. > For h3, there's no way to distinguish valid and invalid packets > outside haproxy, so we're looking to implement this facility within > haproxy itself. > In a nutshell, whenever haproxy receives a quic packet it doesn't > recognize, it should transparently proxy that packet to a specified > destination (in our case a GRE over multicast interface). There are > some subtleties to deal with but that's the high level task. > Standardization work like QUIC-LB[1] will probably eventually handle > this with an approach based on QUIC connection IDs, but I imagine > something like that is ways off both in the standards and in the > haproxy implementation. So maybe there's room to do a simpler approach > in the interim?
We already looked at QUIC-LB specification, but it doesn't seem to match our needs as it mostly targets load-balancer working at layer 4. > Looking at analogs in the current HAProxy configuration, maybe this > could be surfaced as a "quic-unknown" keyword in the style of > "quic-initial", and a new "dgram-forward" action it would support. > We're happy to put in the work to implement this, but it'd be super > helpful if someone familiar with the haproxy quic code could lay some > ground rules on the dos and don'ts around this. Any pointers would be > greatly appreciated. Indeed this kind of work should be possible without too much hassle. I'm ok with a new kind of rule targetting unknown QUIC packets, i.e. non-Initial packets for which the DCID is not known by the haproxy instance. At first glance, this should be invoked in quic_rx_pkt_retrieve_conn(), just prior to Stateless Reset emission. Do not hesitate if you have further questions, Regards, -- Amaury Denoyelle
