Code change:
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 <del> 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. </del> <ins> 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. 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. 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. </ins> 5.3.

Related discussion:
text: I believe this covers the discussion on the issue. It also introduces some MUSTs which should've always been there. I don'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.
NAME 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 don'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 don'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.
Jana 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.