Is MP_RETIRE_CONNECTION_ID needed?

[mirjak]

From discussion in PR #292:

huitema on Nov 20, 2023

I think adding an MP_RETIRE_CONNECTION_ID is unnecessary, and complicates the design. It is simpler to keep connection sequence number unique globally, and leave the RETIRE CONNECTION ID unchanged.

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

I think that a per-path CID sequence number space is simpler, in particular since the MP_NEW_CONNECTION_ID has a Retire Prior To field. Retiring CIDs (which could be in use) for other paths when you get new CIDs for a path seems complex and not very useful.

[mirjak]

Also from discussion in PR #292:

@huitema huitema on Nov 20, 2023

Retire Prior cannot be path specific. In practice, retire prior applies to all connection ID allocated before some event, such as rotation of the encryption key of connection ID used by the load balancer. In that scenario, repeating MP_RETIRE_CONNECTION_ID for every path would be very error prone.

@huitema huitema 2 weeks ago

OK, strike that. We are going for collection of CID per path (or per path ID), and identification of CID by the tuple {path_id, sequence}. So we pretty much need MP_RETIRE_CONNECTION_ID .

[mirjak]

Also from discussion in PR #292:

@huitema huitema on Nov 20, 2023

Retire Prior cannot be path specific. In practice, retire prior applies to all connection ID allocated before some event, such as rotation of the encryption key of connection ID used by the load balancer. In that scenario, repeating MP_RETIRE_CONNECTION_ID for every path would be very error prone.

@huitema huitema 2 weeks ago

OK, strike that. We are going for collection of CID per path (or per path ID), and identification of CID by the tuple {path_id, sequence}. So we pretty much need MP_RETIRE_CONNECTION_ID .

[mirjak]

@huitema sounds like we can close this issue. Can you confirm and go ahead and close?

[huitema]

Yes.

[Yanmei-Liu]

Yes. MP_RETIRE_CONNECTION_ID is needed. It's consensus