"Path ID" needs to be clarified. Do both endpoints use the same path ID, or independently choose which path ID to use?

[mirjak]

Based on discussion in PR #292:

yangfurong [on Nov 22, 2023] (https://github.com/quicwg/multipath/issues/new#r1401920170)

First, I think the semantics of "Path ID" need to be clarified. For a specific bidirectional path, do both endpoints use the same path ID, or independently choose which path ID to use?

@qdeconinck qdeconinck on Nov 22, 2023

I would keep the same logic as we did until now, i.e., each endpoint independently choose the Path ID it should use over a path. However, this "Path ID" (Flow ID may be more appropriate) would remain stable over a given path, even if the CID change.

I have two concerns about forcing such synchronisation of Path ID:

- Clients may try to create paths with Path IDs that are never seen by the server. For instance, Path ID 0 works, and it wants to try two additional paths, respectively with Path ID 1 and Path ID 2. However, the network path tried with Path ID 1 does not work and the server only sees Path ID 2 packets. If the client finally retires its Path ID 1, should the server also drop all related resources about its Path ID 1?
- This would create issues if, for some use cases (like P2P), we would like the server to create paths to the client. What would happen if for some reason, both the client and the server try to open at the same time a path over the same network, but with different Path IDs?

@yangfurong yangfurong on Nov 23, 2023

Indeed, if both endpoints are allowed to initiate paths, it is better to not sync path IDs.

@michael-eriksson michael-eriksson on Nov 23, 2023

I would much prefer if paths had the same identifier in both directions, just like streams do. If also servers will be able to open paths, client-initiated path could use even path IDs and server-initiated path odd path IDs -- a direct reuse of the stream design.

@yangfurong yangfurong on Nov 23, 2023

> I would much prefer if paths had the same identifier in both directions, just like streams do. If also servers will be able to open paths, client-initiated path could use even path IDs and server-initiated path odd path IDs -- a direct reuse of the stream design.

It's actually another way to somehow ''split'' the path ID spaces of endpoints. It solves the second problem as @qdeconinck pointed out. The only thing is how we define the TPs which limit the number of concurrent paths. There might be some options here. For examples:

- We use one TP to indicate the number of concurrent paths that the sender is willing to accept. For instance, if both endpoints send ''2'', there will be four concurrent paths at maximum (each endpoint can initiate two paths).
- We use two TPs where one indicates the max number of paths to be accepted by the sender and another one represents the max number of paths the sender wishes to initiate. This design allows endpoints to negotiate the total number of concurrent paths while the former one just informs the local decision to a peer.

@huitema huitema on Nov 26, 2023

I think we need to get a consensus on the management of path identifiers. I also think that we would get much better clarity if the client and server ended up using the same path ID values. Something like:

1. The client proposes an initial number of paths, which limits how many path ID the server can "pre allocate" (to use @Yanmei-Liu terms)
2. Both the server and the client pre-allocate connection identifiers, with path ID lower than the proposed limits.
3. Client that starts a new path picks one of the server allocated CID, selecting the path ID.
4. Server receiving a packet referencing a not yet use path ID must reply with client-allocated connection ID mentioning the same path ID.
  - If the client has not yet allocated any such path ID, the server cannot send data on that new path.
  - the client can always provide a new CID in messages containing a path challenge.
  - the server can control how many paths will be open by simply limiting how many path ID it mentions.
5. "Abandon path(N)" is handled pretty much like connection close, but just for the path. Any peer can send it, but the path is only closed if both do, or if RTO pass.
  - if a path is abandoned, we should say what happens if the peer keeps using it. Drop the packets? Repeat the Abandon Path message?
6. Path ID cannot be reused. If a path_id is abandoned, all CID allocated for that path should be retired.
7. The client can use a MAX_PATH_ID frame to increase the number of supported paths.

[mirjak]

Do we actually have consensus that the same path ID is used in both directions? If so, can people review PR #315 please! Thanks!