Draft: draft-ietf-quic-multipath

Commentary: 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 can not 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 do n'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 wo n'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 wo n'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 can not 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 can not 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 do n'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   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 can not 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 ?
Packet Number Space Identifier: An identifier of the path packet
number space, which is the sequence number of Destination Connection
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.
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.
Packet Number Space Identifier: An identifier of the path packet
number space, which is the sequence number of Destination Connection
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.
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.