Re: [quicwg/base-drafts] SHOULD NOT include platform delay in ack delay (#2786)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> @@ -302,15 +302,15 @@ continue making forward progress.
 
 ## Measuring and Reporting Host Delay {#host-delay}
 
-An endpoint measures the delay incurred between when a packet is received and
-when the corresponding acknowledgment is sent.  The endpoint encodes this host
-delay for the largest acknowledged packet in the Ack Delay field of an ACK frame
-(see Section 19.3 of {{QUIC-TRANSPORT}}).  This allows the receiver of the ACK
-to adjust for any host delays, which is important for delayed acknowledgements,
-when estimating the path RTT.  In certain deployments, a packet might be held in
-the OS kernel or elsewhere on the host before being processed by the QUIC
-stack. Where possible, an endpoint MAY include these delays when populating the
-Ack Delay field in an ACK frame.
+An endpoint measures the intentional delay between when a ACK-eliciting packet

_an_ ACK-eliciting packet?

> -delay for the largest acknowledged packet in the Ack Delay field of an ACK frame
-(see Section 19.3 of {{QUIC-TRANSPORT}}).  This allows the receiver of the ACK
-to adjust for any host delays, which is important for delayed acknowledgements,
-when estimating the path RTT.  In certain deployments, a packet might be held in
-the OS kernel or elsewhere on the host before being processed by the QUIC
-stack. Where possible, an endpoint MAY include these delays when populating the
-Ack Delay field in an ACK frame.
+An endpoint measures the intentional delay between when a ACK-eliciting packet
+is received and the corresponding acknowledgment is sent. The endpoint encodes
+this delay for the largest acknowledged packet in the Ack Delay field of an ACK
+frame (see Section 19.3 of {{QUIC-TRANSPORT}}).  This allows the receiver of the
+ACK to adjust for any intentional delays, which is important for delayed
+acknowledgements, when estimating the path RTT.  A packet might be held in the
+OS kernel or elsewhere on the host before being processed.  An endpoint
+SHOULD NOT include these delays when populating the Ack Delay field in an ACK
+frame.

Do we need to state something like "unless the delay is controlled by the stack"?

I ask this, because I'd assume that the delay should be taken into account even if it is introduced by the kernel or elsewhere, if it is "intentional" by the stack.

-- 
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/pull/2786#pullrequestreview-249669670