0-RTT DCID Routing

[mikkelfj]

Transport doc says

Packets protected with 0-RTT keys use a type value of 0x7C. The connection ID fields for a 0-RTT packet MUST match the values used in the Initial packet (Section 4.4.1).

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)

[martinthomson]

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.

[mikkelfj]

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.

[martinthomson]

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.

[martinthomson]

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.

[mikkelfj]

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:
0-RTT token is delivered with a DCID token to use in new connections. This DCID is (typically) neither random nor as specific as a proper server generated DCID. This makes it possible to route 0-RTT to any compatible end-point. Perhaps this is what you mean by an ID in the NEW_TOKEN frame? It starts to get complicated, but I think it would work better.

[igorlord]

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.)

[mikkelfj]

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.

[mnot]

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.

[ianswett]

@siyengar Also suggested one could now use the Token field in the INITIAL as a way to accomplish this feature.

[mikkelfj]

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.