Clarify use of MAX_PATHS and client created new paths

[mirjak]

Issue raised in PR #292:

huitema 3 weeks ago

I think we should be a bit more prescriptive here. I would like MAX_PATHS to follow the same logic as MAX_STREAMS, and describe the number of paths that MAY be created by the peer. I would also like to exploit the asymmetry of clients and servers, in which only the clients create new paths. Something like:

1. The server send MAX_PATHS to raise the maximum path number that it is willing to accept.
2. The client sends MAX_PATHS to raise the maximum path number that it is willing to create.
3. The server sends MP_NEW_CONNECTION_ID up to the min of client and server MAX_PATHS
4. The client sends MP_NEW_CONNECTION_ID up to the min of client and server MAX_PATHS
5. The client picks a server provided connection ID to create a new path, send a PATH CHALLENGE
6. If the server receives the challenge, it picks a connection ID with the same path ID for sending the PATH RESPONSE

We have a set of error conditions:

- Server sends MP_NEW_CONNECTION_ID with path ID larger than client limit -- protocol error
- Client sends MP_NEW_CONNECTION_ID with path ID larger than server limit -- protocol error
- Server receives a PATH CHALLENGE before receiving MP_NEW_CONNECTION_ID for the path -- not an error, but the PATH 

CHALLENGE is ignored, no response. Or, response is delayed until MP_NEW_CONNECTION_ID arrives.
But we also achieve path_id symmetry, I guess. Although there is probably some additional complexity with NAT Rebinding.

** @michael-eriksson michael-eriksson 3 weeks ago

I agree, and this is more or less exactly how it is implemented in the Rask stack.

@huitema huitema 2 weeks ago

There is another issue regarding probing for new paths. When a client wants to create a new path, it is supposed to use a "new" path_id, select CID that match the path ID, send a Path Challenge, and wait for the Path Response. The Path Response may well never arrive. That means that the Path ID is "burned" for the client, but also for the server. But the server does not know, will not know until the client sends a Path Abandon. We should be clear that the client should do that. We should also clarify how the Path Abandon causes all the CID allocated for the path ID to be retired.

[mirjak]

There is a new PR now: #354

[mirjak]

As #354 is merged, that clarifies the use of MAX_PATHS, I will close this issue now.

There are two new related issues for further discussion:

• Currently we only recommend that one unused Path ID should be provided (not up to the min of both announced MAX_PATH values). This can be further discussed in Clarify how new CIDs are allocated #338

• If path validation fails, the path ID cannot be used anymore but the other end might not know. This is related to the discussion in Should we require explicit Abandon after path time-out? #366