Subject: [quicwg/base-drafts] Uncapped ACK Delay and RTT estimates (#4035)

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Aug 2020 15:42:44 -0700

When reported ACK Delay would cause the RTT sample to go below min_rtt, we ignore the ACK Delay.  In general, I think that this provides the right incentives to report delays accurately.  If the true minimum RTT is lower than the observed value, you add a few samples that are inflated by up to max_ack_delay.

However...during the handshake, where we don't have an effective cap on ACK Delay, so we effectively have unbound inflation.  And min_rtt is likely not well established.  Should we discard these samples instead?

-- 
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/4035

---

From: ianswett <[email-masked]>
Date: Wed, 19 Aug 2020 16:43:12 -0700

I think this is a potential issue, but I'd like to see this addressed in #3874 with some text to advise this is a potential issue that MAY be solved by ignoring RTT samples.

-- 
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/4035#issuecomment-676815610

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Aug 2020 21:48:38 -0700

Happy to have this rolled into #3874 as long as we can do so expediently.  I don't want a design issue floating around after this next batch of consensus calls.  @janaiyengar do you think that something could be done?

-- 
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/4035#issuecomment-677057747

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Aug 2020 22:16:44 -0700

I tend to think that if we are going to have some advice, it would be something like "MAY ignore the first ACK sample for Handshake and ApplicationData packet number spaces." IIRC, @ianswett suggested something like that somewhere.

Though, if we are going to have something like that, I think we also need to state that using a bad RTT sample might still better than relying on initial RTT of 333ms.

-- 
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/4035#issuecomment-677102320

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 19 Aug 2020 22:54:17 -0700

I've added some text in #3874 ([commit](952952a241916edbca9cd1a56cd633fc596c756d)) that should capture this point. 

-- 
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/4035#issuecomment-677210102

---

From: ianswett <[email-masked]>
Date: Thu, 20 Aug 2020 06:53:50 -0700

Thanks @janaiyengar that new text works for me.

-- 
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/4035#issuecomment-677678004