[quicwg/base-drafts] Definition of ack-delay is incorrect (#3970)

[Kazuho Oku <[e-mail]>]

__Problem statement:__

At the moment, the draft states that ack delay is _a variable-length integer representing the time delta in microseconds between when the ACK frame was sent and when the largest acknowledged packet was received by this peer_. ([transport draft; section 19.3](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-19.3-8.4))

I think that the definition is incorrect. Consider the case of a slow endpoint that needs to spend 10ms for processing one packet. When the true RTT of the network is 50ms, the RTT estimate of the peer would become 40ms, as by this definition, the slow endpoint would report an ack_delay of 10ms.

IIUC, we have thought that the issue is negligible as we have a mechanism using min_rtt, for detecting and ignoring excessive ack_delay values being reported. But, as stated in https://github.com/quicwg/base-drafts/issues/3927#issuecomment-665411499, I am becoming skeptical if that defense works well when the path is being utilized, as the true RTT when the path is congested tends to be greater than when the path is not congested, and because min_rtt would normally reflect the value of the latter. In case of the example above, the defense does not work if the non-congested RTT of that path was 25ms and if min_rtt reflected that value.

__Solution:__

The definition of ack delay should be changed to: _the amount of time an endpoint withheld an ack from the moment when it would have sent an immediate ack._

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