Draft: draft-ietf-quic-recovery

Commentary: I believe this covers the discussion on the issue . It also introduces some MUSTs which should 've always been there . I do n't have a strong opinion on the use of RFC 2119 language here , and I 'm happy to remove all of that language if folks think that 's better . I would like not to bikeshed this , but I would also like to be on a beach right now , enjoying a lovely drink and watching the sunset . 
 wrote the following in his WGLC review ( ): Splitting this off from as a potential design issue . 
 This seems like a reasonable thing to do . 
 I 'd support a can or a MAY , as an example when you might reset min_rtt , but I do n't think we need a SHOULD here . 
 minrtt is currently only used for filtering unexpectedly large ackdelay 's reported by the peer . If the path RTT truly inflates then the peer will be able to report much larger ackdelay values and get a much lower RTT sample accepted . But I do n't think this is a security problem in practice . The only other consideration is that in future QUIC implementations may reuse this computed value for other purposes like delay based congestion control . It 's hard to make a judgement call on how important it is to reset minrtt . I guess I 'd be happy with a SHOULD but I can live with a MAY . 
  made a good argument that persistent congestion could be declared due to an overly small RTT , so resetting minrtt could avoid an endpoint repeatedly declaring persistent congestion . That being said , the RTT samples also need to be too low to spuriously declare persistent congestion , so this is increasingly sounding like an attack scenario , rather than having a poor estimate of minrtt . I think a SHOULD is Ok now , but I 'd like to state the best rationale we have for why it 's a SHOULD and neither a MUST or a MAY . 
 I think there 's one tricky point in resetting the minrtt after handshake confirmation . That is that all the packets can be acked with delays . IIRC , one of the reasons we were happy with using minrtt for capping latestrtt is that Initial and Handshake packets do not have ackdelays . If we are to suggest that an endpoint MAY reset minrtt when persistent congestion is declared , I think we should consider the risk of not having good estimate of minrtt , as we would have during the handshake . 
 I do n't see that as a risk here .  does n't consider any discretionary delays . 
 That 's exactly the problem . will be inflated by , unless and until the peer sends an immediate acknowledgement . And until that happens , will as well . 
 I think that 's OK . In practice , immediate ACKs do happen , and even at low rates , this should resolve to a " true " minimum . And if it does n't , then you have worse performance than you might had otherwise . You have to have a pretty poor network ( or a terrible ACK generation regime ) for minrtt not to eventually resolve to a useful minimum . Explaining this risk is fine , but the endpoint that does this made the choice to throw out minrtt and that 's just a consequence of that . 
 On one hand I agree that we can expect to see immediate ACKs , especially when HTTP/3 is used . At the same time , I am not sure if resetting minrtt when observing persistent congestion is better than other cases where we might reset minrtt , but that we do not currently mention . Change of IPTTL could be one of the examples in this regard ( IIRC pointed out that we do not use that value for detecting path changes ) . To summarize , I think talking about resetting minrtt might be fine , though I am not sure if that discussion should be tied to persistent congestion . 
 To give a specific example , one problem that I know with the current definition of minrtt is that it can not detect and correct RTT estimate of a congested path . The sole purpose of minrtt is to discard excessive ack - delays being reported by the receiver . This works by capping the lower bound of adjustedrtt to minrtt . The problem here is that minrtt is a value that is typically collected when the path is almost idle . Once the path becomes congested , the true RTT becomes much greater than minrtt . For instance , if RTT - on - idle is 10ms and if RTT - on - congestion is 50ms , minrtt would be 10ms , and therefore can not be used to correct RTT estimates when the peer reports an excessive ackdelay of , say 25ms . The RTT estimate would become 25ms in such case . I tend to think that this might be a bigger problem of the original issue , and therefore that we should state that an endpoint can periodically re - collect minrtt estimates , if we are to make a change to the current definition of  . 
 Based on agreement on the resolution in , which introduces normative language , let 's mark this design . 
 Seems fine . I 'm not 100 % on the strength of the recommendation to reset after persistent congestion , but it 's sensible advice . The resetting of min RTT is also specified with LEDBAT or BBR , which differ from each other and from this proposed spec . This is a complex issue , because resetting min RTT in LEDBAT " because of congestion " is a variation of the latecomer advantage . But as long as the text applies only to RENO as specified here , then I am fine with it . I like the cautionary text . Just one suggestion but LGTM regardless . Thank you for working on this .
Paragraph (version A):
min_rtt is the minimum RTT observed for a given network path.
min_rtt is set to the latest_rtt on the first RTT sample, and to the
lesser of min_rtt and latest_rtt on subsequent samples.  In this
document, min_rtt is used by loss detection to reject implausibly
small rtt samples.
Paragraph (version B):
min_rtt is the sender's estimate of the minimum RTT observed for a
given network path.  In this document, min_rtt is used by loss
detection to reject implausibly small rtt samples.
Paragraph (version B):
min_rtt MUST be set to the latest_rtt on the first RTT sample.
min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest-
rtt) on all other samples.
Paragraph (version A):
The RTT for a network path may change over time.  If a path's actual
RTT decreases, the min_rtt will adapt immediately on the first low
sample.  If the path's actual RTT increases, the min_rtt will not
adapt to it, allowing future RTT samples that are smaller than the
new RTT to be included in smoothed_rtt.
Paragraph (version B):
The RTT for a network path may change over time.  If a path's actual
RTT decreases, the min_rtt will adapt immediately on the first low
sample.  If the path's actual RTT increases however, the min_rtt will
not adapt to it, allowing future RTT samples that are smaller than
the new RTT to be included in smoothed_rtt.
Paragraph (version B):
Endpoints SHOULD set the min_rtt to the newest RTT sample after
persistent congestion is established.  This is to allow a connection
to reset its estimate of min_rtt and smoothed_rtt (smoothed-rtt)
after a disruptive network event, and because it is possible that an
increase in path delay resulted in persistent congestion being
incorrectly declared.
Paragraph (version B):
Endpoints MAY re-establish the min_rtt at other times in the
connection, such as when traffic volume is low and an acknowledgement
is received with a low acknowledgement delay.  Implementations SHOULD
NOT refresh the min_rtt value too often, since the actual minimum RTT
of the path is not frequently observable.