Re: ack delay in rx packets

[Subodh Iyengar <[e-mail]>]

It's possible that both sides will TLP at the same time assuming their RTT estimates are the same and both sides are tails. To see whether this happens I'll have to actually look at data in practice to see whether we see whether there is a delay between the server's TLP/RTO and the client's TLP/RTO.

There is also another class case which in which it might be useful to retransmit the ack without a new packet where one side does not have a tail but the other does. For example, in the case of a revproxy where there is an upstream server. The client has sent a tail request to the revproxy, which it forwards to a webserver.


There are 2 cases here:

  1.  The webserver has some processing delay which is < 2 * RTT, so the response comes back and we have new data to send. The server could also bundle a duplicate ack with this packet.
  2.  The response is larger than the request, so we could have bundled some dup ACKs with the response.


It is possible that the client would set an ACK timer < RTO timer and then send an ACK for this new packet, however if a server strictly does not ACK acks,  the client would still have to wait for the RTO timer.


Subodh

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

I'm not sure it would be much better, but it's worth thinking through the case you're describing.

It must be that no 'retransmittable'(I hate that term) packets are being received, but you're sending packets.  If it's a one-way transfer, then you're receiving ACKs for the data you're sending at a regular rate.  If you bundled an ack with outgoing data every sometimes, the ack would have a new largest acked of the received ACK packets, so all is well.

If it's a long pause, such as a TLP or RTO, then you've waited more than an RTT and received no packets to acknowledge, but then you decide to bundle an ACK?  At that point, it's likely the peer has already TLP'd around the same time, so you're probably not saving them a retransmission.

It had never occurred to me to bundle an ACK in this case, but doing so does have the side effect of creating useless RTT estimates.  We could have a special value(already disliking this) for max_ack_delay which indicates the ACK should not be used for RTT estimates, but I'm not sure it's valuable to bundle an ACK with TLPs and RTOs.

On Wed, Apr 25, 2018 at 12:20 PM Subodh Iyengar <[e-mail]<mailto:[e-mail]>> wrote:

@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]<mailto:[e-mail]>> on behalf of Ian Swett <ianswett=[e-mail]<mailto:[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