Re: ack delay in rx packets

[Jana Iyengar <[e-mail]>]

Subodh,

I think you're right. We should fix this issue, though I'm not exactly sure
how.  We dropped this earlier; I've filed #1438
<https://github.com/quicwg/base-drafts/issues/1438> so that we can continue
this discussion there.

- jana

On Wed, Apr 25, 2018 at 9:48 AM Subodh Iyengar <[e-mail]> wrote:

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