Subject: [quicwg/base-drafts] Recovery: when PTO expires and no data to send (#3286)

From: Junho Choi <[email-masked]>
Date: Thu, 05 Dec 2019 14:00:46 -0800

OnLossDetectionTimeout() pseudo code says:

```
   // PTO. Send new data if available, else retransmit old data.
    // If neither is available, send a single PING frame.
```

And "Sending Probe Packets" says:

> When a PTO timer expires, a sender MUST send at least one ack-eliciting packet in the packet number space as a probe, unless there is no data available to send
...
> When there is no data to send, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer.

For me it's a little wasteful to keep sending an ack-eliciting frame (including PING) as a Probe packet when there is no data to send. In this case if the client become unresponsive before receiving PING, the server may keep sending PING as a Probe packet until idle timeout expires in this case.

I think it's better to update as follows:

"When there is no data to send and *last Probe packet included an application data*, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer."

It will make sure that PING as a Probe packet is sent once when the server has no further data to send.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3286

---

From: ianswett <[email-masked]>
Date: Thu, 05 Dec 2019 14:05:28 -0800

This exponential backoff of PING packets is less wasteful than a TCP RTO, since in TCP one can't decide not to retransmit data that was previously sent.  It's also an edge case which rarely occurs in practice.

In order to detect persistent congestion correctly, you'll likely need to send multiple PINGs in this case.

Given the above, I'm happy with the current algorithm.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3286#issuecomment-562339724

---

From: Junho Choi <[email-masked]>
Date: Thu, 05 Dec 2019 16:58:09 -0800

> This exponential backoff of PING packets is less wasteful than a TCP RTO

Do you mean TCP PTO, not RTO?

> In order to detect persistent congestion correctly, you'll likely need to send multiple PINGs in this case.

I agree the use case of persistent congestion, but if we detect persistent congestion (collapsing cwnd) by consecutive PINGs, is it over-reacting to cwnd because there is no real data sent?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3286#issuecomment-562385555

---

From: ianswett <[email-masked]>
Date: Fri, 06 Dec 2019 06:09:23 -0800

> Do you mean TCP PTO, not RTO?

TCP does't have PTO, but the exponential backoff of RTO is most similar to PTO.
> I agree the use case of persistent congestion, but if we detect persistent congestion (collapsing cwnd) by consecutive PINGs, is it over-reacting to cwnd because there is no real data sent?

In QUIC, a PING packet and a packet containing data are equivalently useful from loss detection  and congestion control perspectives, so I don't think it matters whether data is sent.

The text in Section 5.3.1 of recovery says:
  "Alternatively, instead of sending an ack-eliciting packet, the sender
   MAY mark any packets still in flight as lost.  Doing so avoids
   sending an additional packet, but increases the risk that loss is
   declared too aggressively, resulting in an unnecessary rate reduction
   by the congestion controller."

So the suggestion you're describing is permitted, but it's not the recommended behavior.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3286#issuecomment-562585251

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 09 Dec 2019 16:44:13 -0800

@junhochoi : As @ianswett said, you are within the spec to not send anything in response to a PTO. The spec recommends sending something because it keeps the sender's state up to date, and is better when the sender might want to send more data later.

Does that resolve your concern?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3286#issuecomment-563507184

---

From: Junho Choi <[email-masked]>
Date: Tue, 10 Dec 2019 11:15:10 -0800

@ianswett @janaiyengar The behavior was somewhat different from what I expected, but I think now I have a good understanding. I will close this. Thanks for help!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3286#issuecomment-564190827

---

From: Junho Choi <[email-masked]>
Date: Tue, 10 Dec 2019 11:15:11 -0800

Closed #3286.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3286#event-2871744714