Clarify interaction between PATHS_BLOCKED and PATH_NEW_CONNECTION_ID

[gloinul]

In the MP-QUIC interop testing at IETF 121 it was observed that an issue when testing PATHS_BLOCKED is that some servers where blocking path creation by not providing CIDS for some of the path IDs that it allowed. Thus, the client may desire to open more paths, there are agreed on path IDs, but lacks the CIDs. If the PATHS_BLOCKED is usable, how does one handle the situation when the server block the client by not providing CIDs?

I believe some clarifications and possible requirements are needed. I think there are two roads to take here:

1. Require that endpoints provide PATH_NEW_CONNECTION_ID when there are no CIDs for an unused PATH ID, as long as below MAX_PATH_IDS.
2. Create an equivalent or parameter on PATHS_BLOCKED indicating what is the issue.

[huitema]

For the record, the observation during interop was due to an off-by-1 bug in picoquic, which has since be fixed. But the situation could be repeated.

There are a couple reasons why an endpoint might delay provision of CIDs. The Path CID frames can only be sent after the max path id is negotiated, so there will always be a delay. That delay will be longer if packets are lost and need to be repeated. If the client is getting impatient, I think that something like "PATH_CID_BLOCKED" with a path_id parameter would make sense. If after sending that the client still does not receive the expected CID, it can escalate. Maybe abandon the path.

[gloinul]

So picoquiche had the off-by-one issue. QUICHE does not provide CIDs period up to the level of max_initial_path_ids. Thus, I think we need to think about how to deal with this situation. I agree that there are reasons for delaying provisioning CIDs for Paths, but what a peer can expect needs to be made clear.

[mirjak]

Based on the discussion at IETF 121 we will propose a PR to add a field to the PATHS_BLOCKED frame and an error code the PATH_ABANDON frame.