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

[janaiyengar <[e-mail]>]

You still want to have the if check, to avoid a large value due to overflow. Which unfortunately leaves us at the same place. I think what you want is:
```
    if (latest_rtt - min_rtt > ack_delay)
        latest_rtt -= ack_delay
    else
        latest_rtt = min_rtt
```

That said, I'm not sure that this is a good change. Basically if you have a bad clock at the receiver, this means that you constantly underestimate the latest RTT sample. That is bad for two reasons: (i) you miss any queues that might be building up because you underestimate latest_rtt, and (ii) the smoothed_rtt value that might be used for pacing uses this underestimated value.

OTOH, in the current world, if the receiver is consistently bad in reporting ack_delay, the sender becomes less aggressive than it should be, since the latest_rtt is larger than it should be. Pacing rate is lower, and any sender queueing estimate that uses latest_rtt hits detects a queue when there isn't one.  This isn't unsafe, this is just poor performance, which should be expected for a receiver with a poor clock.

-- 
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-442685693