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

[janaiyengar <[e-mail]>]

@kazuho, I see two issues here that we are discussing, and I'll state them explicitly, to ensure that I'm not confused :-)

1. The issue you opened was about having an ack_delay reported that doesn't make sense, since it leads to a latest_rtt that is too small. This is what I was suggesting that we solve by ignoring the ack_delay that is too large.

2. The issue both of you have raised about ack_delay being larger than max_ack_delay is an important but separate one. The easiest way out, as @ianswett says, is to let SRTT and RTTVAR go up, by capping the actual ack_delay to min(ack_delay, max_ack_delay). After all, we include only max_ack_delay in the RTO computation... any additional actual ack delays should be accounted for somewhere and SRTT seems like a fine place. Alternatively, we could do an EWMA to manage ack_delay, but that is more mechanism.

Same page?

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