Subject: Ack Delay

From: Timo Völker <[email-masked]>
Date: Fri, 17 Jan 2020 14:38:29 +0000

Hi everybody,

I have two minor issues with the text in the transport/recovery draft regarding ack delay.

1. Measuring Ack Delay

In quic-transport draft, the first sentence of section 13.2.5. tells me that the ack delay depends on the last received ack-eliciting packet.

   An endpoint measures the delays intentionally introduced between when
   an ack-eliciting packet is received and the corresponding
   acknowledgment is sent.

This does not match to my understanding of ack delay. That is, ack delay describes the time between an ACK frame was sent and the largest acknowledged packet (even if it is a non-ack-eliciting one) was received. I propose to remove "ack-eliciting" in this sentence.

2. Ack Delay scaling

In quic-recovery draft, sections 4.3. and A.6. describe how to use the value from the ack delay field of an ACK frame without mentioning the ack_delay_exponent. I propose to include the ack_delay_exponent in the pseudo code or, alternatively, add a note that mentions the ack_delay_exponent. Either of them would have helped me to interpret the value correctly.

Timo

---

From: Ian Swett <[email-masked]>
Date: Fri, 17 Jan 2020 13:50:51 -0500

Thanks, comments inline.

On Fri, Jan 17, 2020 at 9:38 AM Timo Völker <[email-masked]>
wrote:

> In quic-transport draft, the first sentence of section 13.2.5. tells me
> that the ack delay depends on the last received ack-eliciting packet.
>

> This does not match to my understanding of ack delay. That is, ack delay
> describes the time between an ACK frame was sent and the largest
> acknowledged packet (even if it is a non-ack-eliciting one) was received. I
> propose to remove "ack-eliciting" in this sentence.
>

I think your suggestion is a good one, though I may attempt a slightly
larger change to make the entire paragraph a bit clearer.

>
> 2. Ack Delay scaling
>
> In quic-recovery draft, sections 4.3. and A.6. describe how to use the
> value from the ack delay field of an ACK frame without mentioning the
> ack_delay_exponent. I propose to include the ack_delay_exponent in the
> pseudo code or, alternatively, add a note that mentions the
> ack_delay_exponent. Either of them would have helped me to interpret the
> value correctly.
>

https://github.com/quicwg/base-drafts/issues/3355 filed to add a note about
ack_delay_exponent.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 17 Jan 2020 10:13:00 -1000

There are two different usage of ack delay. The implementation has an internal concept of how long to wait before acking a packet; this is the delay between ack time and the oldest ack-eliciting packet. The ACK frame has an ACK delay field; this is the delay between ACK time and the highest-numbered acked packet, which may very well be non ack eliciting.

-- Christian Huitema 

> On Jan 17, 2020, at 8:51 AM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> 
> Thanks, comments inline.
> 
>> On Fri, Jan 17, 2020 at 9:38 AM Timo Völker <[email-masked]> wrote:
>> Hi everybody,
>> 
> I think your suggestion is a good one, though I may attempt a slightly larger change to make the entire paragraph a bit clearer.
>> 
>> 2. Ack Delay scaling
>> 
> https://github.com/quicwg/base-drafts/issues/3355 filed to add a note about ack_delay_exponent. 
>> 
>> Timo
>>