-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[UDP][Feature] UDP Content Token Routing #9514
Comments
One thing I'd like to see here is to be able to have a sort of fallback routing for when no specific token is configured. |
I'd also like to add the explicit consideration that tokens could be any length and envoy shouldn't be opinionated on that. |
Thanks for raising this @markmandel. This is actually a more general case of what needs to be done for #1193 in which we need to route UDP packets based on the QUIC connection ID. I have some thoughts on how we can approach this and will reply back when I have some more time. cc @danzh2010 |
@mattklein123 glad to hear it has a more general application than the use cases I am thinking of as well. I didn't think to look at how QUIC implements this! 🤦♂️ There is so much good prior art there for a variety of use cases (sessions, crypto, etc). https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-connections (for this also subscribed who want to read up) |
As another data point, IoT protocols also rely on tokens for routing - and other things, like request/response matching, caching and congestion control. CoAP (rfc7252) is based on UDP and one I'm particularly interested in seeing work with Envoy. The way CoAP uses tokens is slightly different than the way Mark/QUIC is describing (it's more a request ID) but hopefully helpful in thinking about a generalized solution. |
I would like to support hash policy in udp proxy. The udp proxy does not support hash based lb algorithms perfectly because it does not provide LoadBalancerContext when choose a host. I have investigated the tcp case and I found that it has the hash policy option. This does not depend on the incoming packet's content. Here is the my draft version of implementation : chadr123/envoy@d95c3f5 Please give your opinions for my idea. |
@chadr123 can you open a PR where we can discuss? I want to make sure we built the API in a way that will allow for byte range hashing. I think this can just be a wrapper message with a oneof inside of it that initially just has the general hash policy, and then later we can add byte range hashing on the datagram. Thank you! |
Ok. I will open a PR soon. :) |
I'd like to suggest an additional way for at least the games use case. Where @markmandel has the client token as part of the UDP packet one could include a server token as well. I know he expressed in his videos covering this that he didn't like the idea but i think that was only to just a server token. I would suggest the client auth token and the server token. The server token is what's used to route to the upstream server while the client auth token is used to allow or drop the packet. The client token could be manually added to the config or another way would be to offload the authorization to an external auth server to handle it. If the external service approves the client token its mapped with its network tuple such that further packets with that same tuple and client token would be passed through with out sending out for the auth call. There could be a TTL on the token so that after x amount of seconds the auth service is called again to see if it's still valid. In the event that the reauthorized client token failed on network allow an option to keep current mapped token, drop mapped token or reauthorize the mapped token with the attached network tuple. This implementation alleviates some of his concerns about number of tokens/session per endpoint in that the server token wouldn't change that often and be at a lower count than one per client session. Also it would be nice if there was a way to call an API for the listener to remove/update the token info. Example user logs out of their game and the service handling the logout could call the to the listener to remove the client token. I also don't see in his proposed config on how to specify where the token would be found in the UDP packet. |
(Please consider this document a sacrificial draft. Feedback corrections and comments are very much appreciated, and likely warranted as I am only newley experienced with Envoy)
Objective
Be able to preemptively route a UDP session to a specific upstream entry in the cluster, based on content available (i.e. a token) within the UDP packet.
This is specifically useful for stateful endpoints in a cluster, such as a Dedicated Game Server for multiplayer games (which is my primary expertise), or VOIP/SIP backends utilise (I believe).
For this reason, any sort of random/round robin type load balancing is not effective, as we need to be able to specifically send a session to a specific cluster upstream endpoint.
Background
Articles
Presentations
Requirements and scale
Requirements:
Use Cases
The specific use case that I want to cover is around Dedicated Game Servers for multiplayer games, but could potentially be applied to any sort of stateful system that uses a UDP stream as a communication protocol.
Concerns / Questions
Design ideas
This is a sacrificial draft for a potential configuration for the content token routing:
Concerns / Questions
Alternatives considered
The text was updated successfully, but these errors were encountered: