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

From: Kazuho Oku <[email-masked]>
Date: Mon, 2 Jul 2018 01:27:41 +0900

2018-06-30 12:43 GMT+09:00 Lubashev, Igor <[email-masked]>:
> 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.

That approach would work well.

In my view, there are two ways; i) define a frame that requests
immediate ACK, and bundle that frame with other frames if immediate
ACK is required, ii) define which frames trigger immediate ACK. I
think either of the two are workable.

Re Praveen's comment, my understanding is that there are cases that a
sender wants to trigger immediate ACK even if gap is not observed on
the receiver side. In case of TLP, such behavior is desirable because
it gives the peers to recover earlier from the loss of a previous
packet that contained an ACK.

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

-- 
Kazuho Oku

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sun, 1 Jul 2018 16:32:34 +0000

Doesn’t the PING frame serves this purpose? The language in the transport draft isn’t very clear:
	The receiver of a PING frame simply needs to acknowledge the packet containing this frame.

Ideally this should say:
	The receiver of a PING frame SHOULD send an immediate ACK acknowledging the packet containing this frame.

> that there are cases that a sender wants to trigger immediate ACK even if gap is not observed on the receiver side
If this is for timing measurements or liveness then PING should work. If you have examples where loss recovery can be further improved using such a mechanism then we should certainly address it. I don’t think we can make any assumptions on the sender that receiver will ACK because pure ACK can also be dropped and not retransmitted.

-----Original Message-----
From: Kazuho Oku [mailto:[email-masked]] 
Sent: Sunday, July 1, 2018 9:28 AM
To: Lubashev, Igor <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Cc: huitema <[email-masked]>; [email-masked]
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)

2018-06-30 12:43 GMT+09:00 Lubashev, Igor <[email-masked]>:
> 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.

In my view, there are two ways; i) define a frame that requests immediate ACK, and bundle that frame with other frames if immediate ACK is required, ii) define which frames trigger immediate ACK. I think either of the two are workable.

Re Praveen's comment, my understanding is that there are cases that a sender wants to trigger immediate ACK even if gap is not observed on the receiver side. In case of TLP, such behavior is desirable because it gives the peers to recover earlier from the loss of a previous packet that contained an ACK.

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

--
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 1 Jul 2018 10:20:42 -0700

On 1 July 2018 at 18.32.56, Praveen Balasubramanian (
pravb=[email-masked]) wrote:

Doesn’t the PING frame serves this purpose? The language in the transport
draft isn’t very clear:
The receiver of a PING frame simply needs to acknowledge the packet
containing this frame.

No, I asked for this several times, but there was no traction. It is ACK’ed
as any packet which the consensus considers soon enough. But I dont’ think
this takes into account use cases with delayed ACK and congestion
algorithms that can tolerate longer delays.

It’s simply useful to ping in order to get a roundtrip time on the
connection, aside from what has already been mentioned.

---

From: Ian Swett <[email-masked]>
Date: Mon, 9 Jul 2018 20:47:28 -0400

This has been discussed on and off for a few years now, even prior to the
IETF process.  It's never been clear that adding a frame for this purpose,
or altering the behavior of an existing frame(ie: PING or STREAM) is
valuable.

I'm about to start an experiment to send an ACK more quickly(ie: 1ms delay)
if it's been over an RTT since an ACK has been sent, which may help, but is
largely aimed at the TLP and RTO use cases.  One use case that's been
discussed is sending a fast ack frame/signal when entering an app-limited
phase.  This seems fairly promising to me, but I have no experimental
evidence it actually helps.

One option would be to recommend sending an ACK quickly in response to a
PING, unless a PING has been acked within the last RTT.  This would provide
a natural rate-limit to immediate ACKs.

On Sun, Jul 1, 2018 at 1:20 PM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> On 1 July 2018 at 18..32.56, Praveen Balasubramanian (
> No, I asked for this several times, but there was no traction. It is
> ACK’ed as any packet which the consensus considers soon enough. But I dont’
> think this takes into account use cases with delayed ACK and congestion

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 9 Jul 2018 21:56:13 -0700

> evidence it actually helps.

If it's mainly aimed at the TLP and RTO, I'm not very sure if this is
really effective.
For TLP and RTO cases, I guess the speed will depend on how fast
sender sends a probe packet (while avoiding redundancy) rather than
how fast receiver sends an ack.
--
Yoshi

---

From: Ian Swett <[email-masked]>
Date: Tue, 10 Jul 2018 09:54:07 -0400

To summarize my current thinking: I'd like to add/change something in QUIC
that allows experimentation in this space.  Ideally this would be in the
near future(before v1), so we can understand if it's valuable and provide a
well-reasoned recommendation in the recovery doc.

The fast ACK after PING approach seems simple enough to me, but I'm open to
other suggestions as well.

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Jul 2018 16:15:31 +0000

Requiring immediate (not explicitly delayed) ACK for PING frame at least once per RTT (or even always) seems fine to me. In the crucial recovery cases TLP will be out of order and will elicit an immediate ACK anyways. If there are ways to speed up recovery let’s experiment and bring them to the draft, they might help TCP as well.

From: Ian Swett [mailto:[email-masked]]
Sent: Tuesday, July 10, 2018 6:54 AM
To: [email-masked]
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>; Praveen Balasubramanian <[email-masked]>; Lubashev, Igor <[email-masked]>; huitema <[email-masked]>; IETF QUIC WG <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)

To summarize my current thinking: I'd like to add/change something in QUIC that allows experimentation in this space.  Ideally this would be in the near future(before v1), so we can understand if it's valuable and provide a well-reasoned recommendation in the recovery doc.

The fast ACK after PING approach seems simple enough to me, but I'm open to other suggestions as well.

On Tue, Jul 10, 2018 at 12:56 AM Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jul 9, 2018 at 5:47 PM, Ian Swett

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 10 Jul 2018 14:14:24 -0700

Hi,
Just to be clear..  I am a bit skeptical about the effectiveness of it
for (current) TLP, but I am not against having this kind of feature
for future experiments.
People may come up with an interesting idea based on the results of
some experiments.
--
Yoshi