Change:
arrival of non-probing packets on the available paths.  Servers SHOULD stop sending traffic on paths through where no non-probing packet was received in the last 3 path RTTs, but MAY ignore that rule <del> if it would disqualify all available paths.  Server MAY release the resource associated with paths for which no non-probing packet was received for a sufficiently long path-idle delay, but SHOULD only release resource for the last available path if no traffic is received for the duration of the idle timeout, as specified in Section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle for the idle timeout, the connection is implicitly closed. </del> <ins> if it would disqualify all available paths.  To avoid idle timeout of a path, endpoints can send ack-eliciting packets such as packets containing PING frames Section 19.2 of QUIC-TRANSPORT on that path to keep it alive.  Sending periodic PING frames also helps prevent middlebox timeout, as discussed in Section 10.1.2 of QUIC-TRANSPORT. Server MAY release the resource associated with paths for which no non-probing packet was received for a sufficiently long path-idle delay, but SHOULD only release resource for the last available path if no traffic is received for the duration of the idle timeout, as specified in Section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle for the idle timeout, the connection is implicitly closed. </ins> Server implementations need to select the sub-path idle timeout as a trade- off between keeping resources, such as connection IDs, in use

Discussion:
To
The current draft says that "Servers SHOULD stop sending traffic on paths through where no non-probing packet was received in the last 3 path RTTs". However, it is possible that only a few data was generated in the past few RTTs due to app-limit conditions, and as a result, only one path was used. So I think, in section 3.2.3, we should suggest the use of some keep-alive mechanisms such as sending ping frames on a particular path if one is interested in keeping that path alive. Let me know what you think?
I fully agree this is an issue to be solved (). However, I think that before trying to find measures at the client side to take into account that server behavior, the text should provide a motivation for such restriction, especially that in typical scenarios the data is flying from the servers and that MPACK may be over any path (BTW, s/ACKMP frame Section 10.2/ACKMP frame (Section 10.2) I'm afraid the use of keepalives may not work in scenarios where the external addresses are not local to the client (and thus has no control on the paths that will be used), e.g., ~~ C/S negotiate multipathing by default. R distributes the load based on a local policy. S/C uses PATHCHALLENGE and PATH_RESPONSE to validate the paths. C does not control the path that will be used by R when forwarding packets.
Med, I am not sure that I understand the scenario that you are describing. There is a router R balancing the load over two paths, and using some NAT like functionality to rewrite the client source address, and presumably the client's port number. This is not supported by either RFC 9000 or by our multipath draft. The server will likely treat arrival from NAME and NAME as NAT rebinding, and the connection will end up using a single path.
R is multi-homed with PA (Provider Assigned) mode . In such mode, R uses the appropriate source IP address when forwarding packets over a given network attachment.

With RFC9000, and depending on the distribution logic used by R (per packet, per flow, round robin, maximize bw usage, RTT-based optimization, ...), there will be a path oscillation for this connection as the server will keep proceeding with path migrations each time it sees a new address (NAME NAME NAME and so on). Now, if both the client and server negotiates multipath, we don't have anymore this oscillation and the connection will use more resources. However, prematurely closing the connection nullifies the benefits of using multipath.
Actually, we will still have oscillation even if the endpoints negotiate multipath. There is not difference of behavior with RFC 9000 here, this scenario will be processed as NAT rebinding. This is not a supported scenario. QUIC is an end to end protocol. Intermediate routers cannot really tell whether the endpoints are supporting multipath, and should not depend on that. For that scenario to work, the alternate addresses NAME and NAME should be somehow managed by the client, and the client should be able to steer traffic towards one or the other.
Sure, the connection is end-to-end. The intermediate routers *do not interfere with the connection. However, an endpoint can still discover the availability of multiple paths (there are plenty mechanisms out there to discover the external IP addresses). Even without a discovery mechanism, many service offerings already allow controlling how flows are bound to external links (including bonding). Think about SDWAN, for example. These policies are configured on the CE router. If this scenario is not supported in this version of the protocol, there should be an applicability section where the target deployments are called out. Some text may be considered to discuss concretely when the client can negotiate multipath activation based on that applicability. Back to the initial issue, I think that more motivation is needed to justify withdrawing a path too prematurely.
The middlebox design that you describe closely resembles address spoofing attacks against QUIC that we discussed and tried to mitigate during the design, so it is no surprise that QUIC does not really support it. It would also break TCP connections, which means it is probably not deployed yet. My advice would be to not try deploy that.
It is deployed in (MP)TCP, but requires another proxy to glue the two connections and hide them to the sever.

In QUIC, we can have a much more cleaner design as the router does not have to interfere with the connection + we avoid the second proxy. That's said, I'm not pushing to have this included. We just need to be clear about the applicability scope.
By default, the applicability scope is the same as QUIC version 1.
By default, the applicability scope is the same as QUIC version 1.
Maybe, but I think having an architecture figure to illustrate the basic multipath case that is covered would be helpful. BTW, there is nothing in the current design that prevents multipath QUIC to be established over the scenario we discussed. I admit this is a side effect, not a desired goal.
Let's get back to the problem Yunfei mentioned, I just submitted PR for it. By the way, do we need a transport parameter to negotiate max path idle timeout? Like the connection maxidletimeout in RFC9000, to prevent one of the endpoints end up the path too early...
Why would you have different maxidletimeout for different paths?
The maxidletimeout defined in RFC9000 is used to close whole connection, but not the path. In order to close an idle path more precisely, one might need sth like maxpathidletimeout. I think we want all paths to have the same maxpathidletimeout values, which is used to control when a path should be closed when no non-probing packets was received on that path. Another approach is to use PING frame to keep a path alive.