Subject: [quicwg/base-drafts] ACK Delay interactions with RTT calculation (#2137)

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 21:38:03 -0800

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

Does this mean that you cap the ACK Delay field to the value from the max_ack_delay 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 #1438, and it seems like this case is rare enough that it won't starve the RTT estimator too badly.

>  If the result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored.

I think that this means that the RTT calculation should be done with an ACK Delay of 0.

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

---

From: janaiyengar <[email-masked]>
Date: Wed, 12 Dec 2018 22:18:13 -0800

On your first point, this was an outcome of #2060. Yes, it is a min, as the pseudocode says.

For context, when #1438 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 ack_delays) as the max_ack_delay. We've since replaced that computation with the peer's explicitly stated max_ack_delay 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 #2060, we decided to let the smoothed_RTT 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?

-- 
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/2137#issuecomment-446855221

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 15:14:00 -0800

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 #2060.  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.

-- 
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/2137#issuecomment-447155572

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 18:57:38 -0800

That's fair. I think we should add text to explain the consequences.

-- 
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/2137#issuecomment-447531792