Original text:
The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the <del> congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet </del>  scheduler that decides, among the paths whose congestion window is <del> open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their precise definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. Note that the receiver could use a different scheduling strategy to send ACK(_MP) frames.  The recommended default behaviour consists in sending ACK(_MP) frames on the path they acknowledge packets.  Other scheduling strategies, such as sending ACK(_MP) frames on the lowest latency path, might be considered, but they could impact the sender with side effects on, e.g., the RTT estimation or the congestion control scheme.  When adopting such asymetrical acknowledgment scheduling, the receiver should at least ensure that the sender negotiated one-way delay calculation mechanism (e.g., QUIC- Timestamp). </del>  7.5.

Reviewer comments:
Let's give the facts to the implementers, without providing too specific guidance neither. and may also address .
Just to not forget this, but this is mostly editorial. Probably present first the ACKMP frame, and then PATHABANDON and PATHSTATUS Drop reference to I-D.liu-multipath-quic as the PATHSTATUS frame is now integrated in the draft. Based on and , and If we agree on , we could also drop the text in PATh_ABANDON stating that on any path, not only the path on which the referenced Destination Connection ID is used.
We probably need to add some text in the scheduling considerations where control frames (PATHSTATUS, PATHABANDON, but also MAX_DATA,...) should be sent on a good working path, ideally with low latency.
I would say the same applies to ACK_MP
For ACK we recommend (SHOULD) to send it on the same path because of RTT calculations and I believe the scheduling text discusses at already.
Thinking about this some more. I believe we should say NOTHING. The point of the standard is to specify expected behavior when a node receives protocol messages from its peer. The basic statement is that most frames, including control frames, can be sent on any path -- the only exception being PATH CHALLENGE frames and PATH_RESPONSE frames. So my preference would be: 1) say nothing, because the purpose of standards is to specify requirements for Interop, not provide guidance to implementors. 2) if we do say something, just say that these frames can be sent on any valid path, based on preferences of the application and the implementation.
As for ACKMP frames, the text says "ACKMP frame (defined in ) SHOULD be sent on the same path as identified by the Path Identifier. However, an ACKMP frame can be returned via a different path, based on different strategies of sending ACKMP frames." That's an OK compromise, leaving open the possibility for implementations to use any strategy they want.
Alternatively, spell out the considerations to make when picking a path? Does it matter, if so, why? This would be useful to know when new frames come along in the future and need to think for themselves how multipath might affect them.
Sure, but at this stage we have preciously little experience. For example, I have a user request to specify affinity between a stream and a path. I can certainly provide them an API to do that, but this is basically research. And then, affinity applies to stream frames, but whether it should be applied to control frames is debatable. I am concerned that the guidance that we provide will be so generic as not to be useful, while still requiring long debates and delaying the publication of the draft. I think guidance is best provided in research papers, and possibly in text books.
I agree we shoukd avoid the potential time sink. I wasn't suggesting guidance but rather a fairly succinct statement like "The path that frames are sent on is a local choice, which could effect the behavior or performance of the QUIC transport or delivery of application data. There is no guidance provided by this document on strategies for path selection for frames beyond the control frames for the multipath extension itself." And perhaps gathering consensus on that now avoids people asking the question in later review rounds.
NAME I agree. Your proposal is basically equivalent to my suggestion that "if we do say something, just say that these frames can be sent on any valid path, based on preferences of the application and the implementation." Your text is good.
Sorry, I did read your comment and immediately paged it out. Credit to you for proposing that option earlier
Looks good, but the description of congestion is imprecise. Either drop it or fix it.

Revised text:
The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the  <ins> congestion control scheme.  QUIC packets that increase the number of bytes in flight can only be sent when the congestion window allows it.  Multipath QUIC implementations also need to include a packet </ins> scheduler that decides, among the paths whose congestion window is  <ins> open, the path over which the next QUIC packet will be sent.  Most frames, including control frames (PATH_CHALLENGE and PATH_RESPONSE being the notable exceptions), can be sent and received on any active path.  The scheduling is a local decision, based on the preferences of the application and the implementation. Note that this implies that an endpoint may send and receive ACK_MP frames on a path different from the one that carried the acknowledged packets.  A reasonable default consists in sending ACK_MP frames on the path they acknowledge packets, but the receiver must not assume its peer will do so. </ins> 7.5.