Draft: draft-ietf-quic-multipath

Commentary: Replace " maxidletimeout " with " a path 's idleperiod " in the IdleTimeout Section and make sure that the idle_period is larger than 3 times the path 's PTO . 
 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 ... 
 Just modified " least maxidletimeout milliseconds ( a ) ... " into " ... at least the period of the idle timeout as specified in { { Section 10.1 of QUIC - TRANSPORT } } ( a ) ... " It 's better to just modify the corresponding 2 lines , but it 's ok for me .
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.
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 the period of the idle timeout as specified in Section 10.1.
of QUIC-TRANSPORT (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.