Draft: draft-ietf-quic-multipath

Commentary: 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  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 was n'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 . 
 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 .
The transmission of QUIC packets on a regular QUIC connection is
regulated by the arrival of data from the application and the
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
scheduler that decides, among the paths whose congestion window is
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).
The transmission of QUIC packets on a regular QUIC connection is
regulated by the arrival of data from the application and the
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
scheduler that decides, among the paths whose congestion window is
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.