Draft: draft-ietf-quic-multipath

Commentary: Should 
 I rewrote the text based on the suggestion from to discuss the case of zero - length CIDs . 
 Is there any reason why a new parameter is n't defined to negotiate maxpaths rather than reusing this existing parameter ? That design is much more cleaner . For example , the  paths would n'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 can not ( 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 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 do n'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 can not 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 "  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 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 .
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.