Change:
Simplify pathstatus frame with pathabandon frame following the discussion on issue. Error code and Reason Phrase are left TBD.
I actually think we should have keep stand-by. I think this was useful in MPTCP and it's not really related to scheduling. Stand-by only means: I won't use this path but please keep it open.
The current draft says "Servers SHOULD stop sending traffic on paths through which non-probing packet was received in the last 3 path RTTs, but MAY ignore that rule if it would disqualify all available paths". First, I believe there is a typo, where the "non-probing packet" should be "no non-probing packet". Second, 3 RTT is too short for our applications and we prefer a longer timeout. Maybe we want to add a new parameter (e.g. maxpathidle_timeout) to allow the server and client to negotiate?
I fixed the missing no. I took this text from Christian's draft. So maybe he can comment. NAME ?
I would suggest to leave the path closing problem for further work and indicate that the next version of the draft will define how a path can be closed by one of the endpoints.
There are two issues, path closing and packet scheduling. For path closing, the simplest solution is to use an idle timer, either the idle timer negotiated for the connection or a new parameter negotiated as part of multipath setup. For packet scheduling, the first rule is to not send data on paths that do not work, e.g., lots of packet losses, or maybe absence of ACK. This is basically the same issue as determining whether a connection is broken, just applied to a path. But that is not entirely sufficient, because the server needs to also infer whether the client still wants to use that path. The monitoring of non probing packets is just an heuristic. The server observes that if the client is not using the path, and deduces that it should not be using it itself. That's not a bad heuristic, but it requires the client to send some kinds of "keep alive" if it wants the server to continue using a path. We may debate how often that should happen. Maybe reuse the same timeout as for jettisoning paths. Another solution may be for the client to tell something like "please don't use that path anymore", but that requires adding a new frame as part of the core multipath specification. In draft-liu, this was done with a specialization of the "path status", setting the status to "Abandon". Maybe we should just use a simplified for of the PATH_STATUS, leaving out the complexities of managing priorities for the advanced scheduling drafts:
I prefer the second approach that Christian proposed, i.e., sending explicit signals like "abandon". But there is an issue with path id type 0x02 in the current draft, which refers to the path over which the control frame is sent or received. The current draft says " If both endpoints are using 0-length Connection IDs on that path, endpoints SHOULD only use type 0x02 for path identifier", so in this case, if a path is broken, we cannot send an explicit "abandon" signal for that path thru other paths, and we have to rely on implicit signals like an idle timeout. That means we may still want to negotiate the idle timer?
The client can always force the issue by dropping all packets received on an old path. They will not be acknowledged, and the server will automatically deduce that the path does not work. Of course, that is ugly...
Note that the "Abandon Path" would be a replacement or a simplification of the "Path Status" frame in the current draft. In my code, I only use the "Abandon" variant of the Path Status. I wonder whether we need alternative statuses like "standby", and whether we should define priorities here, rather than in a separate draft for advanced scheduling.
Yes, I agree. We should put the alternative statuses and priority in a separate draft on advanced scheduling.
I submitted PR on this issue.
This PR was merged.
Look good to me.I made a typo, see comment on closing this path. Apart from that, looks good.

Discussion:
Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is <del> used in multi-path control frames (etc.  PATH_STATUS frame) to </del> <ins> used in multi-path control frames (etc.  PATH_ABANDON frame) to </ins> identify a path.  By default, it is defined as the sequence number of the destination Connection ID used for sending packets on that particular path, but alternative definitions can be used if the

This proposal adds one multi-path control frame for path management: <del> PATH_STATUS frame for the receiver side to claim the path state and preference </del> <ins> PATH_ABANDON frame for the receiver side to abandon the path </ins> All the new frames are sent in 1-RTT packets QUIC-TRANSPORT.

3.2. <del> An endpoint uses PATH_STATUS frames to inform that the peer should send packets in the preference expressed by these frames.  An </del> <ins> The current draft defines PATH_ABANDON frame to inform the peer to abandon a path, and release the corresponding resources.  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ).  An </ins> endpoint uses the sequence number of the CID used by the peer for <del> PATH_STATUS frames (describing the sender's path identifier). </del> <ins> PATH_ABANDON frames (describing the sender's path identifier). </ins> <del> PATH_STATUS frame describes 4 kinds of path states: Abandon a path, and release the corresponding resource. Mark a path as "available", i.e., allow the peer to use its own logic to split traffic among available paths. Mark a path as "standby", i.e., suggest that no traffic should be sent on that path if another path is available. Mark the priority of a path, i.e, path 1 is weight 8, path 2 is weight 2, suggest that path 1 has higher priority than path 2, and peer should try to send more data in path 1. PATH_STATUS frame can be sent on any path, not only the path </del> <ins> PATH_ABANDON frame can be sent on any path, not only the path </ins> identified by the Path Identifier field. 3.3.

