Open DemiMarie opened 2 years ago
Ralith
commented
2 years ago It's not obvious to me that this can be implemented in a sufficiently unopinionated manner to provide out of the box, though I'm open to considering detailed proposals. As of #1364 the necessary hooks should be in place for downstream code to filter/inject packets freely.
DemiMarie
commented
2 years ago That is definitely valid, especially since one might well want to handle this at a lower level. Fastly’s faild uses a custom kernel module to handle misdirected TCP packets, and one could use XDP for similar purposes.
That said, there are some I/O backends (such as standard, unprivileged UDP sockets) for which there is no lower level to filter packets at, and so it makes to provide support in quinn itself. One approach would be a pair of hooks, one to embed a small amount of user-provided state in the connection ID, and one that is called with this state (plus the packet, of course) if quinn detects that an incoming packet was potentially misdirected.
Ralith
commented
2 years ago That's not significantly more capability than #1364 already introduces for handling incoming packets (combined with the existing CID customization API), and provides no way to actually handle a forwarded packet.
ECMP (Equal-Cost Multipath) generally only allows directing packets based on the 5-tuple. Therefore, it is possible that a server can receive a packet that should have been sent to another server or thread. This can be averted with a load balancer that can use the connection ID, but those may be too expensive. ECMP has the advantage of being stateless and generally implemented in hardware, so it has no performance impact.
quinn should provide support for detecting misrouted packets and sending them to the correct server, unless this is too implementation-dependent.