Subject: Re: [quicwg/base-drafts] Congestion control during application limited state (#2554)

From: Jana Iyengar <[email-masked]>
Date: Wed, 03 Apr 2019 13:00:37 -0700

@pravb: You're right, this needs to be made crisp and we need to add pseudo-code to handle this. Do you have a strawman proposal? How does Windows TCP do currently to handle growth during app limited periods?

The naive approach doesn't work, since it prevents growth in the second RTT during slow start. I don't remember anymore what Linux TCP does, but I can look into that.

-- 
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/2554#issuecomment-479637205

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 03 Apr 2019 13:33:56 -0700

FWIW, my read of the Linux code tells me that at ack receipt time, the sender considers itself app-limited if in slow-start and cwnd > 2 x inflight, or if in cong-avoid and cwnd > inflight.

-- 
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/2554#issuecomment-479648097

---

From: ianswett <[email-masked]>
Date: Wed, 03 Apr 2019 13:39:17 -0700

Jana, your reading matches my memory, but I thought there was an extra "fq-pacing quantum" added to inflight in the second case?

-- 
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/2554#issuecomment-479649799

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 05 Apr 2019 18:20:55 -0700

So there is no standard mechanism defined for this in any of the TCP RFCs especially the ones describing modern congestion control like CUBIC and DCTCP. Instead of providing a particular algorithm I propose we leave the handling of this to the implementations? Maybe we can refer implementers to https://www.rfc-editor.org/rfc/rfc7661.txt for possible ideas.

-- 
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/2554#issuecomment-480462616

---

From: evolodina <[email-masked]>
Date: Mon, 08 Apr 2019 08:00:19 -0700

I’m not sure, but I guess RFC4960 & SCTP implementation may be useful in this case.

-- 
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/2554#issuecomment-480869016

---

From: ianswett <[email-masked]>
Date: Mon, 08 Apr 2019 15:28:23 +0000 (UTC)

I found this in RFC4960(https://tools.ietf.org/html/rfc4960#section-7.2.1):
"When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
      use the slow-start algorithm to increase cwnd only if the current
      congestion window is being fully utilized, an incoming SACK
      advances the Cumulative TSN Ack Point, and the data sender is not
      in Fast Recovery.  Only when these three conditions are met can
      the cwnd be increased; otherwise, the cwnd MUST not be increased."

The current QUIC recovery text tries to clarify what fully utilized means, particularly in the presence of pacing.

-- 
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/2554#issuecomment-480880608

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 10 Apr 2019 19:13:43 -0700

I'm quite familiar with RFC 4960, and it does not have anything that is particularly helpful here. @ianswett: I didn't see an fq-quantum in the code, but I could also be missing something.

-- 
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/2554#issuecomment-481938308

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 17 Apr 2019 10:56:15 -0700

Closed #2554 via #2605.

-- 
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/2554#event-2283532687