An endpoint that wants to close a path SHOULD NOT rely on implicit signals like idle time or packet losses, but instead SHOULD use <del> explicit request to terminate path by sending the PATH_STATUS frame. </del> <ins> explicit request to terminate path by sending the PATH_ABANDON frame. </ins> 3.3.1. <del> Both client and server can close a path, by sending PATH_STATUS 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. </del> <ins> Both client and server can close a path, by sending 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. </ins> 3.3.2.

that are not used anymore, and the server is supposed to provide replacements, as specified in QUIC-TRANSPORT. <del> In this example, if the client wants to send a PATH_STATUS frame to tell the server that it prefers the path with CID sequence number 1 (of the server's side), the client should use the identifier of the server (sequence 1) in PATH_STATUS frame. </del> 7.2. fig-example-path-close illustrates an example of path closing.  In

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 <del> use different packet number space.  (For the convience of distinguishing the CID sequence number and PATH_STATUS sequence number, we call the "PATH_STATUS sequence number" as "PSSN".) </del> <ins> use different packet number space. </ins> In scenarios such as client detects the network environment change (client's 4G/Wi-Fi is turned off, Wi-Fi signal is fading to a

9.1. <del> PATH_STATUS Frame are used by endpoints to inform the peer of the </del> <ins> PATH_ABANDON Frame are used by endpoints to inform the peer of the </ins> current status of one path, and the peer should send packets according to the preference expressed in these frames.  Endpoint use <del> the sequence number of the CID used by the peer for PATH_STATUS frames (describing the sender's path identifier).  PATH_STATUS frames are formatted as shown in fig-path-status-format. </del> <ins> the sequence number of the CID used by the peer for PATH_ABANDON frames (describing the sender's path identifier).  PATH_ABANDON frames are formatted as shown in fig-path-abandon-format. </ins> <del> PATH_STATUS frames contain the following fields: </del> <ins> PATH_ABANDON frames contain the following fields: </ins> Path Identifier: An identifier of the path, which is formatted as shown in fig-path-identifier-format.

Path Identifier Content: A variable-length integer specifying the path identifier. <del> Note: If the receiver of the PATH_STATUS frame is using non-zero </del> <ins> Note: If the receiver of the PATH_ABANDON frame is using non-zero </ins> length Connection ID on that path, endpoint SHOULD use type 0x00 for path identifier in the control frame.  If the receiver of the <del> PATH_STATUS frame is using 0-length Connection ID, but the peer is </del> <ins> PATH_ABANDON frame is using 0-length Connection ID, but the peer is </ins> using non-zero length Connection ID on that path, endpoints SHOULD use type 0x01 for path identifier.  If both endpoints are using 0-length Connection IDs on that path, endpoints SHOULD only use type 0x02 for path identifier. <del> Path Status sequence number: A variable-length integer specifying the sequence number assigned for this PATH_STATUS frame.  There is a different path status sequence number space for each path. Available values of Path Status field are: 0: Abandon 1: Standby 2: Available </del> <ins> A variable-length integer that indicates the reason for abandoning this path. </ins> <del> If the value of Path Status field is 2 ("available"), the receiver side can use the Path Priority field to express the priority weight of a path for the peer. </del> <ins> A variable-length integer specifying the length of the reason phrase in bytes.  Because an PATH_ABANDON frame cannot be split between packets, any limits on packet size will also limit the space available for a reason phrase. </ins> <del> 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 Path Identifier with a sequence number equal to or higher than the sequence number of the incoming frame. </del> <ins> Additional diagnostic information for the closure.  This can be zero length if the sender chooses not to give details beyond the Error Code value.  This SHOULD be a UTF-8 encoded string RFC3629, though the frame does not carry information, such as language tags, that would aid comprehension by any entity other than the one that created the text. </ins> <del> PATH_STATUS frames SHOULD be acknowledged.  If a packet containing a PATH_STATUS frame is considered lost, the peer should only repeat it if it was the last status sent for that path - as indicated by the sequence number. </del> <ins> PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer should repeat it. </ins> 9.2.