Re: [quicwg/base-drafts] Reset min_rtt on persistent congestion (#3927)

[Kazuho Oku <[e-mail]>]

> To summarize, I think talking about resetting min_rtt might be fine, though I am not sure if that discussion should be tied to persistent congestion.

To give a specific example, one problem that I know with the current definition of min_rtt is that it cannot detect and correct RTT estimate of a congested path.

The sole purpose of min_rtt is to discard excessive ack-delays being reported by the receiver. This works by capping the lower bound of adjusted_rtt to min_rtt. The problem here is that min_rtt is a value that is typically collected when the path is almost idle. Once the path becomes congested, the true RTT becomes much greater than min_rtt.

For instance, if RTT-on-idle is 10ms and if RTT-on-congestion is 50ms, min_rtt would be 10ms, and therefore cannot be used to correct RTT estimates when the peer reports an excessive ack_delay of, say 25ms. The RTT estimate would become 25ms in such case.

I tend to think that this might be a bigger problem of the original issue, and therefore that we should state that an endpoint can periodically re-collect min_rtt estimates, if we are to make a change to the current definition of min_rtt.

-- 
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/3927#issuecomment-665411499