Draft: draft-lmbdhk-quic-multipath

Commentary: I just want to note that I used value 1 for multiple packet number spaces to bee compatible with what is already used by Alibaba . However , if that change it not a problem for Alibaba , this order is slightly nicer . 
 I took the following text from draft - liu : This basically makes the one packet number handling mandatory to implement as you also need it if multiple packet number spaces were negotiated but zero length CID is used . The alternative would be to say that you ca n't used zero length CID if multiple packet number spaces are negotiated . Also I 'm currently proposing enablemultipath=1 for multiple number space and enablemultipath=2 for one number space to be compatible with the draft - liu and the alibaba implementation . However if we think one packet number space is mandatory to implement , it would make more sense to have it the other way around and allow fallback to one packet number space , namely if the client ask for two packet number spaces but the server supports only one but would also lead to a successful negotiation . What do people think about this ? 
 As long as inter - op is allowed , I think it might be better to keep both PN space choices optional (  's proposal of using enable_multipath=1 or 2 works for me ) . The first thing is to allow people more freedom . If some implementors only want to use one option , they just need to implement one code branch . Second , single packet number space requires the modification of loss detection algorithm , the way how rtt is sampled ( the overall largest ack may not be the largest acked packet on a given path ) , and some delayed ACK strategies , which might take additional effort . People may also want to avoid round - robin scheduling in single PN as it creates a lot of holes in the ack range , so certain things regarding performance get coupled . Christian introduced many good practices and we are currently learning from it , so we probably need more experience on that . 
 Adding the option to negotiate is a very good solution at this point . It would be helpful to hear more people 's implementation experience . To avoid failure for interop tests , I suggest that we could negotiate the transport parameter like this : use 2 - bits in the value field for negotiating one or more PN spaces . 0x0 : do n't support multi - path 0x1 : only support multiple PN spaces for multi - path 0x2 : only support one PN space for multi - path 0x3 : support both one PN space and multiple PN space The client could send all these 4 values in the enable_multipath transport parameter which depends on what kind of modes it supports . If the server just support one mode(such as one PN space ) , it could return 0x2 so that the client knows how to do next . If the server support both , it could choose 0x1 or 0x2 as it prefers , and make sure that the server do n't return 0x3 as it need to decide which mode to choose . In 0x2 mode , the endpoints must not use 0 - length CID . Then for people who just want one PN space , it would be ok to just support 0x2 mode . For the other guys who do n't use 0 - length Connection ID and want to get less overhead for ack ranges , they could choose to use 0x1 mode . And for people who want to support both 0 - length CID and multiple PN spaces , they could choose 0x3 and of course it will add more modification in the implementation . Maybe this could meet everyone 's need for experiments . 
 any views ? 
 I agree with Yanmei 's proposal of 4 options 0 , 1 , 2 or 3 , although I have a slight preference for " the other way around " : Client Option Allowed server responses -------------------------------------------- 0x0 0x0 0x1 0x0 or 0x1 0x2 0x0 or 0x2 0x3 0x0 , 0x1 or 0x2 Receiving an unexpected value from the server should be a protocol violation . If the transport parameter is not present , the value defaults to zero . 
 Agree with Christian 's design for value definitions . Submitted PR for this issue . 
 As got merged , I think this is now resolved . 
 Actually I think this is not fully resolved . The initial question was about use of multiple packet number spaces and zero length connection ID . Do we now say that if multiple packet number spaces are used , zero connection ID can not be used ? If yes , that means we need to remove the text I 've cited in the initial issue description from the draft . And also add some text that " zero - length CID MUST not be used with enable_multipath=2 " . Or if we want to keep that option that basically means that you need to always implement also singe packet number handling even if use of multiple packet number spaces is negotiated , and then we should say that more explicitly in the negotiation section . To me it 's not fully clear which option you have agreed to now ... ? 
 I opened to track the remaining point .
If the peer does not carry the enable_multipath transport parameter,
which means the peer does not support multipath, endpoint MUST
fallback to QUIC-TRANSPORT with single path and MUST NOT use any
frame or mechanism defined in this document.
If the peer does not carry the enable_multipath transport parameter,
which means the peer does not support multipath, endpoint MUST
fallback to QUIC-TRANSPORT with single path and MUST NOT use any
frame or mechanism defined in this document.  If endpoint receives
unexpected value for the transport parameter "enable_multipath", it
MUST treat this as a connection error of type MP_CONNECTION_ERROR and
close the connection.