maximum number of paths an endpoint should open

[kazuho]

At the moment, we state in section 1 that

If the 4-tuple changes without the use of a new connection ID (e.g. due to a NAT rebinding), this is considered as a migration event.

and in section 3 that

The transport parameter "active_connection_id_limit" [QUIC-TRANSPORT] limits the number of usable Connection IDs, and also limits the number of concurrent paths.

While each statement is true, they are misleading in conjunction.

The problem here is that when an endpoint opens paths as many as "active_connection_id_limit", all CIDs will be use. That means that when an unintentional migration (e.g., NAT rebinding) occurs, the peer cannot respond to the migration event. This is because RFC 9000 section 9.5 states that endpoints MUST NOT reuse a connection ID when sending from more than one local address and MUST NOT reuse a connection ID when sending to more than one destination address.

As a path forward, I think we should at least warn developers not to try to use paths as many as "active_connection_id_limit."

[kazuho]

Filed PR #231 that fixes the issue without adding new mechanism.

[mirjak]

I commented in the PR. What's happens in RFC9000 if a NAT binding occurs and there is no new available CID? You have to close the path? Maybe that's also something to discuss.

[kazuho]

@mirjak Thank you for your comments. That topic is covered correctly by RFC 9000 already (please see my comments on the PR).

[mirjak]

Thanks for the update!

I guess the other question here is if we want to further discuss, what to do if a migration events happens and no CID is available. I think with multipath if you still have an active path, you should probably send a PATH_ABANDON frame for the old CID. This also related to PR #198 and issue #188, however, this might need further discussion.