Original text:
result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored. <del> Like TCP, QUIC calculates both smoothed RTT and RTT variance similar to those specified in RFC6298. </del>  min_rtt is the minimum RTT measured over the connection, prior to adjusting by ack delay.  Ignoring ack delay for min RTT prevents

Reviewer comments:
Looks good to me, always nice to pull that note out of the reference and make sure people see it.
merging, so we can get this into -18
Based on the recovery draft, a largest newly acked packet should be considered as sample for the RTT estimation. This means that if the receiver sends 1 ACK for every packet, then every single ACK will be taken as sample for RTT estimation. But RFC6298 suggests to take at least one RTT measurement per RTT and also states, "Additionally, when multiple samples are taken per RTT, the alpha and beta defined in Section 2 may keep an inadequate RTT history." I think taking every single largest ACK into consideration doesn't comply with RFC6298.
The next sentence is: "A method for changing these constants is currently an open research question." Unless this research question has been answered, ideally in an RFC, I think we need to keep the text as is.
For context, the entire paragraph is: It is true that counting each packet causes us to retire history faster. Where this matters is when the sender might RTO or TLP too soon, since too late is usually not a problem. This might happen still, but our deployment experience so far has not shown this to cause any undue issues. Specifically, a QUIC sender detects and handles spurious timeouts better than TCP senders did when RFC 2988 (the precursor to RFC 6298) was written. It may be possible to tweak these constants to make them better for the "correct" timescale, but as NAME (and RFC 6298) points out, that is very much open research issue. The numbers in 6298 come from 2988 which was based on measurement studies from 1999 (the end-to-end path properties in the refs section of 6298).
I am worried if the new RTT samples could lower the TLP/RTO values significantly by over-writing the history faster especially if the receiver is sending an ACK for every packet. Tweaking the constants would require extensive experimentation. I am thinking maybe we can limit number of RTT samples per RTT to a finite number.
The easiest thing to implement is to use an RTT sample per packet. In the absence of newer information, it's hard to know what the right answer is. I'm open to any data you (or anyone else) might have that recommends better multipliers.
NAME can you take a look at NAME proposed resolution here? I know that it's not great, because it ties the depth of the history to the ACK rate, but we don't have a concrete alternative solution.
The note looks fine to me. Once we have some experience with RTT samples per ACK and how it impacts the history, we can make an informed decision.

Revised text:
result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored.  <ins> A sender calculates both smoothed RTT and RTT variance similar to those specified in RFC6298, see on-ack-received. A sender takes an RTT sample when an ACK frame is received that 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. </ins> min_rtt is the minimum RTT measured over the connection, prior to adjusting by ack delay.  Ignoring ack delay for min RTT prevents