Closed Yanmei-Liu closed 5 months ago
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.
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:
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.
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.
As the design required revision of the entire draft, this PR attempts to be a start point.