Draft: draft-ietf-quic-multipath

Commentary: The current text says that one has to wait for a the retire frame or 3 PTOs . However ( as also indicated in the states figure ) this should be at least 3 PTOs . This PR fixes this inconsistency . Further is add a reference to the definition to PTO and replaces RTO with PTO where the wrong term is used . I believe all these fixes address straightforward mistakes , however , if discussion is needed , we can of course also open an issue . 
 In 4.3.1 ( Use PATHABANDON Frame to Close a Path ) , we state that This is actually already said later in Section 8.2 . We could remove this duplicate mention . 
 By fixing the conflict , I also fixed .
We assume that the reader is familiar with the terminology used in
QUIC-TRANSPORT.  When this document uses the term "path", it refers
to the notion of "network path" used in QUIC-TRANSPORT.
To add a new path to an existing multipath QUIC connection, a client
starts a path validation on the chosen path, as further described in
setup.  In this version of the document, a QUIC server does not
initiate the creation of a path, but it can validate a new path
created by a client.  A new path can only be used once the associated
4-tuple has been validated by ensuring that the peer is able to
receive packets at that address (see Section 8 of QUIC-TRANSPORT).
The Destination Connection ID is used to associate a packet to a
packet number space that is used on a valid path.  Further, the
sequence number of Destination Connection ID is used as numerical
identifier in control frames.  E.g. an endpoint sends a PATH_ABANDON
frame to request its peer to abandon the path on which the sender
uses the Destination Connection ID with the sequence number contained
in the PATH_ABANDON frame.
Endpoints use Destination Connection ID Sequence Number field in
PATH_STATUS frame to identify which path state is going to be
changed.  Notice that PATH_STATUS frame can be sent via a different
path.  An Endpoint MAY ignore the PATH_STATUS frame if it would make
all the paths unavailable in a single connection.
Each endpoint manages the set of paths that are available for
transmission.  At any time in the connection, each endpoint can
decide to abandon one of these paths, following for example changes
in local connectivity or changes in local preferences.  After an
endpoint abandons a path, the peer will not receive any more non-
probing packets on that path.  Non-probing packets are defined in
Section 9.1 of QUIC-TRANSPORT.
The endpoint sending the PATH_ABANDON frame SHOULD consider a path as
abandoned when the packet that contained the PATH_ABANDON frame is
acknowledged.  When releasing resources of a path, the endpoint
SHOULD send a RETIRE_CONNECTION_ID frame for the connection IDs used
on the path, if any.
The receiver of a PATH_ABANDON frame SHOULD NOT release its resources
immediately, but SHOULD wait for the reception of the
RETIRE_CONNECTION_ID frame for the used connection IDs or 3 RTOs.
Usually, it is expected that the PATH_ABANDON frame is used by the
client to indicate to the server that path conditions have changed
such that the path is or will be not usable anymore, e.g. in case of
a mobility event.  The PATH_ABANDON frame therefore indicates to the
receiving peer that the sender does not intend to send any packets on
that path anymore but also recommends to the receiver that no packets
should be sent in either direction.  The receiver of an PATH_ABANDON
frame MAY also send an PATH_ABANDON frame to signal its own
willingness to not send any packet on this path anymore.
If connection IDs are used, PATH_ABANDON frames can be sent on any
path, not only the path that is intended to be closed.  Thus, a path
can be abandoned even if connectivity on that path is already broken.
If no connection IDs are used and the PATH_ABANDON frame has to send
on the path that is intended to be closed, it is possible that the
packet containing the PATH_ABANDON frame or the packet containing the
ACK for the PATH_ABANDON frame cannot be received anymore and the
endpoint might need to rely on an idle time out to close the path, as
described in idle-time-close.
Retransmittable frames, that have previously been sent on the
abandoned path and are considered lost, SHOULD be retransmitted on a
different path.
If a PATH_ABANDON frame is received for the only active path of a
QUIC connection, the receiving peer SHOULD send a CONNECTION_CLOSE
frame and enters the closing state.  If the client received a
PATH_ABANDON frame for the last open path, it MAY instead try to open
a new path, if available, and only initiate connection closure if
path validation fails or a CONNECTION_CLOSE frame is received from
the server.  Similarly the server MAY wait for a short, limited time
such as one RTO if a path probing packet is received on a new path
before sending the CONNECTION_CLOSE frame.
Both endpoints, namely the client and the server, can initiate path
closure, by sending a PATH_ABANDON frame (see path-abandon-frame)
which requests the peer to stop sending packets with the
corresponding Destination Connection ID.
The sender and receiver of a PATH_ABANDON frame should not release
its resources immediately, but SHOULD wait for at least three times
the current Probe Timeout (PTO) interval as defined in Section 6.2.
of QUIC-RECOVERY after the last sent packet before sending the
RETIRE_CONNECTION_ID frame for the corresponding CID.  This is inline
with the requirement of Section 10.2 of QUIC-TRANSPORT to ensure that
paths close cleanly and that delayed or reordered packets are
properly discarded.  The effect of receiving a RETIRE_CONNECTION_ID
frame is specified in the next section.
Usually, it is expected that the PATH_ABANDON frame is used by the
client to indicate to the server that path conditions have changed
such that the path is or will be not usable anymore, e.g. in case of
a mobility event.  The PATH_ABANDON frame therefore recommends to the
receiver that no packets should be sent on that path anymore.  In
addition, the RETIRE_CONNECTION_ID frame is used indicate to the
receiving peer that the sender will not send any packets associated
to the Connection ID used on that path anymore.  The receiver of a
PATH_ABANDON frame MAY also send a PATH_ABANDON frame to indicate its
own unwillingness to receive any packet on this path anymore.
PATH_ABANDON frames can be sent on any path, not only the path that
is intended to be closed.  Thus, a path can be abandoned even if
connectivity on that path is already broken.
Retransmittable frames, that have previously been sent on the
abandoned path and are considered lost, will be retransmitted on a
different path.
If a PATH_ABANDON frame is received for the only active path of a
QUIC connection, the receiving peer SHOULD send a CONNECTION_CLOSE
frame and enter the closing state.  If the client received a
PATH_ABANDON frame for the last open path, it MAY instead try to open
a new path, if available, and only initiate connection closure if
path validation fails or a CONNECTION_CLOSE frame is received from
the server.  Similarly the server MAY wait for a short, limited time
such as one PTO if a path probing packet is received on a new path
before sending the CONNECTION_CLOSE frame.
An endpoint may deny the establishment of a new path initiated by its
peer during the address validation procedure.  According to QUIC-
TRANSPORT, the standard way to deny the establishment of a path is to
not send a PATH_RESPONSE in response to the peer's PATH_CHALLENGE.
Associated Source Connection ID: The Connection ID used to receive
packets over the path.  The endpoint relies on its sequence number
to send path control information and specifically acknowledge
packets belonging to that Connection ID-specific packet number
space.
The endhost can use all the paths in the "Active" state, provided
that the congestion control and flow control currently allow sending
of new data on a path.  Note that if a path became idle due to a
timeout, endpoints SHOULD send PATH_ABANDON frame before closing the
path.
In the "Closing" state, the endhost SHOULD NOT send packets on this
path anymore, as there is no guarantee that the peer can still map
the packets to the connection.  The endhost SHOULD wait for the
acknowledgment of the PATH_ABANDON frame before moving the path to
the "Closed" state to ensure a graceful termination of the path.
The ACK_MP frame, as specified in ack-mp-frame, is used to
acknowledge 1-RTT packets.  Compared to the QUIC version 1 ACK frame,
the ACK_MP frame additionally contains the receiver's Destination
Connection ID Sequence Number field to distinguish the Connection ID-
specific packet number space.
Acknowledgements of Initial and Handshake packets MUST be carried
using ACK frames, as specified in QUIC-TRANSPORT.  The ACK frames, as
defined in QUIC-TRANSPORT, do not carry the Destination Connection ID
Sequence Number field to identify the packet number space.  If the
multipath extension has been successfully negotiated, ACK frames in
1-RTT packets acknowledge packets sent with the Connection ID having
sequence number 0.
As soon as the negotiation of multipath support is completed,
endpoints SHOULD use ACK_MP frames instead of ACK frames to
acknowledge application data packets, including 0-RTT packets, using
the initial Connection ID with sequence number 0 after the handshake
concluded.
ACK_MP frame (defined in ack-mp-frame) SHOULD be sent on the path it
received packet with the Connection ID of the packet number space it
acknowledges.  However, an ACK_MP frame can be returned via a
different path, based on different strategies of sending ACK_MP
frames.
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.
In order to guarantee the uniqueness of the nonce, the nonce N is
calculated by combining the packet protection IV with the packet
number and with the Destination Connection ID sequence number.
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.
fig-example-path-close1 illustrates an example of path closing.  For
the first path, the server's 1-RTT packets use DCID C1, which has a
sequence number of 1; the client's 1-RTT packets use DCID S2, which
has a sequence number of 2.  For the second path, the server's 1-RTT
packets use DCID C2, which has a sequence number of 2; the client's
1-RTT packets use DCID S3, which has a sequence number of 3.  Note
that the paths use different packet number spaces.  In this case, the
client is going to close the first path.  It identifies the path by
the sequence number of the DCID its peer uses for sending packets
over that path, hence using the DCID sequence number 1 (which relates
to C1).  Optionally, the server confirms the path closure by sending
an PATH_ABANDON frame by indicating the sequence number of the DCID
the client uses to send over that path, which corresponds to the
sequence number 2 (of S2).  Both the client and the server can close
the path after receiving the RETIRE_CONNECTION_ID frame for that
path.
As stated in introduction, when multipath is negotiated, each
Destination Connection ID is linked to a separate packet number
space.  This a big difference between implementations of QUIC as
specified in QUIC-TRANSPORT, which only have to manage three number
spaces for Initial, Handshake and Application packets.
Implementation of multipath capable QUIC will need to carefully model
the relations between paths and number spaces, as shown in fig-
number-spaces.
The path is defined by the 4-tuple through which packets are received
and sent.  Packets sent on the path will include the Destination
Connection ID currently used for that path, selected from the list of
CID provided by the peer.  Packets received on the path carry a
Destination CID selected by the peer from the list provided to that
peer.
The relation between CIDs and paths is not fixed.  A node may decide
to rotate the Destination CID it uses, a NAT may decide to change the
4-tuple over which packets from that path will be received.
Implementation will have to manage these evolving relations.
RTT measurements and congestion state are logically associated
with the 4-tuple.  They will remain unchanged if data starts being
received or sent through the same 4-tuple using new CIDs.
Implementations of loss recovery typically maintain lists of
packets sent and not yet acknowledged.  Such information, along
with the value of the next PN to use for sending, is logically
associated with the "Sender Number Space", and with the peer-
provided CID used for sending on the path.
Sending of acknowledgement requires keeping track of the PN of
received packets and of acknowledgements previously sent.  Such
information is logically associated with the "Receiver Number
Space", and with the CID used by the peer for sending on the path.
When the link between paths and CID changes, the information tied to
the now unused CID remains useful for some time.  For example, the
list of packet numbers to acknowledge maintained in the old receiver
number space could still be used to send ACK_MP frames for that
number space.  Similarly, the list of packets sent but not yet
acknowledged with an old sender number space can be used when
processing incoming ACK_MP frames for that number space.  Such data
should not be discarded immediately after a CID change, but only
later, for example when the CID is retired.
The sequence number of the Destination Connection ID used by the
receiver of the frame to send packets over the path to abandon.
The sequence number of the Destination Connection ID used by the
receiver of this frame to send packets over the path the status
update corresponds to.
A variable-length integer specifying the sequence number assigned
for this PATH_STATUS frame.  The sequence number MUST be
monotonically increasing generated by the sender of the
PATH_STATUS frame in the same connection.  The receiver of the
PATH_STATUS frame needs to use and compare the sequence numbers
separately for each Destination Connection ID Sequence Number.
Endpoints use PATH_STATUS frame to inform the peer whether it prefer
to use this path or not.  If an endpoint receives a PATH_STATUS frame
containing 1-Standby status, it SHOULD stop sending non-probing
packets on the corresponding path, until it receives a new
PATH_STATUS frame containing 2-Available status with a higher
sequence number referring to the same path.
Frames may be received out of order.  A peer MUST ignore an incoming
PATH_STATUS frame if it previously received another PATH_STATUS frame
for the same Destination Connection ID Sequence Number with a Path
Status sequence number equal to or higher than the Path Status
sequence number of the incoming frame.
The sequence number of the Connection ID identifying the packet
number space of the 1-RTT packets which are acknowledged by the
ACK_MP frame.