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

From: Kazuho Oku <[email-masked]>
Date: Tue, 28 Jul 2020 21:29:06 -0700

__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

---

From: ianswett <[email-masked]>
Date: Wed, 29 Jul 2020 05:48:01 -0700

This came up in #2596 and the resolution was along the lines of what you're describing, so I think this is a matter of clarifying the text.

-- 
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#issuecomment-665643098

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 29 Jul 2020 05:52:01 -0700

@ianswett Thank you for pointing that out. So glad to know that this is an editorial problem.

-- 
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#issuecomment-665644930

---

From: ianswett <[email-masked]>
Date: Wed, 29 Jul 2020 05:52:19 -0700

>From https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-measuring-and-reporting-hos

> An endpoint measures the delays **intentionally introduced** between the time the packet with the largest packet number is received and the time an acknowledgment is sent. The endpoint encodes this delay in the Ack Delay field of an ACK frame; see Section 19.3. This allows the receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed. A packet might be held in the OS kernel or elsewhere on the host before being processed. An endpoint MUST NOT include delays that it does not control when populating the Ack Delay field in an ACK frame.

So I think the text is there, but maybe a reference to this section from section 19.3 and some editorial cleanup would help.

-- 
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#issuecomment-665645071

---

From: ianswett <[email-masked]>
Date: Thu, 30 Jul 2020 13:49:30 -0700

Closed #3970 via #3971.

-- 
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#event-3605742067