Subject: [quicwg/base-drafts] Samples for RTT estimation (#2067)

From: Vidhi Goel <[email-masked]>
Date: Wed, 28 Nov 2018 17:10:37 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2067

---

From: ianswett <[email-masked]>
Date: Thu, 29 Nov 2018 01:45:43 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2067#issuecomment-442770464

---

From: janaiyengar <[email-masked]>
Date: Thu, 29 Nov 2018 19:41:36 -0800

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).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2067#issuecomment-443080711

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 30 Nov 2018 18:45:38 +0000 (UTC)

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2067#issuecomment-443300234

---

From: janaiyengar <[email-masked]>
Date: Fri, 30 Nov 2018 18:01:31 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2067#issuecomment-443390115