[quicwg/base-drafts] Ignoring ACK delay can result in wrong RTT calculations (#3350)

[kixelated <[e-mail]>]

I'm implementing the RTT estimation code in quic-recovery at the moment and I've run into a potential edge case with ACK delays. This is entirely hypothetical for the moment.


For example, suppose `min_rtt = 100` and our actual round trip time is 99ms, 100ms, or 101ms with equal frequency. This minimum RTT was calculated earlier (ex. handshake) but now the peer is delaying ACKs.

If we receive an ACK with `latest_rtt = 126` and `ack_delay = 25`, then `adjusted_rtt = 101`.
If we receive an ACK with `latest_rtt = 125` and `ack_delay = 25`, then `adjusted_rtt = 125`.
If we receive an ACK with `latest_rtt = 124` and `ack_delay = 25`, then `adjusted_rtt = 124`.

The computed result is `smoothed_rtt=117` and `rttvar=11`.
The "actual" result should be closer to `smoothed_rtt=100` and `rttvar=2/3`.

Any delayed ACKs sent faster than `min_rtt` will skew the results based on the `ack_delay`. This includes ACKs sent over a faster path. 

These RTT estimates can be brought closer to reality with a more accurate `min_rtt`. This can only be accomplished if the peer transmits an ACK with `ack_delay=0` and gets lucky.

However, a peer will only send an immediate ACK if it receives two ack-eliciting packets within `max_ack_delay` of each other (and the peer follows the RFC recommendation). Ironically, this is the situation where estimating the RTT is the most important, as the packet rate is too low for fast recovery.

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