Re: ack delay in rx packets

[Subodh Iyengar <[e-mail]>]

@Ian Swett<mailto:[e-mail]> sending ACKs in response to packets or delay seems fine, and an implementation might choose to do that. If we have more opportunities to send an ACK and avoid an RTO on the peer, wouldn't that be better? Is the objective of sending packets only during timer or recv data to simplify the ack delay calculation logic?


Subodh

________________________________
From: Subodh Iyengar
Sent: Wednesday, April 25, 2018 9:11:15 AM
To: Ian Swett; Jana Iyengar
Cc: IETF QUIC WG
Subject: Re: ack delay in rx packets


My concern is this situation: a "receiver" had not seen the original ACK (the packet was lost), then the sender rtos and sends a large ack delay to compensate for the rto, the max filter for max ack delay would inflate the delay for future packet.


if latest_rtt - min_rtt  > ack_delay:

   max_ack_delay = max(max_ack_delay, ack_delay)


latest_rtt in this case would be rto_timer + rtt because the sender sends an ack after an rto.


The rtt cal So max ack delay would become the rto timer. Is this a correct characterization?


Subodh


________________________________
From: QUIC <[e-mail]> on behalf of Ian Swett <ianswett=[e-mail]>
Sent: Wednesday, April 25, 2018 9:09:39 AM
To: Jana Iyengar
Cc: Subodh Iyengar; IETF QUIC WG
Subject: Re: ack delay in rx packets

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dquic-2Drecovery-2D11-23section-2D3.1&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=vQP8b9xGAVAynYcZHdgaeS3tK7f1xcKRczLJy-IILfA&s=z__D443_wlVvybsHUk1ua_Ve_0v1RqsNH09OhpeVA7g&e=>

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]<mailto:[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]<mailto:[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