Draft: draft-lmbdhk-quic-multipath

Commentary: Please carefully review the text about abandon frames on the last active path . This is new and maybe not what you intended , however , because of potential crossing of abandon frames from each direction ( as mentioned by in the issue ) , I do n't think receiving an abandon frame on the last active path should be a protocol violation . 
 The text says that both endpoint can send an abandon frame . However , if I understand the current text correctly it only says that the receiving peer of that frame can remove its state as the sender of the abandon frame indicated it will not send any more packets ion that path . However , the sender of the abandon frame ca n't remove its state until it also receives an abandon frame from the other end . That would mean a path can " half - open " ... Do we need to say something that that the receiver of an abandon frame SHOULD also send an abandon frame in response ? Or MAY ? Or MUST ? Or is the path considered completely closed as soon as an ACK for the packet containing the abandon frame is received ? In this case we need to say that when an abandon frame is received , the receiver MUST not use that path anymore . I think we need to clarify that ! Please provide a PR or let me know what the intention was and I can write something ! 
 For me ,  means " please stop sending on that path , I may soon stop listening " . The peer should definitely stop sending on that path . It may want to keep listening for a short time , because some packets may still be sent out of order . It may also want to keep some context to process acknowledgement of packets previously sent on that path . The general guidance is to to wait for something like 3xRTO before dropping path management resource . I do n't think that we need symmetry , that both peers have to abandon the path before they can release resource . But we have to solve a potential path suicide problem . Suppose we have two paths , peer 1 abandons path , peer 2 abandon path . Now we have zero path , and the connection is closed -- unless the client promptly opens a new path . My original intention is that only the client ever sends an ABANDONPATH , since only the client can initiate a new path , which dodges the path suicide issue . 
 Good questions ! For me , the issue is that when an endpoint decides to close a path , it is probably due to that the path condition is getting worse , which also means that further communication on that path may fail . When we use non - zero CID , as we should have at least one path that is working ( if no path is working , the connection will be closed ) , and we are not constraint to send PATHABANDON frame on the same path that we want to close , the sender should be able to receive the ACK of PATHABANDON . But when we use null CID , we use pathidtype 0x02 , which refers to the path where the packet is coming from , and hence , we are constraint to send PATHABANDON on the same path we want to close . In such a case , it is likely that the ACK of PATHABANDON will not be received , resulting in the " half - open " problem . Therefore , we should say sth like " when the sender moves into the " ABANDONSENT " state , and after 3RTO , it should close the path even if it has n't seen the PATHABANDON sent from its peer " . 
 Also , regarding when a path is considered completely closed , the current intention is that a path is considered closed when both the sender - side and the receiver - side resources of that path are released . The sender - side resources can be readily released when PATHABANDON is acked ( We may need to retransmit the pathabandon ) . The receiver - side resources are released when the RETIRECID frame is received . However , when zero - CID is used , it is possible that an endpoint is not going to receive any RETIRECID frames , so the receiver - side resources are released 3RTO after sending out the PATH_ABANDON . 
 I created PR . I think this is the biggest issue we need to address and agree on before submission of -00 . So please review ! 
 Sounds good . I think the next feedback will come once we have implemented and tested the feature .
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 a
client abandons a path, the server will not receive any more non-
probing packets on that path.
Both endpoints, namely the client and the server, can close a path,
by sending PATH_ABANDON frame (see path-abandon-frame) which abandons
the path with a corresponding Path Identifier.  Once a path is marked
as "abandoned", it means that the resources related to the path can
be released.
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 receive 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
an 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
connection 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 sent 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 Section idle-time-close.
Retransmittable frame, that have previously been send 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.
The PATH_ABANDON frame informs the peer to abandon a path, and
release the corresponding resources.  An endpoint uses the sequence
number of the CID used by the peer for PATH_ABANDON frames
(describing the sender's path identifier).  More complex path
management can be made possible with additional extensions (e.g.,
PATH_STATUS frame in I-D.liu-multipath-quic ).
The PATH_ABANDON frame informs the peer to abandon a path.  An
endpoint uses the sequence number of the CID used by the peer for
PATH_ABANDON frames (describing the sender's path identifier).  More
complex path management can be made possible with additional
extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ).
PATH_ABANDON frames can sent on any path, not only the path
identified by the Path Identifier field.
PATH_ABANDON frames MAY be sent on any path, not only the path
identified by the Path Identifier field.