Draft: draft-ietf-quic-multipath

Commentary: My understanding is that if I am a receiver that wants to proactively cause a sender to stop sending , I should use the explicit way of sending a path abandon frame . The idle timeout handles the case when a receiver is unaware of a path change that leads to communication failure . If that is the purpose , as long as the receiver can receive packets in the sender - to - receiver direction and acknowledge on another path , it looks to me that we should still allow the sender to use that path . But I feel if we do that , we are diverging from the bidirectional nature of a path described in the draft , which worths more discussion . 
 I agree with that if you want to close a path , you should use the abandon frame . This sentence covers the case where a path was idle for a while and therefore should be closed silently as it might not work anymore anyway . However , if you have received packet on the path or have an indication that packets you 've sent on the path were received by the other end , the path is clearly not idle and working . I also agree with that that means you only know for sure that the path is still working in one direction and that might need further discussion . 
 This was discussed in issue and PR . 
 Regarding the maxidletimeout , RFC9000 says " To avoid excessively small idle timeout periods , endpoints MUST increase the idle timeout period to be at least three times the current Probe Timeout ( PTO ) . " As in multi - path QUIC , the PTO is per - path , when maxidletimeout is used to close a connection , it makes sense to set maxidletimeout = 3max(PTO1 , PTO2 ) . But when it comes to close a path , I am not sure if the timeout for path1 should also depend on the PTO of path 2 ? 
 I think there are two idle timeouts : the " connection idle timeout " and the " path idle timeout " . For the " connection idle timeout " , I agree that it should be at least 3PTO_max . Triggering this timeout closes the connection . For the " path idle timeout " , this might be a way to have a stronger guarantee to stop using paths ( closing them ) after some inactivity than the text proposed in . Still , if we define such a mechanism , we need to know whether all paths should have the same path timeout value or not ( in the latter case , a transport parameter might not be the best way ) . 
 I would avoid having a different timer for a path than for a connection . That would make the protocol more complex without a lot of benefits . If a host wants to use a shorter timeout per path than the connection timeout , it can simply define it and use a PATH_ABANDON frame to indicate that the path is abandoned . However , we need to be clearer in 3.2.3 to indicate that a path can be considered valid if either packets are received on that path or packets sent on that path are acknowledged ( possibly on another path ) 
 Presented at IETF-113 but no time for discussion . 
 I have submitted PR to resolve this issue according to the above discussions . 
 PR was merged but forgot to close issue ... 
 In 3.2.3 , we have the following paragraph : When more than one path is available , servers shall monitor the 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 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 ] . This paragraph implicitly indicates that we consider a path to be active if we send and receive packets on this path . This definition works well for MPTCP where each data packet triggers an ACK on the same path . In MPQUIC , a server could have two paths that it uses to send data . However , the client might decide to always send the ACKs on only one path ( e.g. the lowest delay one ) . In this case , the two paths are clearly active , but the server could consider the higher delay path to be inactive since it does not receive packets over this path . It could send PING frames to trigger data packets , but then it would need to send one PING every 3 RTT , which seams excessive . I would suggest to rewrite the text as follows ( I removed  , because I think the recommendation should be generic ): When more than one path is available , hosts shall monitor both the arrival of non - probing packets and the acknowledgements for the packets sent over each path . Hosts SHOULD stop sending traffic on paths whether either : ( a ) no non - probing packet was received in the last 3 path RTT or ( b ) no non - probing packet sent over this path was acknowledged during the last 3 path RTT , but MAY ignore that rule 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 ] . 
 The word " either " means that STOP sending becomes true If either ( a ) is true or ( b ) is true . If I understand correctly , the actual meaning is to use the word " both " here , instead . So stop sending if both ( a ) no non - probing packets received and ( b ) no packets was acknowledged . 
 Yes , I think this is a good clarification and yes " either " might be confusing here . 
 I commented on the PR . I do n't like the idea that receivers would have to stop acknowledging packets in order to signal preference to not use a path . We need to think that a little more . 
 So we have a choice : either say that nodes should regularly send non - probing packets over the path that they want to keep using , or if we do n't want that , accept the idea that acks on other paths show continuity , and require " abandon path " to terminate a path that is otherwise working , acknowledges packets , etc .. 
 Yes , I think the second option is what we are aiming for with the new text . Stopping ack'ing packets to stop someone sending on a path is wrong and is something you should never do . If you receive a packet successfully you should ack it ( also because that would otherwise confuse congestion control ) . But we have the abandon frame exactly for that case . However , it also seems wrong to me to require sending acks on the same path taen the data is received . So if you decide to always only send ack on one path and all payload data flows into one direction only over multiple paths , the current text would require you to send potentially unnecessary ping packets over each non - ack'ing paths or you would end up closing those paths which also is wrong as everything seems to work fine . So the question is really is , do we want to require pings in this scenario ( payload traffic over multiple paths but acks only on one path ) in order to ensure that all paths are usable bidirectionally ? I think that 's unnecessary overhead and believe  's proposed addition is the correct thing to do . 
 I can look at what I implemented in picoquic : If there is no traffic in either direction for the idle period , the path is automatically abandoned . If traffic is sent and acked , or traffic is received , the path is not considered idle . This is pretty much what  proposed . If there is a " timer loss " , and if there is an alternate , the path is put in a low priority list . The node will send ping and try get an ack . If no ack is received after N trials , the path is abandoned . If " abandon path " frame is received , the path is abandoned . 
 I marked this issue as editorial as we have an editorial PR for it . However , I open a new issue for the per path idle timeout discussion ( ) . Do we need another issue to clarify path closure or sending of keep - alive traffic ? However this might be covered in other parts of the draft already ... ? 
 The modified text looks good . Looks good to meThe text looks good to me .
When more than one path is available, servers shall monitor the
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
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.
When more than one path is available, hosts shall monitor the arrival
of non-probing packets and the acknowledgements for the packets sent
over each path.  Hosts SHOULD stop sending traffic on a path if for
at least max_idle_timeout milliseconds (a) no non-probing packet was
received or (b) no non-probing packet sent over this path was
acknowledged, but MAY ignore that rule 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.