Change:
This requires changes to the ACK frame as well as packet protection as described in the following subsections. <ins> 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". </ins> 5.1. The ACK_MP frame, as specified in ack-mp-frame, is used to

Discussion:
A new sentence is added 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 cannot 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 don'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 don't have a strong option on either approach but I honestly don't know what the best approach is.
This goes back to the decoding argument. When the CID changes, the sender cannot 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 cannot properly find the max 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 didn'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 don't think we necessarily need to couple the question of reseting the packet number and using a stable path id. 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 doesn't necessarily mean that this will create a new path, e.g. the server doesn't have to start validation and you don'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 don'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 id for the MP_ACK frame, while using the path id 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 Quentin's text!