Draft: draft-ietf-quic-multipath

Commentary: A new sentence is to clarify that when a new CID is used , packet number space 's largest_ack should be reset to None for the packet number encoding algorithm specified in RFC9000 . 
 Based on discuss in we need to clarify if the packet number is reset if the CID changes . If only the CID changes but not the 4 - tuple , the 4 - tuple can be used to map to a path and packet number space . If both changes ( the client reset the CID after an idle period and on the same packet a NAT rebinding happens ) , I guess you can / have to try the exiting packet numbers first ... however , this is anyway a case that needs more discussion . 
 In the presence of NAT , we can not use the 4 tuple to map to a path and packet number space . Not on the receive side . If we want to not deviate from RFC 9000 , then we ought to bring back the single number space design and make it work . I think I should write an experimental draft to do explain how . My implementation is pretty close to parity between single space and multiple space , but I never spent the time to completely explain the ACK sending logic and the loss detection logic , including how to properly estimate per path delays . And I would need to add an MP_ECN frame so we get proper ECN counts per path . I gave up on this in the interest of converging soon on an agreed solution . But instead , we are going in the weeds , revisiting past decisions . I guess I could just as well restart the single number design . 
 I do n't think we revisit past decision ( or where was that decided ? ) . This was so far underspecified in the spec and we need to clarify . I do n't have a strong option on either approach but I honestly do n't know what the best approach is . 
 This goes back to the decoding argument . When the CID changes , the sender can not always predict that the packet will be received on the same 4 tuple as packets sent before the change -- a NAT in the way may have a different idea . That means the receiver can not properly find the  PN used on the receiving path from the 4 tuple alone . Thus you must start a new numbering space , with the highest received PN at 0 . 
 The weed part is because a lots of the comments I see try a different model than either unique number space or CID based number space . They assume what I would call a " strong path ID " model , in which the path has a unique ID defined in a protocol exchange , and then we get a number space per path . But that strong path ID model will not work unless we change the packet header to insert a path ID . It also does not support NAT very well . Yet , the proposals keep coming , and they have to be explained out each time . This is slowing consensus a lot . 
 I agree that we should start packet number from 0 when we start a new number space . It is more robust and less error prone , and we probably want to clarify this in the draft . 
 Sorry to have raised this again but I actually did n't recognise that we discussed this in detail . I actually hope this is not slowing consensus but helps to make progress quickly . Again even if we discussed is before , we need to clearly define and explain this in the draft and in order conclude this discussion and avoiding coming it up again . So let 's do that ! I optimistic we can reach agreement quickly ! 
 A few more thoughts , just for completeness , not trying to push in any direction . I do n't think we necessarily need to couple the question of reseting the packet number and using a stable path i d. Resetting the packet number with a new CID makes decryption easier , however , after you have decrypted the packet you may still be able to assign to an existing path . Actually it is not a problem neither for decryption nor for path assignment , if only the 4 - tuple or the CID changes . The problem is that if the client changes the CID , it never can be sure if not also the 4 - tuple changes ( which can even be likely after an idea period ) . Therefore the client need to reset the packet number for easy decryption when it uses a new CID ( this is deviation from RFC9000 - just to note but that 's probably fine ) . However , to my understanding just changeing the CID and reseting the packet number without a change in 4 - tuple does n't necessarily mean that this will create a new path , e.g. the server does n't have to start validation and you do n't have to close the old path as it is the same . So while you need to update your mapping from CID to path ID , I do n't think the path ID has to change . This is the discussion we should have in . 
 One addition : decoupling the CID / packet number space from the path ID however means that we need to also have a packet number space i d for the MP_ACK frame , while using the path i d for the other frames . Actually I think this is not too bad because ACK frames contain information that relate to packets and the other frames contain information that relate to the path . 
 Discussion at author meeting : just add one sentence to clarify that packet number is changed / reset when a new CID is used ( even on the same path ) 
 Add PR . 
 Please use  's text !
When multipath is negotiated, each Destination Connection ID is
linked to a separate packet number space.  Each CID-specific packet
number space starts at packet number 0.  When following the packet
number encoding algorithm described in Section A.2 of QUIC-TRANSPORT,
the largest packet number (largest_acked) that has been acknowledged
by the peer in this new CID's packet number space is initially set to
"None".