Re: [quicwg/base-drafts] compensation of ack_delay is fragile against errors (#2060)

[janaiyengar <[e-mail]>]

@ianswett: Responding to your comment ([here](https://github.com/quicwg/base-drafts/issues/2060#issuecomment-443213389)) and PR #2062. For (1), yes, that is true, but we have already put a stake in the ground: min_rtt is only driven by what a sender measures and not by reported ack_delay. Under that framework, no SRTT that is smaller than measured min_rtt will be valid. That is a consequence we know and hopefully we should be measuring true min_rtt often enough that this isn't a problem.

Basically, my core argument is this: SRTT is used for loss detection and potentially congestion control and pacing. 
- A too-small SRTT is more aggressive: it causes too-early loss detection and might cause a congestion controller that uses RTT samples to get a one-off min_rtt sample. It might also cause a pacer to go a bit too fast.
- A too-large SRTT is more conservative.

Given that this is a mis-reporting receiver, a natural consequence of mis-reporting should be poor performance, not more aggressive sending.

I still think the sender should ignore a computed latest_rtt sample which seems to be smaller than 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/2060#issuecomment-444348125