Fallback CIDs

[Martin Thomson]

When using codepoint 0b11, all bytes but the first SHOULD have no larger of a chance of collision as random bytes. The connection ID SHOULD be of at least length 8 to provide 7 bytes of entropy after the first octet with a low chance of collision. Furthermore, servers in a pool SHOULD also use a consistent connection ID length to simplify the load balancer's extraction of a connection ID from short headers.

I think that I understand what the intent of the randomness text is, but this could be a lot clearer. I can suggest words for this, but the next part is serious enough that I didn't want to touch this yet.

If the load balancer needs to extract the connection ID, then the length needs to be fixed. Ideally in the specification. However, the recommended handling for this (4-tuple routing) means that you don't need to make this fixed in a specification, only in a deployment. You should explain that rather than do rapid arm-waving.

FWIW, 62 bits of entropy is probably a little bit too light to be practical, but if this doesn't need to be fixed in a specification, then you only need to talk about the probability of collision and the birthday bound. The number of random bits $|CID|$ determines the odds of collision which is about 0.5 (i.e., way too damned high) at $\sqrt{|CID|}$. That all means that you probably want to recommend more than twice as many bits as you would need to assign to the number of connections you might expect to see, plus some margin. I don't think that 62 bits would be enough for a really big website. Maybe it is enough to cover those occasional glitches in configuration distribution, but I wouldn't want to be the cause of an outage, so I'd probably add a few extra to be safe.

[Martin Duke]

I'm not quite sure we need to fix the length here. As you said, if it's straight 4-tuple routing the connection ID length doesn't matter at all. If it's storing observed connection IDs in a map, those are first arriving in long header packets that provide the length.

As written in the paragraph, having many different lengths in the deployment would be both inefficient and increase linkability, but what's important is that the server pool decides on a length, not that the length is communicated to the LB.

I would imagine a "really big website" would understand the birthday problem and pick a bigger length. A smaller website is probably fine with 8B. I'm not sure I want to write up the birthday paradox in this section, but I'm certainly open to new text that indicates the tradeoffs more explicitly.

[Martin Duke]

Closing, assuming this response was satisfactory?