Draft: draft-ietf-quic-multipath

Commentary: More specifically , if the receiver can not process an old  seq number , it MUST ignore it ( i.e. , no error ) . Also 
 Updated the PR to also include the case of a DCID sequence number greater than any sent ( connection error ) . 
 Somewhat related to ( that moved text that was ACKMP specific to all the multi path - specific frames ) , we currently state in the ACKMP section that number which was never issued ( i.e. , with a sequence number larger than the largest one advertised ) , it MUST treat this as a connection error of type MPPROTOCOLVIOLATION and close the connection . Should we also react the same way with PATHABANDON and  frames ? I would say yes , but would be great to agree on this . 
 I think so . It should lead to connection error . 
 At least we should react the same to all three frames . Not sure if there is a point in ignoring instead but I also think a connection error is right . 
 We may add a sentence to clarify that we should just ignore Multipath frames related to retired DCIDs , but I would suggest to add such a sentence at the beginning of the section introducing these frames , as this applies to all of them . 
 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 . 
 Look good to me
All multipath-specific frames relate to a Destination Connection ID
sequence number.  If an endpoint receives a Destination Connection ID
sequence number greater than any previously sent to the peer, it MUST
treat this as a connection error of type MP_PROTOCOL_VIOLATION.  If
an endpoint receives a multipath-specific frame with a Destination
Connection ID sequence number that it cannot process anymore (e.g.,
because the Connection ID might have been retired), it MUST silently
ignore the frame.
If an endpoint receives an ACK_MP frame with a Connection ID sequence
number which was never issued (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.