UDP Ingress

[sgrman]

Customer is requesting support for UDP based ingress capability. They utilize/create applications in the telephony space that are migrating to K8s. These applications are UDP based.

Submitting this for feature request.

thanks

[davecheney]

@sgrman thank you for raising this request. Sorry it took me so long to reply to you.

UDP proxying is too far outside Contours remit as a HTTP load balancer, we will not implement this feature.

[moderation]

Interested if this might be revisited now that UDP proxy support has been added to Envoy

• udp proxy: complete MVP envoyproxy/envoy#9046
• https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/udp_filters/udp_proxy#config-udp-listener-filters-udp-proxy

Like the original issue request we have an internal client that have a SIP based telephony app that prefers UDP.

HTTP/3 which is imminent (on both the internets and Envoy) is UDP based however for the purposes of Contour will likely be treated as HTTP / HTTP/2

[davecheney]

Thanks for the update.

For the record, we have no plans of adding a generic UDP proxy, but within the scope of wherever HTTP/3 goes with QUIC, we'll follow.

[michmike]

reopening this issue, not because we going to deliver this feature in a release, but because we will spend some time to do proper due diligence around the future impact of this feature.

[abursavich]

I am interested in seeing HTTP/3 support... Should this be considered a separate issue?

[jpeach]

On Jun 13, 2020, at 3:43 AM, Andy Bursavich <notifications@github.com> wrote:  I am interested in seeing HTTP/3 support... Should this be considered a separate issue? Yes, could you please file a new issue for HTTP/3? There’s a few different ways that could be supported, not only by UDP proxying.

[moderation]

Linking to #2582

[youngnick]

I've added "wontfix" to this issue because Contour is not currently planning on supporting UDP traffic. If you would like this to change, I need use cases and more information on what you would like.

For various networking-related reasons (which I am preparing a presentation and blog post on), I don't think it's practical to add generic UDP support to Contour's current design. But,, if you have specific protocols or use cases you really need hit, I need information about them to be able to see if we can change that stance.

So, please consider this "wontfix" a "no for now", not a "no forever".

[bnopacheco]

We work together with the biggest TV stations and websites in Brazil and LATAM. We deliver live content on TV through a variety of technologies and much content comes to us via UDP packets.

We are currently migrating to K8s and, due to the large volume of simultaneous connections, Envoy proved to be very performant in our tests. Please consider delivering UDP packets via Contour

[youngnick]

Thanks for the info, @bnopacheco! For the UDP packets you would want to forward, can you tell me more about what's on the in-cluster end? Does it need access to the client IP the UDP packets originally came from? Doing that for UDP in-cluster is quite tricky, it pretty much requires PROXY protocol, unless there's another protocol running on top of UDP that allows for the passing of the client IP.

In addition, how many replicas would there be in the cluster, and would the service expect UDP packets from a client IP to be consistently hashed to the same backend pod? That's also difficult to guarantee, and leads to a lot of concerns about managing pseudo-connection space in the Envoys.

As I said earlier, I'm working on a blog post about the limitations of in-cluster proxies more generally, these are two of the big ones for UDP.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack