Low-Config CID creating huge problems with coexistence of configurations about load-balancers HOT 8 CLOSED

Of course, I was thinking of something else.

from load-balancers.

For the stateless algorithm, can we assume that servers are configured with a "current epoch" in a way that's properly synchronized with the LB, and that the epoch is encoded in the first byte of the "compliant" CID? Then the LB can do the following:

1. For Initial packets, assume non compliance. Treat CID as if they were part of the current epoch. Derive mapping from CID to server ID according to current epoch' key.

2. For all other packets, assume compliance. If epoch is "too old", drop the packet (server should have sent new CID to client.) Otherwise, derive mapping from CID to server ID according to specified epoch' key. (Or if CID in cache, use cache.)

from load-balancers.

Thanks Christian!

I am not sure I fully understand your proposal, but I will make some points:

1. quic-lb tries to distinguish only short-header and long-header packets to remain version invariant. There is no notion of Initials.

2. the second Initial carries a server generated CID, and 0RTT does not. so it is not so simple as sniffing the Initial codepoint.

3. IIUC the CR codepoint is much like your "epoch." I think the problem is when you are switching epochs; the LB must understand both and can't be sure which epoch any given server is on. Indeed, this is the heart of the issue.

Or perhaps I've wildly misunderstood your proposal.

from load-balancers.

So it boils down to a synchronization problem. The LB knows that a server is in epoch N+1 if it sees a CID from that server with the new epoch. So the transition will work like this:

1. Before transition, server use epoch N. LB sees from that server CID with epoch N.
2. At some point, LBtransitions to N+1.
3. If the server notices the LB's transition, it also moves to epoch N+1
4. Some time after that, the LB sees clients sending packets to that server with DCID marked for epoch N+1, at which points it knows server and LB are synchronized.

The main problem is that there is no synchronization signal from LB to server. The server cannot look at the ID and infer that the LB has moved to a new epoch.

It might be possible to use the retry frames to solve that. When it receives a new initial that would map to server X before confirmation that server X is on epoch N+1, the LB might send a retry to the client, suggesting a conforming DCID marked with epoch N+1. The server will receive the retried Initial, and learn that the new epoch has started. The idea probably needs some exploring, but that seems plausible.

from load-balancers.

Assuming handshakes are going on, yes, LBs can see what configs are operating. This is my option 2 but using egress SCID instead of ingress DCID, definitely an improvement.

Several drafts ago we moved away from explicit in-band signaling. Now we're headed back.

from load-balancers.

@ianswett and I had a long discussion about this problem. We reached a consensus that solution #6 was the least bad one. To summarize:

1. If a client-generated CID comes in that does not match a known config, do not add an SID entry at the LB or server.
2. If it does match a config codepoint, extract the SID accordingly and add it to the table.
3. There will be cases where the LB has a config codepoint, but the server does not. If so, the LB has "wasted" an entry but this is not a big problem. The reverse would be a problem, but it is already a requirement for the LB to have the superset of server configs.
4. When it first loads a config, the server will not have any SIDs. This should correct itself after a handful of connections, but until it does the CIDs it generates use the 4-tuple routing codepoint. When it does get an SID, it can retire the old ones across all connections. Thus, there are transitory states where a server can't support rebinding and migration.

This is still open for discussion, but I am working on a large PR to reorganize the whole routing section around dynamic SID allocation.

from load-balancers.

One Note: I believe it can support NAT rebinding, just not migration or changing CIDs. If a client unknowingly changes its address due to a NAT rebind, it does not change its CID.

from load-balancers.

No, because if it's the 4-tuple routing codepoint the LB ignores the rest of the CID. So it will route based on the (changed) 4tuple

from load-balancers.