-
Notifications
You must be signed in to change notification settings - Fork 204
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
0-RTT DCID Routing #1513
Comments
The operating assumption here is that the server doesn't get a chance to set a connection ID because that takes a round trip. That text exists because the client can still be sending 0-RTT after getting a connection ID from the server. It's a little rare though, and the consequences of an occasional inconsistency were considered worse than just having all 0-RTT go to the same place, even if that place was a black hole. |
You could require the 0-RTT uses not the original DCID, but the DCID it was given by the server after the earlier successfull 1-RTT handshake. |
Yes. That is an option, it wouldn't change the recommendation of the quoted text though. There's a tension there that makes ticket reuse (a common practice still) harder. |
So a design that might be valid here is to include a connection ID in the NEW_TOKEN frame. It would be mandatory to use both the token and connection ID if you wanted to use 0-RTT. I made a similar suggestion early on. The feedback I got from server implementers is that the value of such a connection ID approaches zero too quickly. There are so many topology changes in a cluster that a connection ID can be useless even on relatively short timescales. 0-RTT tickets might be valid for hours, but providing a connection ID isn't useful after minutes. That might have changed, so feel free to poll the list if you think that this is important, or you disagree with that assessment. |
It does make sense - in my response to the linked comment above I claim that 0-RTT cannot be routed in the general case. But in specific cases where a DC can distribute 0-RTT trust better than LB routing it makes sense. I don't know enough about 0-RTT trust formation to have a strong opinion. There are downsides to both cases. The risk is the 0-RTT mostly become useless and provides more RTT's rather than fewer. Idea: |
As a load balancer implementor, my primary consideration is knowing whether a particular bunch of octets is supposed to be server-generated or a random DCID. If I cannot tell the difference from the packet header (w/o performing crypto), I would prefer t stick with the assumption of "random" and then not have DCID change from the initial. (CID internal consistency validation would be performed on the DCID that claims to be server-generated, but it should not be the primary method of deciding whether a CID is be considered to be server-generated.) |
Currently it would be random. If there were a server negotiated DCID for 0-RTT then I'd assume it could be generally assumed that all 0-RTT initials are server generated DCID's. If it is not consitent, it would be useless as @igorlord suggests. |
Discussed in NYC; WG members had concerns about the viability of this, and there was little interest in pursuing it. Closing as a result. If you disagree, please take it to the list. |
@siyengar Also suggested one could now use the Token field in the INITIAL as a way to accomplish this feature. |
Yes that would make sense - it could even be a relatively slow distributed token lookup to land at the right place, then get a fresh DCID that matches live infrastructure. |
Transport doc says
But the original DCID is random and the server with the 0-RTT keys is at the DCID replied to the original handshake packet.
See also
#1507 (comment)
The text was updated successfully, but these errors were encountered: