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

[Martin Thomson <[e-mail]>]

>  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