Re: ack delay in rx packets

[Ian Swett <[e-mail]>]

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]> wrote:

> @Ian Swett <[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]> 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
>
>