[quicwg/base-drafts] Including ACK delay in packet loss detection time threshold (#3951)

[Dirkjan Ochtman <[e-mail]>]

In https://github.com/djc/quinn/issues/815, I've been going through the handling of PTO and other timer-related code in the Quinn implementation to make sure that it is consistent and compliant with the spec. One issue I bumped on is whether/when the ACK delay is relevant to a particular timer. This seemed somewhat inconsistent to me in the code, so I dug through the recovery spec and found the following:

* [Time Treshold](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#time-threshold) for detecting packet loss says the time threshold is `max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)`, so it does not include the ACK delay. This seems surprising to me, as the ACK delay seems highly relevant in this case...

* [Idle Timeout](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-idle-timeout) says "To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the current Probe Timeout (PTO)."; it seems like the ACK delay is relevant here: we wouldn't want to consider a connection idle if we haven't received ACKs because they are delayed.

* [Failed Path Validation](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-failed-path-validation) says `validation_timeout = max(3*PTO, 6*kInitialRtt)`. However, path validation should be based on a `PATH_RESPONSE` frame, not an `ACK` frame, so including the `max_ack_delay` here doesn't seem relevant from first principles.

* [Closing And Draining Connection States](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-closing-and-draining-connec) says "These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY].", so I think this should keep the ACK delay as well.

So concrete questions I came up with:

* Should the packet loss detection threshold take the `max_ack_delay` into account somehow?
* Should the failed path validation timeout use a different calculation that doesn't include `max_ack_delay`?
* For closing/draining connection timers, does it make sense to include the `max_ack_delay`?


-- 
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/3951