search

envoyproxy / envoy

Cloud-native high-performance edge/middle/service proxy
https://www.envoyproxy.io
Apache License 2.0
25.13k stars 4.82k forks source link

L4 consistent hashing QUIC proxy #1193

Open josephjacks opened 7 years ago

josephjacks commented 7 years ago

Mentioned partially and might depend on work in https://github.com/lyft/envoy/issues/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 commented 7 years ago

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

alyssawilk commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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[bot] commented 6 years ago

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 commented 6 years ago

Looks like this is finally happening based on https://github.com/envoyproxy/envoy/issues/2557#issuecomment-434497327 — Awesome!

mattklein123 commented 5 years ago

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 commented 4 years ago

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 https://github.com/envoyproxy/envoy/pull/9424. And this issue seems not specific to QUIC any more, consider renaming and untagging it?

mattklein123 commented 4 years ago

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 https://github.com/envoyproxy/envoy/issues/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 https://github.com/envoyproxy/envoy/issues/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.