Original text:
4.3.2.  Receiving a RETIRE_CONNECTION_ID frame causes the endpoint to discard the resources associated with that connection ID.  If the connection ID was used by the peer to identify a path from the peer to this either acknowledged or marked as lost, and finally retire the Connection ID. <del> 4.3.3. </del>  QUIC-TRANSPORT allows for closing of connections if they stay idle for too long.  The connection idle timeout in multipath QUIC is

Reviewer comments:
Should
I rewrote the text based on the suggestion from NAME to discuss the case of zero-length CIDs.
Is there any reason why a new parameter isn't defined to negotiate maxpaths rather than reusing this existing parameter? That design is much more cleaner. For example, the max paths wouldn't be ignored even when zero-length CIDs are in use. Unless I'm mistaken, the current design have to comply with the following from RFC9000: >If an endpoint issues a zero-length connection ID... and therefore ignores the activeconnectionidlimit value received from its peer. BTW, how the following MUST will be honored for the zero-length CID case:
From RFC9000 (Section 9.5), an endhost cannot (voluntary) reuse a given CID on different addresses. Since CIDs are the path identifiers, this already restricts the number of concurrent paths. Given that paths must be symmetrical, this should restrict the number of concurrent paths to the minimum advertised value of . Note that the actual limit can be lower than this, as you depend on your peer to have your CIDs. For the parameter, this is something we considered in early multipath drafts (such as draft-deconinck-quic-multipath-02). Such value would only be meaningful when it is lower than the advertised . And even in such case, it is difficult to enforce that limit. If you provide 8 CIDs to your peer and request to be 2, how would you do that? Especially when handling transient situations (i.e., stop using a path on a network A to use another on network B), the receiver might notice 3 paths being in concurrent use (especially if network B is faster than network A), even if the sender behaves nicely. On the other hand, if one host definitely wants to limit the number of concurrent paths, it can simply as most active CIDs. For the zero-length CIDs, I think there are two parts. If we consider one-sided zero-length CIDs while the other direction uses non-zero-length CIDs, the maximum number of paths is constrained by the value of the non-zero-length CID side. If we now consider both sides using zero-length CIDs, then I would keep the minimum of both values? RFC9000 states that the host can ignore because it will not send NEWCONNECTION_ID frames, but we can extend this meaning in the draft. In any case, it might be better to clarify this, and we will likely perform a strong editorial pass on the whole text once we get an agreement on .
I agree with NAME Having two limits instead of just one just introduces complexity with little benefit. Yes, the case of two endpoints both using zero-length CIDs may be under specified. But the deployments of that scenarios are going to be very limited. If the server is part of a frame and uses zero-length CID, the client is identified by its IP address and port. The load balancer will struggle to match the new IP and port of a new path with the original values used in connection establishment. I don't see how that could work. So we are pretty much left to peer to peer scenarios, in which the server is a single computer. Even there, the matching of the new IP and port with the original client requires a combination of guesswork and maybe trial decryption. If developers are ready to do that, they can probably invent a way to manage the path number...
I'm not sure to get why you say that CIDs are "path identifiers". Also, please note that an "address" in 9000 is defined as follows:
Sure, this reasoning is still valid independent of whether activeconnectionid_limit or a new transport metric is defined.
This same case can be considered when more than activeconnectionidlimit are used (including in transient situations you mentioned). What concerns me with activeconnectionidlimit is that the connection must be closed as per: while, with a dedicated path_max, new paths can be just discarded while maintaining the connection alive.
Agree. This is only possible when dedicated parameters are defined.
Noted.
I'm not sure to see complexities out there. Using connection IDs to infer per path specifics is not a clean design, btw.
Relying to previous comments: 1) the limits the number of CID that a peer MAY advertise at the same time. A peer MAY advertise "at most" this limit. 2) there is no guarantee that a peer will advertise "at least" the . For example, a node could decide to never advertise more than 3 CID, even if its peer's limit is 9. 3) if a node reuses a non-zero-length CID on a different path mimics, the peer is most likely to treat that as a "NAT rebinding" event. There will be an exchange of probes, after which the peer will retain either the old or the new path. Thus, there can never be more active paths than the . 4) Since a new path requires a new connection ID in each direction, the maximum number of paths cannot be higher than the lowest of the two advertised by both peers. I think the issue boils down to "how does a node refuse to establish a new path". Imagine a node with a hard limit to maximum two simultaneous paths per connection, but advertising 3 CIDs. With RFC 9000 the only option would be to ignore incoming challenges for new paths. The peer will see timeouts, and repeat the challenges a number of time before giving up. If the peer knew that the local node supports at most two paths, it might not bother sending new challenges in the first place, saving some time. But there are synchronization issues. The peer may or may not know how many paths are currently active. For example, one of the current paths may have been abandoned, and the peer does not know that yet. So if we create a "max path" mechanism, we also need some kind of synchronization mechanism. Or, we could add a soft-error mechanism of some kind, something like a "CHALLENGE_REFUSED" frame, maybe carrying an error reason. But we would have to work out the complexity, etc. Looks like something we could do later, maybe an extension on top of the basic multipath.
Fully Agree, Christian.
That's it! I'd like the mechanism to not lead to closing the connection when such new paths are being added but a limit is fired.
Let's not add additionally frame(s) now, but do we want to add some text about "how to refuse a new path"?
Actually, there is a pretty straightforward way to "refuse a new path" -- just send back an "abandon path" frame.
True. I think we should add some explicit text that you should send an abandon frame (on an existing path) to refuse a new path and not reply to oath challenge.
Looks good to me.

Revised text:
4.3.2. <ins> An endpoint may deny the establishment of a new path initiated by its peer during the address validation procedure.  According to QUIC- TRANSPORT, the standard way to deny the establishment of a path is to not send a PATH_RESPONSE in response to the peer's PATH_CHALLENGE. An endpoint that has negotiated the usage of the multipath extension MAY use an explicit method by sending on another active path a PATH_ABANDON frame containing the Path Identifier of the refused path, but only if the PATH_CHALLENGE arrives in a packet using a non- zero length Connection ID. 4.3.3. </ins> Receiving a RETIRE_CONNECTION_ID frame causes the endpoint to discard the resources associated with that connection ID.  If the connection ID was used by the peer to identify a path from the peer to this either acknowledged or marked as lost, and finally retire the Connection ID.  <ins> 4.3.4. </ins> QUIC-TRANSPORT allows for closing of connections if they stay idle for too long.  The connection idle timeout in multipath QUIC is