Draft: draft-ietf-quic-multipath

Commentary: This PR removes the use of a single packet number space on multiple paths as a fully supported option . However , it currently does n't remove it entirely . Specifically , it moves the respective text for now into the appendix but still allows the reception of packets without a Connection ID on multiple validated paths , similarly as path migration is not strictly forbidden without connection ID . 
 yes I also opened issue for discussion ! 
 I updated the PR and removed the appendix for SPNP . Further this PR threats the use of the multipath extension without CID as an error new text is the following : 
 I created a PR that moves the single packet number space option into the appendix : This PR still support zero - length connection ID on the initial path and it also still supports reception of packets with zero - length connection ID ( given path migration with zero - length ID is also not strictly forbidden ) . However , it requires the sender to use a non - zero connection ID when opening an additional path and recommends to send non ack - elicting packet only over one active path . The intention is to leave the door open for experimentation but still make the spec shorter and more concise . However , I guess we could also decide to remove the single packet number space discussion entirely from this draft , or even allow zero - length connection ID packets only for migration but not for simultaneous use . 
 I have had a similar thought in the past . It really might be worth the reduction in complexity to just say you have to use a CID if you do multipath . I think I would be ok with that restriction . 
 I think it might be useful to get inputs from the audience to know whether we want to keep support for zero - length CID for basic multipath . Given the adaptations that single packet number space requires , I wonder if this should be a separate draft that would extend the basic one ( i.e. , this one ) . 
 This is more of a question , but is there a privacy concern by trying to establish a new path when zero - length CID is used ? states that : IIUC , when zero - length CID is being used on a multipath QUIC connection , paths shared by the connection would be trivially linkable , regardless of if a non - zero - length CID is used to establish a new path . Assuming that is the case , I think we have to discourage endpoints from using zero - length CIDs with multipath QUIC as well , even if we are to provide support for that . 
 I think we got sufficient consensus from IETF115 to remove support for single packet number space ( waiting for confirmation from the ML ) . For zero - length CID , we may still keep this issue open , but as an individual , I agree with  's viewpoint . 
 Why would the paths be " trivially linkable " ? In the normal case , they would have different client IP addresses -- how would the paths otherwise go different ways through the network ? FWIW , I think it is quite straight forward to use multiple PN spaces and zero - length client CIDs . 
 Closing this issue for now as PR was merged . We can open a separate new issue on the question if we still want to enable server - to - client zero - CID with multiple packet number spaces . 
 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 . 
 With my commit ( ) , LGTM . could you just double - check it ? If this is ok , I think we can merge . Yes , I approve . It looks very much like I remember of my first review of this PR , with nice fixes .
The use of this multipath extension requires the use of non-zero
Connection IDs in both directions.
This specification requires the sender to use a non-zero connection
ID when opening an additional path.  Some deployments of QUIC use
zero-length connection IDs.  However, when a node selects to use
zero-length connection IDs, it is not possible to use different
connection IDs for distinguishing packets sent to that node over
different paths.
Packet Number Space Identifier (PN Space ID): An identifier that
is used to distinguish packet number spaces for different paths.
It is used in 1-RTT packets and ACK_MP frames.  Each node
maintains a list of "Received Packets" for each of the CID that it
provided to the peer, which is used for acknowledging packets
received with that CID.
If the parameter is set to 1, both endpoints MUST use non-zero
connection IDs.  If an enable_multipath parameter set to 1 is
received and the carrying packet does not contain a non-zero length
connection ID, the receiver MUST treat this as a connection error of
type TRANSPORT_PARAMETER_ERROR (specified in Section 20.1 of QUIC-
TRANSPORT) and close the connection.
To open a new path, an endpoint SHALL use different Connection IDs on
different paths.  Still, the receiver may observe the same Connection
ID used on different 4-tuples due to, e.g., NAT rebinding.  In such
case, the receiver reacts as specified in Section 9.3 of QUIC-
TRANSPORT.
Not transmitting again ACK ranges that were present in an ACK
frame acknowledged by the peer.
Limit the total number of ranges sent in an ACK frame.
Limiting the number of transmissions of a specific ACK range, on
the assumption that a sufficient number of transmissions almost
certainly ensures reception by the peer.
Send multiple messages for a given path in a single socket
operation, so that a series of packets sent from a single path
uses a series of consecutive sequence numbers without creating
holes.
As soon as the negotiation of multipath support is completed,
endpoints SHOULD use ACK_MP frames instead of ACK frames for
acknowledgements of 1-RTT packets on path 0, as well as for 0-RTT
packets that are acknowledged after the handshake concluded.
The path ID for 1-RTT packets is the sequence number of the
Connection ID as specified in QUIC-TRANSPORT.  Section 19 of QUIC-
TRANSPORT encodes the Connection ID Sequence Number as a variable-
length integer, allowing values up to 2^62-1; in this specification,
a range of less than 2^32-1 values MUST be used before updating the
packet protection key.
Type 0: Refer to the connection identifier issued by the sender
of the control frame.  Note that this is the connection
identifier used by the peer when sending packets on the to-be-
closed path.  This method SHOULD be used if this connection
identifier is non-zero length.  This method MUST NOT be used if
this connection identifier is zero-length.
Type 1: Refer to the connection identifier issued by the
receiver of the control frame.  Note that this is the
connection identifier used by the sender when sending packets
on the to-be-closed path.  This method MUST NOT be used if this
connection identifier is zero-length.
Type 0: Refer to the connection identifier issued by the sender
of the control frame.  Note that this is the connection
identifier used by the peer when sending packets on the to-be-
closed path.  This method SHOULD be used by default.
Type 1: Refer to the connection identifier issued by the
receiver of the control frame.  Note that this is the
connection identifier used by the sender when sending packets
on the to-be-closed path.
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.
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 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.