Should active_connection_id_limit be per path or per connection?

[mirjak]

With PR #292 we changed the active_connection_id_limit to be now per path. Is that really necessary or the correct thing to do?

If we can keep active_connection_id_limit to limit the total numbers of CID an endpoint is willing to maintain (because maintaining with or without a path ID associated to the CID is not really a difference), each endpoint can still control the maximum number of paths by announcing CIDs respectively.

[MikeBishop]

I would be inclined to mint a separate transport parameter here. The number of CIDs an endpoint is committing to manage is active_connection_id_limit if MP is not negotiated, but active_connection_id_limit times number of paths if MP is negotiated. An endpoint might want to select comparable total numbers for each case, but can't know in advance whether the peer will negotiate multipath or not.

[mirjak]

To give a bit more detail: active_connection_id_limit controls the maximum number of CIDs to ensure that the other end cannot force you to allocate a huge amount of memory to store the CIDs. This is still the same with use of a path ID; the only thing that is different is that you have to store a path ID in addition to the CID. However, controlling the max number of CIDs is still the way to control how much memory needs to be allocated.

Additional path state beyond the CIDs only need to be created when a path is actually opened. An endpoint needs to also control the maximum number of open paths, however, first of all active_connection_id_limit give a maximum for that as well and second when the same path ID is used in both direction each endpoint can control the number of maximum path individually without the need to communicate this to the other end by not issuing more path IDs.

In practice we should recommend that each endpoint locally decides how many paths it is willing to maintain at max and then we recommend to set the active_connection_id_limit parameter to local_max_path * 2 to still allow for migration on each path. Similarly the other end can look at the active_connection_id_limit parameter from the other peer and issue at least active_connection_id_limit/2 path ID if its own local limit allows that.

About @MikeBishop point, I don't think it's really needed to control the active_connection_id_limit value very tightly. It's more important to have a limit at all. So if you select a value for multipath support and only get single path, you might get more CIDs then you need to but its the same amount of ressources you committed to. I don't think that is really a problem.

Note that in this case it would maybe also make sense to maintain only one sequence number space for all CIDs instead of per path. This question can be decided independently, even though it supports the same idea, I opened issue #371 for the this.

[Yanmei-Liu]

I think it's clear that the active_connection_id_limit need to be per path. We've already discussed this issue in PR #292 and I'd like to provide more details about this issue:

1. The whole explicit path ID design require the CID's sequence number to be generated under per path(instead of generated for the whole connection in RFC9000), the Retire Prior To is also used for per path as part of the corresponding mechanism, or the core design is not able to work.
2. The transport parameter active_connection_id_limit describe the limit of active connection IDs for connection in RFC 9000, it's nature to transmit the limit for per path as we changed the CID allocation for per path.
3. If the active_connection_id_limit is still for the whole connection, there could be terrible situations that endpoints used too much CIDs on the previous paths, and don't have enough CID(s) for creating the new path. It could cause the CID allocation strategy to be more complicated.
4. Although we could set the active_connection_id_limit as (active_connection_id_limit_per_path * path_num), but it would be easy for attackers to generate more CIDs under one single path and try to force the peer to allocate more unnecessary memory.

On conclusion, it's simple and clear to use the TP active_connection_id_limit for per path. We could add more editorial texts to explain this part of design if needed.

[LPardue]

Discussed during interim: general sense that its ok to leave things as is. CID allocations strategirs came up, see minutes and chat for more details.

Outcome: issue consensus call to close this issue with no action