Draft: draft-ietf-quic-multipath

Commentary: Fix issue and 
 For the transition from a " closing " state to a " closed " state In the path state figure in section 4.2 , I find the phrase " path idle timeout " a bit confusing , because right now this value is supposed to be equal to maxidletimeout , but should n't a transition from a " closing " state to a " closed " state be much quicker than that from an " active " state to a " closed " state since the first transition is just what we expect to happen ? 
 I think this is now fixed by . 
 In Section 4.3 we wrote : There are 2 problems in this figure : " Associated CID have been retired " should not cause the path turn into closed state , because in Section : So retiring associated CID only cause the resources belonging to the corresponding packet number space to be released , but not the whole path to be closed . In CID migration cases , endpoints just want to retire the old CID and use a new one , as path is defined as " refers to the 4 - tuple " in the current draft , this operation will not cause the whole path context ( including congestion control states , RTT measurements , etc . ) to be removed . closing is triggered by PATHABANDONED frame , and does not have dependency on CID retiring ( Although path closing would trigger the retirement of CID resource ) . So when pathstate transmit from " Closing " to " Closed " , the proper condition might be " Acknowledgement of PATHABANDONED frame received " or " Path 's draining timeout for at least 3 times the current PTO interval " . 
 First , regarding the transitioning from a " closing " state to a " closed " state , there will be a problem if we use the receipt of the ACK of a PATHABANDON as a condition for the transitioning due to possible out - of - order delivery . Suppose a client uses DCID S2 to on its first path to send three pkts with the packet number 100 , 101 , and 102 , where PATHABANDON frame is sent in packet 102 . However , due to the out - of - order delivery , it is possible that 102 is acked first , while packet 100 and 101 are still in flight . Therefore , at this point , we can not mark the first path as " closed " since it is also possible that the acks of those two packets will later return from the first path . Due to the above reasons , in the initial design , we say that the path should be closed after CIDs are retired . As shown in the path - closing figure ( Fig.3 ) in the draft , after the client makes sure that the packets ( 100 , 101 ) sent before PATHABANDON on path 1 are also acknowledged , it then decides that the CID S2 is no longer needed , and thus sending out the  frame . Second , regarding the transitioning from an " active " state to a " closed " state , yes , it is possible that we want to retire the old CID and use a new one , and I think the current figure is a bit confusing . The purpose of this transitioning is to handle exceptions and it basically says that when there are no available CIDs to use for communication on a particular path , we should close it . I think we can simply keep the " path 's timeout " as the condition because when there are no available CIDs , the path timeout will be triggered anyway . 
 I agree that the transitioning from " Active " to " Closed " should not be directly done if we retire the associated CID . We could instead have an intermediate " Idle " state in which as long as you have no associated CID , keep relevant recovery / RTT/ ... contexts . In general , I think it could be worthwhile to make a clearer distinction between the acknowledgment / packet number context and the recovery one . For instance , if for any reason a host changes the DCID used over a given path , it should still keeps track of packets sent with the previous DCID ( and thus possibly sent with a different packet number space ) . For the " Closing " to " Closed " transition , I tend to agree with  and I would not directly rely on the acknowledgment of the PATHABANDON frame to close my path . But as a sender , I can react to the acknowledgment of my PATHABANDON frame and send the RETIRECONNECTIONID frame . On the other hand , relying on 3*PTO to transition from " Closing " to " Closed " is probably more relevant than using the path 's idle timeout . 
 I 've just submitted PR for this issue , containing the suggestions from Yunfei and  . The core points for this modification : Retiring CIDs would not trigger path closure . If a path is idle timeout , endpoints should send PATHABANDON frame before closing the path , so the path state transition would be " Active " -"Closing " -"Closed " in this situation If a path is detected blackhole or ca n't be used for some reason such as the whole network environment failed , endpoints can close the path immediately , because sending PATHABANDON frame on this path seem to be useless . 
 your PR ( ) says While you wrote in your comment above that it might be useless to send PATHABANDONED . Am I missing something ?
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.
When a path reaches the "Closed" state, the endhost releases all the
path's associated resources.  Consequently, the endhost is not able
to send nor receive packets on this path anymore.
When a path reaches the "Closed" state, the endhost releases all the
path's associated resources, including the associated Connection IDs.
Endpoints SHOULD send RETIRE_CONNECTION_ID frames for releasing the
associated Connection IDs following QUIC-TRANSPORT.  Considering
endpoints are not expected to send packets on the current path in the
"Closed" state, endpoints can send RETIRE_CONNECTION_ID frames on
other available paths.  Consequently, the endhost is not able to send
nor receive packets on this path anymore.