Signals of Initial Packet

[MikeBishop]

The Initial Packet type (versus Handshake) carries two signals:

• This packet initiates a new connection
• This packet carries a client-selected Destination CID

However, after a Retry, the DCID is server-chosen, not client random, so that promise isn't true. However, if we used Handshake as the client's packet after Retry (because the DCID is server-chosen), then the server would need to consider both Handshake and Initial packets as potentially initiating a connection.

Do we need to consider separating these signals? Given the larger (and potentially structured) DCIDs, the signal of DCID source might be unnecessary now.

[mikkelfj]

This is something that has been bothering me a bit - I think it is important to be able to trivially tell if a CID is initial random, server chosen, or client chosen. But I didn't get as far as to analyze all the possible outcomes.

If the situation is that a server receives a packet and needs to guess if the DCID is random or previously chosen then it is open to collision risk and may be forced to create longer CID's than necessary. It may also want to cryptographically verify the CID which also makes it longer.

The number of packet types is trivial to handle compared to ambiguity in the CID. This also ties into assumptions about unique tuples - which of course - I'd very much like to avoid depending on. I can see the point of stable tuple during handshake - but it need not be unique (p2p servers where both have a single port egress).