Samples for RTT estimation

[goelvidhi]

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.

[ianswett]

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.

[janaiyengar]

For context, the entire paragraph is:

   For fairly modest congestion window sizes, research suggests that
   timing each segment does not lead to a better RTT estimator [AP99].
   Additionally, when multiple samples are taken per RTT, the alpha and
   beta defined in Section 2 may keep an inadequate RTT history.  A
   method for changing these constants is currently an open research
   question.

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 @ianswett (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).

[goelvidhi]

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.

[janaiyengar]

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.

[martinthomson]

@goelvidhi, can you take a look at @janaiyengar's 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.

[goelvidhi]

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.