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

From: Kazuho Oku <[email-masked]>
Date: Sat, 30 Jun 2018 12:14:01 +0900

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 <[email-masked]>:

> 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

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 30 Jun 2018 03:43:06 +0000

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 [[email-masked]]
Received: Friday, 29 Jun 2018, 11:14PM
To: Christian Huitema [[email-masked]]
CC: IETF QUIC WG [[email-masked]]
Subject: Speeding up tail loss detection (Re: Congestion control algorithm questions)

--
Kazuho Oku

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sat, 30 Jun 2018 06:26:00 +0000

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:[email-masked]] On Behalf Of Lubashev, Igor
Sent: Friday, June 29, 2018 8:43 PM
To: huitema <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)

- Igor

-----Original Message-----
From: Kazuho Oku [[email-masked]]
Received: Friday, 29 Jun 2018, 11:14PM
To: Christian Huitema [[email-masked]]
CC: IETF QUIC WG [[email-masked]]
Subject: Speeding up tail loss detection (Re: Congestion control algorithm questions)

--
Kazuho Oku

---

From: Christian Huitema <[email-masked]>
Date: Sat, 30 Jun 2018 11:11:09 -0700

>    largest received packet number.

Yes, but I don't think this is what Ian is looking for. Ian is looking
for something mechanical, "if you receive this signal please send an ACK
right now."

The paragraph that you quote does not achieve that. In it, "SHOULD"
stands for something like "SHOULD unless you think you are smarter than
that." For example, a receiver that experiences lots of out of order
deliveries might replace the last sentence by "when it receives a new
packet which is not X greater than the largest received packet number",
where X is based on an estimate of current out of order deliveries.

Besides, the sender might wish for an immediate ACK for other reasons
than managing out of order deliveries. Precise time management or
checking for connectivity come to mind.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Sat, 30 Jun 2018 11:12:19 -0700

Oops. Attributed to Ian what was really Igor's idea. Sorry.

On 6/30/2018 11:11 AM, Christian Huitema wrote:
> for something mechanical, "if you receive this signal please send an
> ACK right now."
>
> stands for something like "SHOULD unless you think you are smarter
> than that." For example, a receiver that experiences lots of out of
> order deliveries might replace the last sentence by "when it receives
> a new packet which is not X greater than the largest received packet
> number", where X is based on an estimate of current out of order
> deliveries.
>