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

[ianswett <[e-mail]>]

FYI, my experience with clocks is they're either noisy, and if so over very short timescales(<1ms) or they jump suddenly.  In the case of a sudden jump, any protection from largely ignoring the jump should be fine.

I like Kazuho's suggestion because it changes a case that's currently discontinuous(1us extra max ack delay and the RTT sample can jump tens of ms) into one that's continuous.   Discontinuities in congestion control and loss recovery tend to lead to weird corner cases.  The current pseudocode is what gQUIC currently does, which is why it's there, but especially now that max ack delay is explicitly communicated, I think Kazuho's suggestion is a good one.

There is the question of what to do if the specified ack_delay is larger than the value specified in transport params.  Possibly we should only adjust by min(ack_delay, max_ack_delay), and then if the alarm is always waking up late, SRTT will include that even though max_ack_delay is not?

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