MUST for checking if peer has spare Connection IDs

[kazuho]

Section 4.1 of the Multipath draft states: Following [QUIC-TRANSPORT], each endpoint uses NEW_CONNECTION_ID frames to issue usable connections IDs to reach it. Before an endpoint adds a new path by initiating path validation, it MUST check whether at least one unused Connection ID is available for each side.

I do not think it is possible to perform such checks reliably, as RFC 9000 allows the peer to start using spare Connection IDs at any moment.

In RFC 9000 section 5.1.1, we state that an endpoint that initiates migration and requires non-zero-length connection IDs SHOULD ensure that the pool of connection IDs available to its peer allows the peer to use a new connection ID on migration, as the peer will be unable to respond if the pool is exhausted.

Considering that Multipath is as extension of v1, I think it might just be sufficient to use what we already have (probably adding a pointer to the above text in RFC 9000) and calling it a day.

[mirjak]

I agree that checking the other side maybe not fully reliable to do but maybe we still need a MUST for the sender side, like "MUST use a new DCID when initiation path validation". Or is that also already covered in RFC9000? I couldn't quickly find it right now.

Also maybe we want to say more on the fact that active_connection_id_limit limits the number of active paths. So I guess you should check that parameter at least against the number of already open paths.

And finally an endpoint might also check the number of active paths again the number of active CID it provided to the peer. If all CIDs appear to be used by active paths and that number of provided values is be below active_connection_id_limit, it should sent a NEW_CONNECTION_ID frame before initiating validation.

[kazuho]

@mirjak

I agree that checking the other side maybe not fully reliable to do but maybe we still need a MUST for the sender side, like "MUST use a new DCID when initiation path validation". Or is that also already covered in RFC9000? I couldn't quickly find it right now.

Yes, it is my understanding that we already state that in RFC 9000. Quoting from section 9.5, an endpoint MUST NOT reuse a connection ID when sending from more than one local address, and an endpoint MUST NOT reuse a connection ID when sending to more than one destination address. To paraphrase, when sending to a new 4-tuple, a previously unused Connection ID has to be available.

Also maybe we want to say more on the fact that active_connection_id_limit limits the number of active paths. So I guess you should check that parameter at least against the number of already open paths.

Yeah, availability of spare Connection IDs limits the number of paths that can be opened, while active_connection_id_limit gives endpoints the expectation. I think the discussion of the expectation is covered by #221?

And finally an endpoint might also check the number of active paths again the number of active CID it provided to the peer. If all CIDs appear to be used by active paths and that number of provided values is be below active_connection_id_limit, it should sent a NEW_CONNECTION_ID frame before initiating validation.

That is already covered by RFC 9000 section 8.2, I think. Of course, I would not be opposed to adding a reference from the Multipath document, but considering that we are reusing the path establishment process of RFC 9000 maybe we do not need to repeat the point.