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? 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. Marko [1]: https://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html
