Re: ack delay in rx packets

[Ian Swett <[e-mail]>]

Jana's right about ignoring the ack for RTT calculation if it doesn't
acknowledge a new packet, see section 3.1:
https://tools.ietf.org/html/draft-ietf-quic-recovery-11#section-3.1

If it did acknowledge a new packet because the previous ACK was lost, then
you end up with either a useless RTT, a useless max ack delay, or both.
Because of issues like this, I prefer sending acks in response to packets,
or within an alarm of packet receipt, rather than at other times.

On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar <[e-mail]> wrote:

> If the sender has seen a previous ack for the same largest received, then
> it should basically ignore this new ack. If not, the ack delay will be
> accurate... What concern do you see with having a large ack delay?
>
> On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar <[e-mail]> wrote:
>
>> We ran into very common cases where we might have all our data to send
>> already outstanding, so when a TLP and RTO alarm fires, we have no new data
>> to send, so we resend data that was in previous packets.
>>
>>
>> In the time that the RTO fires, we might not have received any new
>> packets, however want to send ACKs in this new packet as well. Since no new
>> packets were received, this ACK will have the same largest acked as the
>> previous packet.
>>
>>
>> One question came up as to what the ack delay of an ACK in such a rx
>> packet should be. We could technically set it to the time since receipt of
>> the packet, however with the new max_ack_delay computations, adding this
>> might screw up our estimate of the normal ack delay, so I don't really want
>> to do that. Is there a better option here, or does max_ack_delay not cover
>> this case?
>>
>>
>> Subodh
>>
>