RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)

[Praveen Balasubramanian <[e-mail]>]

All out of order packets elicit an immediate ACK, this applies to QUIC the same way it applies to TCP.

Section 3.4 of recovery spec:

   Out-of-order packets SHOULD be acknowledged more quickly, in order to
   accelerate loss recovery.  The receiver SHOULD send an immediate ACK
   when it receives a new packet which is not one greater than the
   largest received packet number.

From: QUIC [mailto:[e-mail]] On Behalf Of Lubashev, Igor
Sent: Friday, June 29, 2018 8:43 PM
To: huitema <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)

It would make sense to define PING to require an ACK as soon as possible. The need for an immediate ACK is not just in tail loss probes. It is also PMTU probes. Come to think of this, PATH_CHALLENGE should require an expedited ACK as well.

- Igor

-----Original Message-----
From: Kazuho Oku [[e-mail]]
Received: Friday, 29 Jun 2018, 11:14PM
To: Christian Huitema [[e-mail]]
CC: IETF QUIC WG [[e-mail]]
Subject: Speeding up tail loss detection (Re: Congestion control algorithm questions)
I know that the recovery draft defines TLP, but it does not provide a
way for a sender to request client to send an ACK immediately. I think
that there should be a way to request that, because it would help the
sender detect the loss at the earliest moment.

One way is to specify a TLP frame, which is identical to a PING frame
with only one difference: it suggests the peer to send ACK
immediately. A sender sending a TLP will include the frame in the
packet to evoke the peer to send ACK without waiting for the delay.

Searching the mailing list archive told me that Christian raised the
issue about a year ago (in the mail cited below), but it seems to me
that the issue has not been resolved yet.

2017-08-25 14:52 GMT+09:00 Christian Huitema <[e-mail]<mailto:[e-mail]>>:

> 3) Can the senders do something to speed up retransmission?
> In the absence of continuous traffic flow, the previous decision tree
> degenerates to timer based retransmission. To speed things up,
> implementations can generate extra traffic. For example, if no
> acknowledgement is received after a short timer, they can send a
> gratuitous packet that may trigger a further acknowledgement. That's the
> essence of the "tail loss probe" algorithm of TCP, but things are really
> simpler with monotonously increasing packet sequence numbers. There are
> various plausible ways to send a gratuitous packet -- a Ping, a Max Data
> Update, or repeating the oldest packet will all work.
>
> Of course, implementations should avoid sending too many gratuitous
> packets, because it can cause congestion. The typical implementation
> will wait one min-RTT before sending the first tail loss probe, then
> just wait for the regular timer based retransmission. But we may start
> being creative. For example, if packets are waiting and the
> implementation is sending a naked ACK for whatever reason, it does not
> cost much to add a Ping to that.
>
> This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is
> very easy to implement.
>
> --
> Christian Huitema
>
>



--
Kazuho Oku