Change:
Fix issue
When using Identifier Types 0 or 1, the current text does not discuss how we should handle related path Identifier that the receiver cannot map to a path. When using Identifier Type 1, the Path Identifier corresponds to the sequence number of the Destination CID used by the sender to send packets on the related path, hence a sequence number of a source Connection ID of the receiver. When using Identifier Type 0, the Path Identifier corresponds to the sequence number of the Source CID of the sender, hence the sequence number of the Destination CID used by the receiver to send packets on the related path. While there are obvious values that could be considered as bad and may lead to, e.g., a MPPROTOCOLVIOLATION (e.g., a sequence number larger than any sequence number advertised), I don't think we should be as radical with regular values as they might have been retired meanwhile (also possible to face this with packet reordering). The worst edge cases I see are the followings. With type 1, the sender might send a PATHABANDON with the seq of the CID in one packet, and then the RETIRECID retiring that CID in a subsequent one, but the RETIRECID reaches the receiver before the PATHABANDON one. If the receiver drops state upon RETIRECID reception, it won't be able to map the PATHABANDON to the path. With type 0, the sender might send a PATHABANDON with the seq of the CID, but before it reaches the peer, the peer sends a RETIRECID retiring that CID. If the receiver drops the CID state upon RETIRECID sending, it won't be able to map the PATHABANDON to the path. Handling these edge cases with connection closure is clearly too strong. Still, ignoring or even acknowledging these PATHABANDON may have bad consequences. Silently dropping packets (i.e., not acknowledge the packet having PATHABANDON) will make the peer retransmit the frame (hoping it updates its path identifier) but could cause the loss/non-acknowledgment of accompanying frames (e.g., STREAM ones), and processing packet content without acknowledging it sounds odd. Acknowledging PATHABANDON that cannot be mapped to a path would make some desynchronisation about the status of the path between the peers (the sender now assumes the path is closed, but the receiver not). To address the type 1 issue, we could write some text stating that a sender cannot retire a DCID if a PATHABANDON containing the related sequence number is still in flight. But for the type 0, the fix is not obvious (I don't think we could have the same solution as in )...
One solution is to put the retired cid into a cidhistorylist and keep it for a while before its final deletion. In doing so, one can still find the cid-to-path mapping if the PATHSTATUS frame uses a retired cid. In this case, as long as the path that the peer wants to retire has no ambiguity, the current path close process can still work. If the receiver can no longer find the cid in both the active list and the history list, then it should treat this as a connection error of MPPROTOCOL_VIOLATION and close the connection.
Another solution would to to not change the path ID (see issue ). In this case all unknown path IDs could be handled as a connection error. Or is it anyway better to just ignore those frames (e.g. if completely outdated packet arrives and the path was already closed)?
I think the simplest solution is to just ignore Path Abandon that refer to abandoned connection ID sequence numbers. The problem is self correcting. If the connection ID is not used anymore, it is either because the path was actually abandoned (no problem), or because packets on the same 5-tuple are now sent with a different CID. In that case, the peer will see these packets arriving on the path that it wants to abandon, and can simply send a new Path Abandon.
Given that we agree that PATHABANDON relates to CID sequence numbers, we can probably apply the same approach to all multipath-specific frames (including ACKMP): if you receive such a frame with a CID sequence number you cannot map anymore, just ignore it.
This is somewhat related to . Section 12.2 states that The notion of "non-existing" packet number space ID is somewhat blurry and maybe too aggressive. If for some reason an ACKMP frame referencing an old, retired DCID sequence number arrives at the endhost, probably we just want to ignore it? And we could instead consider ACKMP related to a packet number space ID larger than the greatest advertised one being MPPROTOCOLVIOLATION?

Discussion:
ID of the 1-RTT packets which are acknowledged by the ACK_MP frame. If the endpoint receives 1-RTT packets with zero-length Connection ID, it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames. <del> If an endpoint receives an ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection. </del> <ins> If an endpoint receives an ACK_MP frame with a packet number space ID which was never issued by endpoints (i.e., with a sequence number larger than the largest one advertised), it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection.  If an endpoint receives an ACK_MP frame with a packet number space ID which is no more active (e.g., retired by a RETIRE_CONNECTION_ID frame or belonging to closed paths), it MUST ignore the ACK_MP frame without causing a connection error. </ins> When using a single packet number space, endhosts MUST NOT send ACK_MP frames.  If an endhost receives an ACK_MP frame while a single