Re: Ack Delay

[Christian Huitema <[e-mail]>]

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=[e-mail]> wrote:
> 
> 
> Thanks, comments inline.
> 
>> On Fri, Jan 17, 2020 at 9:38 AM Timo Völker <[e-mail]> wrote:
>> 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.
> 
> 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. 
>> 
>> Timo
>>