[+] Explicit path identifier first shot

[Yanmei-Liu]

As the design required revision of the entire draft, this PR attempts to be a start point.

[Yanmei-Liu]

The biggest open question I have is what happens to the path identifier when peers have reached max_concurrent_paths. In your proposal, it sounds like path identifiers are reused. This might have weird corner cases when packets are delayed. The other way to implement this is to have path identifiers increment. We need to have a consistent view of how many paths are currently in use between the two peers.

That's an important point that we need to make it clear. I think it's better to reuse than increment, as we can add some limitation for the corner cases(e.g. Path Identifier can only be reused after 3 max PTOs after the path is abandoned and all the CIDs belonging to this path is retired). It's more friendly for resource limitation of endpoints.

If we use increment, then we need to discuss when to increase the max Path Identifier in the new connection IDs without breaking the limitation for max concurrent paths.

[Yanmei-Liu]

Thanks for doing this work. I think three key points need to be fixed:

• the CID should be uniquely identified by their sequence number, not by the combination of path-id and sequence number.
• we do not need MP_RETIRE_CID
• we should never reuse path-ID, because they are part of the cryptographic nonce.

@huitema I think the first 2 points are for the same design mechanism: whether the CID sequence should be allocated for per path. So basically we have 2 main issues here:

• whether the CID sequence and Retire Prior to should be allocated for per path, or the whole connection use the same sequence: For this part, my opinion is "per path" is better than "the whole connection". Because if different paths use the same sequence for CIDs, endpoints would not be able to use "Retire Prior To" to retire CIDs with continuous sequence. It will eventually retire CIDs from other paths and may have unexpected effects.
• "reuse" or "increase and no-reuse" for path-ID: For this part, I prefer "increase and no-reuse" for security consideration as Path ID are part of the cryptographic nonce. Then we will need mechanism for the limitation of max active Path IDs. Marten's design for PATH_LIMIT { highest path ID} frame might be an available way to solve this problem.

[marten-seemann]

I'm not sure how symmetrical path IDs would work in a world where both client and server probe paths. While the current document doesn't specify a more p2p-friendly QUIC, it would be nice if our path ID design didn't unnecessarily complicate the use in the p2p context.

[huitema]

I'm not sure how symmetrical path IDs would work in a world where both client and server probe paths. While the current document doesn't specify a more p2p-friendly QUIC, it would be nice if our path ID design didn't unnecessarily complicate the use in the p2p context.

For the client-server case, starting connections from the server will not work well because of NAT and firewall. That does not mean that we don't want the server to only accept connections at one address. The solution is to have the server send a frame "Call me at address IP:port". See for example the ADD_ADDRESS Frame in Quentin and Olivier's original draft. I think that a mechanism like that would work well for P2P as well, since we need something like ICE to start the P2P paths.

Symmetrical path ID make path management significantly simpler in the client-server case. I believe that symmetrical path ID would also simplify the design of an ICE-like mechanism in the P2P case.