Clarify use of RETIRE_CONNECTION_ID frame

[mirjak]

RFC 9000 defines a way to request a peer to retire old CIDs, but only in-sequence (i.e., all CIDs with a sequence number less than n). This doesn't work when multiple CIDs are in use over different paths and you only want to retire one of them.

(issue originally raised by @michael-eriksson)

[yfmascgy]

I think you actually mean the Retire Prior To field in the NEW_CONNECTION_ID frame? In the RETIRE_CONNECTION_ID frame, the sequence number field is the connection ID being retired, so it should be fine, but yes, in the context of multipath, we should apply Retire Prior To field in NEW_CONNECTION_ID with caution. I am wondering shall we say that when multipath is in use, an endpoint SHOULD NOT use Retire Prior To when issuing a new connection ID, but instead, retire CID one by one with the use of RETIRE_CONNECTION_ID frame?

[michael-eriksson]

Yes, I mean that field. Note that the Retire Prior To field is a request to the peer to use RETIRE_CONNECTION_ID frames to retire CIDs issued by the first party. This means that you can not replace the Retire Prior To field with RETIRE_CONNECTION_ID frames as you suggest, since they work in "different directions".

https://www.rfc-editor.org/rfc/rfc9000.html#section-5.1.2-5

[qdeconinck]

Yes, there is no direct relation between the ordering in which you receive the CIDs and the order of removing them in a multipath context. I'm also not sure that an endhost is required to use available DCIDs "in-sequence" (i.e., it may use the CID with seq 2 before using the CID with seq 1).

Basically, let's consider the following example. Assume a two path scenario where the client uses DCID seq 0 on a path A and DCID seq 2 on a path B. At some point (e.g., the server might notice a NAT rebinding on path B), the server would like the client to retire the DCID with seq 2. The only way the server could force this behaviour is to send NEW_CONNECTION_ID frames with Retire Prior To set to 3, which would force the client to send RETIRE_CID frames. However, doing so would also force the client to retire DCID seq 0, which might not be required/needed/wanted.

FWIW, one of the previous multipath proposals proposed to let the CID issuer split the CIDs into "uniflow spaces", i.e., pre-assign CIDs to specific paths. Such a design enables retiring a specific CID using the Retire Prior To without affecting the other paths, as the CID seq is path-specific. However, such a solution adds more complexity than the current draft, which is likely not desirable.

In the end, I'm not sure with the current proposal the aforementioned issue is a big one, but it would indeed deserve some documentation/discussion in the draft.

[mirjak]

Actually if the other peer asks you to retire a CID that is currently in use, you can simply use a new CID on the path (this is true for both the uni- as well as multi-path case). As such this is also related to issue #160 and we should clarify these things.

[mirjak]

I created PR #171 to clarify what happens if no new CID is available. Maybe this helps here as well?

[michael-eriksson]

Actually if the other peer asks you to retire a CID that is currently in use, you can simply use a new CID on the path (this is true for both the uni- as well as multi-path case). As such this is also related to issue #160 and we should clarify these things.

Depending on the CID sequence numbers, it may be necessary for the peer to ask you to retire the CIDs also on some or all other paths (and thus also generate, install and signal a number of new CIDs) even if it just wants you to retire it on one of them. This is clearly suboptimal.

[mirjak]

I don't think that's problem. The question why would the CID issuer ask you to retire a CID. Usually this is probably some kind of clean up and in this cases it's actually the purpose that all old CID are replaces with newer ones. I believe this simply how it is intended. However, sure how this is actually implemented and used at the moment.

[qdeconinck]

Fixed by #171 that got merged.