Re: [quicwg/base-drafts] Remove ack_delay_exponent TP (#2670)

[Nick Banks <[e-mail]>]

First, if the parameter ends up staying, I agree with @ianswett and I would just leave things as they are, with no changes (though maybe we update the default to 10?).

But I still haven't seen a specific answer to two things:

1) The endpoint setting the timers for loss detection is the one who knows the accuracy of the timer; not the one sending the ACK frame. So, shouldn't the endpoint that sets the timer tell it's peer what ack_delay_exponent to use, not the other way around?

2) Even in intra-DC environments, where RTT is nearly 0 ms, that doesn't change how accurate timers can be set. In the default case for Windows, for instance, 15.6 ms is still average accuracy a timer can get. At best, that can be reduced to 1 ms. But at that small of an interval, any kind of scheduling interruption will add extra delay too. So practically, I don't ever see sub-millisecond timers being viable. Therefore, why do we ever need sub-millisecond ack_delay values communicated over the wire? Any fractional delay would just be included in the rtt variance (and IMO, rightly so).

-- 
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/2670#issuecomment-490925674