L4 consistent hashing QUIC proxy

[josephjacks]

Mentioned partially and might depend on work in #492 given QUIC is built on top of UDP.

https://en.m.wikipedia.org/wiki/QUIC

Official standalone library: https://github.com/google/proto-quic

[mattklein123]

Presumably G will implement this at some point. cc @tschroed @htuch

[alyssawilk]

I suspect this is the case but I don't believe we plan on doing so this year. If more folks pile on requesting it I'll reach out to the QUIC TL and see if we can get it on the roadmap sooner rather than later.

[mattklein123]

Assigning over to @alyssawilk for tracking and further updates. Google will be starting on this in the next month or so. ETA for feature delivery is conservatively probably 6 months out.

[alyssawilk]

AFIK the Google-QUIC team is committed to integrating actual QUIC rather than UDP proxying. I don't think adding UDP proxying to Envoy was on our road map. I'll check with [relevant folks] about adding it but I suspect it would go after QUIC integration so a ways out.

If @cmluciano does stateful UDP proxying over on #492 this would be a fairly small feature (hash on ConnectionId rather than 4-tuple) on top of that. @cmluciano when you've hashed out line items for stateful proxying can you circle back and let me know if you're interested in a plug-in for determining connection based on ConnectionId? Even if not, if you do the bulk of the work for stateful UDP I suspect I can get folks on our end to sign up for hashing.

The only extra feature I think would be useful for QUIC proxying other than the above mentioned is "health checking" to ensure port connectivity. Essentially if you're doing this on the open internet it's nice to send a trial QUIC handshake through the open socket to make sure ephemeral port for the upstream connection isn't one of the commonly blocked UDP ports, or that no other entity is black-holing your packets. Depressingly important for QUIC reliability.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[josephjacks]

Looks like this is finally happening based on #2557 (comment) — Awesome!

[mattklein123]

Re-titling this "L4 consistent hashing QUIC proxy" to differentiate from the L7 support being worked on right now. This feature is required for a production QUIC deployment behind UDP load balancers that don't understand QUIC. I will work on a design doc for this in the next 1-2 months and share.

[danzh2010]

This feature is required for a production QUIC deployment behind UDP load balancers that don't understand QUIC.

This statement is out dated in light of #9424. And this issue seems not specific to QUIC any more, consider renaming and untagging it?

[mattklein123]

I don't think it's out of date, it's still required in some deployments if we want to deal with NAT rebinding, but I agree it's actually now covered by #9514. I'm still planning on working on this but it's gotten pushed back due to other obligations. If it's OK with you I would rather keep this issue right now for tracking as my plan is to implement #9514 as a means to solve this issue by allowing to hash on the QUIC connection ID within the UDP frame during UDP proxy forwarding.