Change:
packet that is not newly acknowledged or not ack-eliciting. When RTT is calculated, the ack delay field from the ACK frame SHOULD <del> be limited to the max_ack_delay specified by the peer.  Limiting ack_delay to max_ack_delay ensures a peer specifying an extremely small max_ack_delay doesn't cause more spurious timeouts than a peer that correctly specifies max_ack_delay.  It SHOULD be subtracted from the RTT as long as the result is larger than the min_rtt.  If the result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored. A sender calculates both smoothed RTT (SRTT) and RTT variance (RTTVAR) similar to those specified in RFC6298, see on-ack-received. </del> <ins> be limited to the max_ack_delay specified by the peer by using a minimum of the two values.  Limiting ack_delay to max_ack_delay ensures a peer specifying an extremely small max_ack_delay doesn't cause more spurious timeouts than a peer that correctly specifies max_ack_delay.  It SHOULD be subtracted from the RTT as long as the result is larger than the min_rtt.  If the result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored.  Ignoring ack_delay when it would cause an RTT sample smaller than the current min_rtt prevents a peer from manipulating RTT samples below min_rtt at the cost of inflated RTT samples in the presence of persistent delayed acks. </ins> A sender takes an RTT sample when an ACK frame is received that <del> acknowledges a larger packet number than before (see on-ack- received).  A sender will take multiple RTT samples per RTT when multiple such ACK frames are received within an RTT.  When multiple samples are generated within an RTT, the smoothed RTT and RTT variance could retain inadequate history, as suggested in RFC6298. Changing these computations is currently an open research question. </del> <ins> acknowledges a larger packet number than before.  A sender will take multiple RTT samples per RTT when multiple such ACK frames are received within an RTT.  When multiple samples are generated within an RTT, the smoothed RTT and RTT variance could retain inadequate history, as suggested in RFC6298.  Changing these computations is currently an open research question. </ins> min_rtt is the minimum RTT measured over the connection, prior to adjusting by ack delay.  Ignoring ack delay for min RTT prevents intentional or unintentional underestimation of min RTT, which in turn prevents underestimating smoothed RTT. <ins> A sender calculates both smoothed RTT (SRTT) and RTT variance (RTTVAR) similar to those specified in RFC6298.  Note that computing smoothed_rtt does not use ack_delay for the first RTT sample, because doing so would result in a smoothed_rtt that is smaller than the min_rtt. On every newly acknowledged ack-eliciting largest acked: ~~~ latest_rtt = ack_time - send_time_of_largest_acked ~~~ First RTT sample: ~~~ min_rtt = latest_rtt smoothed_rtt = latest_rtt rttvar = latest_rtt / 2 ~~~ Subsequent RTT samples: ~~~ min_rtt = min(min_rtt, latest_rtt) ack_delay = min(ack_delay, max_ack_delay) if (ack_delay + min_rtt < latest_rtt): latest_rtt = latest_rtt - ack_delay smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * rtt rttvar_sample = abs(smoothed_rtt - latest_rtt) rttvar = 3/4 * rttvar + 1/4 * rttvar_sample ~~~ </ins> 6. QUIC senders use both ack information and timeouts to detect lost

Discussion:
Also clarifies the implications of ignoring ackdelay when it would result in an RTT sample less than minrtt.
From , NAME had the following suggestion for restructuring the RTT estimation section:
Does this mean that you cap the ACK Delay field to the value from the maxackdelay transport parameter with min()? That's what the pseudocode says, but "limit" is sufficiently vague that I wasn't sure. Especially since that has the effect of feeding massively inflated RTT samples into the estimator. ACK Delay will be large if the packet contains retransmissions. Shouldn't we be throwing out these samples rather than distorting them? I mean, that was my understanding of the outcome of , and it seems like this case is rare enough that it won't starve the RTT estimator too badly. I think that this means that the RTT calculation should be done with an ACK Delay of 0.
On your first point, this was an outcome of . Yes, it is a min, as the pseudocode says. For context, when was being discussed, two things were true that aren't anymore: (i) non-ack-eliciting packets were being used for the RTT computation, and (ii) we were using max(observed ackdelays) as the maxackdelay. We've since replaced that computation with the peer's explicitly stated maxackdelay in our RTO computations. So if you do get inflated ack delays, that's going to be because acks were being lost or the receiver took too long to send an ack. In either case, we want to capture the resulting increase somewhere, since the RTO should incorporate such potential delays. In , we decided to let the smoothedRTT EWMA estimator handle it. If it's rare, it shouldn't move the EWMA by much. If it's not rare, then the EWMA will capture it, and we will appropriately end up with a larger RTO. On your second point, yes, ack delay of 0 is what is meant there. Should there be more text?
Well, if I understand the first, you are saying that RTO won't be negatively affected by this. But I'm concerned about RTT. Excluding non-ack-eliciting packets changes the odds of encountering this, but that's all. I lost track in .

There were pictures of inscrutable graphs. What I think I will request here is text explaining the consequences of these tweaks. Clearer text. The text on the second just needs to be clearer.
That's fair. I think we should add text to explain the consequences.
Meta-level comments. The code and text look fine.