Change:
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

Discussion:
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.