Draft: draft-ietf-quic-multipath

Commentary: you wrote : That sounds like you want to restrict the multipath extension to only one server address ( but potentially different paths from different clients address ) ... ? I think this restriction is unnecessary . Yes we do n't specify a way to learn server addresses but that does n't means that the client does n't know ( e.g. based on higher layer information ) multiple addresses of the server . What should we restrict that ? 
 However , can we maybe merge this PR as it is for now and you open a separate issue for your additional point ? 
  , That was my understanding of the sentences in the PR . Maybe I got it wrong . I think that we should discuss the role of preferred address in section 3 where we explain how paths can be opened . 
 Fine , let 's do it this way . 
 RFC9000 defines a list of transport parameters . 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 [ QUICWG ] These transport parameters apply to all the paths that compose a Multipath QUIC connection . We should probably confirm this in the mpquic draft to avoid any misinterpretation ( e.g. for maxidletimeout or ack delays ) . There are two transport parameters that could warrant some discussion : disableactivemigration : This transport parameter is incompatible with enablemultipath . An endpoint that receives both this transport parameter and a non zero enablemultipath parameter MUST treat this as a connection error of type  and close the connection . preferredaddress : RFC9000 , section 9.2.1 contains the following : Once the handshake is confirmed , the client SHOULD select one of the two addresses provided by the server and initiate path validation ( see Section 8.2 ) . A client constructs packets using any previously unused active connection ID , taken from either the preferredaddress transport parameter or a NEWCONNECTION_ID frame . As soon as path validation succeeds , the client SHOULD begin sending all future packets to the new server address using the new connection ID and discontinue use of the old server address . If path validation fails , the client  continue sending all future packets to the server 's original IP address . For multipath , do we want to be stronger than SHOULD select one ? Can a client create news paths towards the initial address or only to one of the preferred addresses ? Should the client use both addresses ( IPv4 and IPv6 ) if non - empty ? 
 Good point about " disableactivemigration " . I would read it as also disabling multipath . We do not need to say that " transport parameters apply to all the paths that compose a Multipath QUIC connection " . We are already inheriting that property from compatibility with path migration in RFC 9000 . Multipath support is an extension to QUIC v1 , not a new protocol , so we do not need to specify all the defaults . Same goes for the preferred address -- meaning does not change just because the nodes negotiate multipath . I would avoid debating " which server addresses the client can try " in the base multipath document . If we want the server to signal plausible addresses to the client , let 's have a specific document for that . 
 I would maybe add a sentence that this draft does not change the meaning of preferred_address and if that address could also be used for multipath is out of scope for this extension . 
 Regarding disableactivemigration : this can not be a connection error , as you can also send preferred address and after migration to the preferred address you can still use migration or multipath ( if negotiated ) . I think the definition in RFC9000 is still valid ; it means you ca n't send any packets from another address than the one used in the handshake . Which effectively means disabling multipath as well as Christian noted ( if not moved to another preferred address ) . I guess we could explicitly note that this draft does not change the definition of disableactivemigration . For your reference this is what RFC9000 says : 
 I created a PR in . Is this sufficient to address this issue or do we need to say more ? ? 
 The proposed PR sounds good to me , with the slight addition I mentioned .
This extension does not change the definition of any transport
parameter defined in Section 18.2. of QUIC-TRANSPORT.  Inline with
the definition in QUIC-TRANSPORT disable_active_migration also
disables multipath support, except "after a client has acted on a
preferred_address transport parameter" Section 18.2. of QUIC-
TRANSPORT.  Further, it is out of scope for this document to specify
if the old address can also be used for multipath after a client has
migrated to the address provided in the preferred_address transport
parameter.  However, it SHOULD NOT be assumed that it is possible to
use both addresses simultaneously without further confirmation from
the other host.