3 ms·

While this is true, a lot of software is not prepared to have connections change IP address. Lot's of networking software works on the idea of a loop which ass

While this is true, a lot of software is not prepared to have connections change IP address. Lot's of networking software works on the idea of a loop which assigns each connection (5-tuple) to a thread. If QUIC were to be more widely used, the association of the connection would have to be linked to the connection identifier in QUIC, which is different than the 5-tuple. Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten. This also means the kernel, which could previously steer traffic to a connection onto a single core. Realistically, QUIC will need a BPF filter to inspect the connection identifier and steer to the same core in the event of an IP address change. All this is to say: I don't think most software is ready for QUIC, even if the protocol allows for cool things.

bb88 8y ago
> Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten. Yeah, but I don't think that's a hard thing to do, realistically speaking. Instead of mapping a source ip/port to a destination in the LB it's mapping a QUIC session ID instead. > This also means the kernel, which could previously steer traffic to a connection onto a single core. Most likely the kernel will not be rewritten to support this, since QUIC is a user space protocol. Also, the LB might just be able to rewrite the packet so it looks like it came from the LB when it sends it on to the server. The end server would never see the ip address change.