UDP load balancing

[Geal]

There's an interest in supporting UDP load balancing in so, so here's an issue to explore that topic. There are some protocols relying on UDP that could benefit from load balancing, such as DNS, syslog, MQTT, and more recently, Quic. Unfortunately, UDP has no concept of session or stream like TCP:

• no session: there is no way to know, from an UDP packet, when we can drop ressources allocated to proxying packets to and from a client
• no stream: packets are not buffered and reassembled in the kernel, they're provided as is, possibly in the wrong order, some dropped, etc

There's also no concept of a listen socket like TCP: the UDP socket that receives client traffic will receive all of their packets, they're not separated on different sockets with each their own buffer. On the backend side though, it would be possible to have one socket per "session".

What's apparent, from looking at various protocols (and the discussion at https://github.com/haproxy/haproxy/issues/62 ) is that generic UDP load balancing, where we do not know anything about the higher level protocol, is not very useful, while e could provide a lot of value if we can recognize protocols that are one way, or request-response, or multiplexed, etc.

For that, we would need to support those higher level protocols, ie being able to recognize packet contents and find a field to use for routing (whether from client to backend or the other way).

Examples of routing information:

• DNS has a transaction ID that we can use to know which client must receive which response (and track hen a request-response session is done)
• MQTT has a topic name to route to backend, a client ID to associate responses to clients, information on keepalive behaviour, and a packet header indicating the session's state
• Quic has a connection ID (that could be removed though) then an encrypted payload. For that case, we might want to terminate the encrypted stream there, then route on the decrypted content

[Geal]

There's another issue around handling "sessions" across different workers, and across upgrades: there is no guarantee that 2 packets from one client will arrive to the same worker, so session information should be shared between workers (and there's a risk of data races here, where another worker receives the second UDP packet before receiving the session information)