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

[janaiyengar <[e-mail]>]

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