Subject: [quicwg/base-drafts] Should kPersistentCongestionThreshold be 1 or 2? (#2556)

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 26 Mar 2019 13:54:01 +0000 (UTC)

Both Linux and Windows TCP arm a single PTO for TLP and then arm the RTO. The recommendation in RACK draft https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack is also for doing a single TLP. If we keep the value as 2 then we need to add a justification statement for deviating from TCP. It would be good to find out if Yuchung has a any data on why Linux settled on a single TLP (PTO). 

-- 
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/2556

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 26 Mar 2019 14:21:10 +0000 (UTC)

The recovery draft currently says MUST send 1, and MAY send up to 2 (https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#rfc.section.6.3.2). Is that not good enough?

-- 
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/2556#issuecomment-476667933

---

From: ianswett <[email-masked]>
Date: Tue, 26 Mar 2019 08:36:57 -0700

The issue is about the length of the persistent congestion period.  If the -16 draft recommended 1 TLP before the first RTO instead of 2 TLPs before RTO(See https://github.com/quicwg/base-drafts/issues/2185), then the natural persistent congestion time period would be 2 * PTO instead of 3 * PTO.

As an editorial issue, as Jana and I discussed yesterday, we should make kPersistentCongestionThreshold a direct constant, not an exponent - 1, because it's making this more confusing to think about.

-- 
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/2556#issuecomment-476707358

---

From: ianswett <[email-masked]>
Date: Tue, 26 Mar 2019 15:44:06 +0000 (UTC)

Last time I talked to Yuchung, I remember him saying they chose 1 somewhat arbitrarily.

I'm going to argue for 2 (3 * PTO) as a good number because it provides enough time for the PTO timer to go off twice now that the PTO has exponential backoff.  This is in some ways more similar to 1 TLP and then 1RTO in terms of network load.  Additionally, I believe making it only 1 would allow a single tail packet to be lost and persistent congestion to be declared if there was some RTT variation?  That certainly seems undesirable.

Maybe the rationale for why this value was chosen should be clarified further?

-- 
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/2556#issuecomment-476710975

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 26 Mar 2019 17:09:52 +0000 (UTC)

*facepalm* @ianswett, of course. (Also, FWIW, PR #2557 makes this a simple multiplier, so let's just use that language.)

So I think I may have the opposite concern to @pravb. The mechanisms we are talking about are subtly different, so let's just talk about behavior instead of the mechanisms.

TCP RTO uses a minRTO while PTO does not. As a result, in the common case, persistent congestion for TCP will be declared at minRTO (or later). We risk declaring persistent congestion too soon with QUIC, even with 3 PTOs, since minRTO is at least 200ms for TCP, AFAIK. QUIC might be too aggressive in declaring persistent congestion.

This might be actually bad for performance. Anecdotally, I remember that Yuchung had tried turning on [RTO Restart](https://datatracker.ietf.org/meeting/85/materials/slides-85-tcpm-2) and found that it increased spurious RTOs.  While spurious PTOs are not bad in QUIC, we don't yet have a way to detect spuriously declared persistent congestion.

This makes me wonder if we should use a min value for declaring persistent congestion. I think this is justifiable as based on best current practice that we know in TCP and that declaring congestion too soon might hurt throughput. (Note that a min is still unnecessary for QUIC PTO because spurious PTOs have only minor bandwidth cost.)

As a strawman, I'll propose that we set the persistent congestion time period to max(PTO, 200ms).

Why PTO and not 3 * PTO? Because I believe (and someone can prove me wrong) that TCP actually does use a single RTO period for declaring an RTO, despite potentially sending TLPs in that time period.
>From the RACK draft, my understanding is that sending TLPs in TCP does not actually change the RTO timer, which runs for the same amount of time (from the last ack received in practice or the earliest outstanding data).

-- 
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/2556#issuecomment-476751807

---

From: ianswett <[email-masked]>
Date: Thu, 28 Mar 2019 06:37:18 -0700

I edited the title to indicate 2 or 3 instead of 1 or 2, now that #2557 has landed.

Yes, TLPs in TCP do not change RTO.  One of the reasons TLP was added in the way it was is that it doesn't really interact with RTO at all, which made it convenient.

My understanding is that TCP uses 200ms because it's 2x the expected delayed ACK timer?  If so, given we're including max_ack_delay in the PTO value, shouldn't that be sufficient(assuming we keep a 2x or larger multiplier on PTO)?

-- 
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/2556#issuecomment-477597841

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 28 Mar 2019 10:02:50 -0700

The TCP minRTO is 1 sec per RFC 6298, but Linux uses 200 ms if I'm not mistaken. I could be wrong, but don't think it was based on the delayed ack timer, since the delayed ack timer value is typically 200ms. (I'll confirm this.)

My high order point is that we probably do not want QUIC to declare persistent congestion (and collapse cwnd) sooner than TCP currently does in the network. Using only the PTO values might cause us to do that, and it might cause unnecessary throughput degradation.

IMO we don't lose anything by declaring persistent congestion similar to TCP. PTOs still fire the way they always do, and recovery continues the way it always does. Other machinery (such as when to call a connection or path dead for instance) can continue to use PTOs, but we just declare persistent congestion based on what we know TCP behavior to be in the wild.

-- 
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/2556#issuecomment-477684981