Edit: (@alyssawilk on behalf of @cmluciano)

Design doc:

https://docs.google.com/document/d/1G9IVq7F7Onwinsl6EYzGsdzAGvVbo2FGfcPt35ItIx8)

Roadmap

• General API refactoring (Ex. less file-descriptor hardcoding)
• UDP listener
• UDP "session manager"
• Basic UDP proxying sessions (proxy -> host)
• Advanced UDP proxying features (timeouts, filters, etc.)
• Network filters (need a use-case)
• Clear documentation with configuration and developer walkthroughs of UDP features

Original top level comment (@rshriram)

Just like TCP proxying, it would be great if Envoy had support UDP proxying as well.

The current code for TCP proxying is pretty generic for most part. The flow is something like this:
on_connection_received_callback()
-->pick upstream and connect to it
on_data_received_callback(data)
-->write_to_upstream(data)
on_stream_reset_callback() [downstream reset or upstream reset?]
-->cleanups
Based on a cursory scan through the code, there is also a timer that cleans up connections beyond a certain period of inactivity ( @mattklein123 please confirm).

In terms of UDP support, much of the code in filters above can be repurposed or renamed to be generic to TCP/UDP where possible.

The ClientConnectionImpl class hardcodes the socket type to be Stream. This needs to be changed.

UDP packets with source port 0 should be dropped(?)

Instead of creating/destroying UDP connection objects per packet, the process can be optimized by having a keepalive style timer that deletes the connection objects after timer expiry. UDP datagram size can be fixed to one MTU or less, as a first order approximation, that should (RFC 791, RFC 2460). We do not need to buffer up data and send it out. WDYT?

In terms of session affinity, packets from same src port, src ip would go to same dst port, dst ip.