Draft: draft-ietf-quic-multipath

Commentary: This PR is to resolve issue . The description of the path - closing figure is rephrased for better clarity . The pathidtype field in the PATHABANDON frame is also in the figure to give an idea how the type is used . Moreover , one case for single PN is ( where the client receives zero - length CID while the server receives long CID ) . According to previous discussion , in the single PN case , only the client needs to send out a PATHABANDON . The server SHOULD stop sending new data on the path indicated by the PATHABANDON frame after receiving it . However , The client may want to repeat the PATHABANDON frame if it sees the server continuing to send data . It is optional for the server to respond with a PATHABANDON after it receives a PATHABANDON frame from the client . 
 There is one part I am afraid people might feel a little bit hard to follow : the three types of path identifiers in the  frame . Those three types of path identifiers were introduced in order to be compatible with zero - length CID use cases , so I think we might need two additional example figures ( like figure 3 in the current draft ) , one for ( non - zero length CID , zero - length CID ) and the other one for ( zero - length CID & zero - length CID ) . Do you think that is a good idea ? I can work on those figures if it does n't complicate the flow of the draft . 
 This might be indeed useful in the " Example " section . 
 Yes , please create a PR ! 
 I am editing the path closing figures with zero - length CID and single PN . Is it similar to what you have in mind ? { : #  - example - path - close2 title="Example of closing a path when the server chooses to use zero - length CID " } { : #  - example - path - close3 title="Example of closing a path when the both client and server choose to use zero - length CIDs . " } 
 In the case of single number space , we use ACK , not ACKMP . But in fact you do not need to draw the ACKs there , there is no special processing of ACKs required . Also , there is no need to wait for an idle timeout , which typically is 10 to 30 seconds . That 's too large . Do we really need to send " abandon path " in both directions ? If I think about it , the real concern is that client will send a PATHABANDON message , but some time later , due to differences in delay , etc . , the server receive data on the same four tuples . How does the server know whether it should create a new path or not ? In the single space case , the logical test may be to check the sequence numbers of the packet . If the sequence number of the new packet is greater than that of the path_abandon , then the client is reactivating a path that was abandoned previously . Maybe the client connected again to the same network , after some disconnected interval . The server can start sending on the reactivated path . If the packet number is lower than that of the path abandon , then the server should not reactivate the path . In the multiple space case , if the CID is defined , there is no ambiguity . 
 ACK works for me . I think we might also want to add a sentence in the Sec . of " one packet number space " explicitly specifying that " for single PN , use ACK instead of ACKMP " , and change some texts in the ACKMP frame section that is related to zero - length CID ( the current draft says " if the endpoint receives 1 - RTT packets with 0 - length Connection ID , it SHOULD use Packet Number Space Identifier 0 in ACKMP frames " . ) . I think in single PN , sending " abandon path " in both directions is helpful . When the client sends " PATHABANDON " , it promises not to send non - probing packets in the current activity cycle . It could send probing packets to reactivate the path a moment later if the client thinks the network environment has changed . After sending out " PATHABANDON " , the client should still be able to receive packets from the server for a while on that path because there may be the server 's inflight packets on that path . It was not until the client sees the server 's " PATHABANDON " , the client then knows that no more server 's data is to be expected except for some out - of - order packets . So after receiving " PATHABANDON " , the endpoint can start preparing to free memories and clear path stats allocated for that path . The time interval from seeing " PATHABANDON " to actually releasing relevant resources is going to be an important parameter , and yes , 10 - 30 seconds is too long . What would be a more appropriate number for this interval ? Does it imply that we need to track the packet number of the PATHABANDON for a path that is closed ? When a path is in a closed state , the server may reject any newly received packets unless it is a probing packet ( back to our path initialization process ) . In this way , it should be OK to forget any info related to that path in the last activity cycle . 
 In most similar situations , RFC 9000 uses a delay of 3xRTO . Note that in the " simple " case , the client can receive packets from the server on any tuple . There are no resource allocated per path for receiving packets . There will be local resource allocated for sending packets , congestion context for example . But not on for receiving : all packets can be decrypted and processed . If the client knows that it will not send , it can discard the resource allocated for sending without risking a side effect . 
 I changed the timeout to 3RTO . As the problem is similar to FIN - ACK&FIN - ACK when TCP closes , I kept the ACK in the graph ( because the pathidtype=2 refers to the path where the packet is traveling , we want to make sure it is acked before we close the path . ) . Regarding the resource , I think if we keep a unified receive record , which is not per - path , yes , we can discard the sending resources . But if we have some path stats ( e.g. how many packets received in total in this current activity cycle ) , we need to keep these data structures until we are sure that the peer is not going to send more packets on that path . Indeed , it depends on the implementation , but I feel it is generally helpful to have PATH_ABANDON sent in both directions . What do you think ? { : #  - example - path - close2 title="Example of closing a path when the server chooses to use zero - length CID " } { : #  - example - path - close3 title="Example of closing a path when both client and server choose to use zero - length CIDs . " } 
 I submitted PR . Let 's first have sth that we can start modifying . 
 addressed by PR 
 I think there is still a mismatch between the proposed examples and the definition of the pathidtype in Section 11.1 ( definition of PATH_ABANDON frame ) .
In Figure fig-example-path-close the server's 1-RTT packets use DCID
C1, which has a sequence number of 1, for the first path; 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 CID S3,
which has a sequence number of 3.  Note that two paths use different
packet number space.
The client initiates the path closure for the path with ID 1 by
sending a packet with an PATH_ABANDON frame.  When the server
received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame
in the next packet.  Afterwards the connection IDs in both directions
can be retired using the RETIRE_CONNECTION_ID frame.
fig-example-path-close1 illustrates an example of path closing when
both the client and the server use non-zero-length CIDs.  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 received packet's DCID over that path
(path identifier type 0x00), hence using the path_id 1.  Optionally,
the server confirms the path closure by sending an PATH_ABANDON frame
using the sequence number of the received packet's DCID over that
path (path identifier type 0x00) as path identifier, which
corresponds to the path_id 2.  Both the client and the server can
close the path after receiving the RETIRE_CONNECTION_ID frame for
that path.
fig-example-path-close2 illustrates an example of path closing when
the client chooses to receive zero-length CIDs while the server
chooses to receive non-zero-length CIDs.  Because there is a zero-
length CID in one direction, single packet number spaces are used.
For the first path, the client's 1-RTT packets use DCID S2, which has
a sequence number of 2.  For the second path, the client's 1-RTT
packets use DCID S3, which has a sequence number of 3.  Again, in
this case, the client is going to close the first path.  Because the
client now receives zero-length CID packets, it needs to use path
identifier type 0x01, which identifies a path by the DCID sequence
number of the packets it sends over that path, and hence, it uses a
path_id 2 in its PATH_ABANDON frame.  The server SHOULD stop sending
new data on the path indicated by the PATH_ABANDON frame after
receiving it.  However, The client may want to repeat the
PATH_ABANDON frame if it sees the server continuing to send data.
When the client's PATH_ABANDON frame is acknowledged, it sends out a
RETIRE_CONNECTION_ID frame for the CID used on the first path.  The
server can readily close the first path when it receives the
RETIRE_CONNECTION_ID frame from the client.  However, since the
client will not receive a RETIRE_CONNECTION_ID frame, after sending
out the RETIRE_CONNECTION_ID frame, the client waits for 3 RTO before
closing the path.