Subject: Re: [quicwg/base-drafts] Define "under-utilization" of cwnd (#2630)

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 May 2019 02:01:07 -0700

Defining "under-utilised cwnd", seems conceptually the right thing, but we struggled with that term and the term "fully utilized the congestion window" when writing RFC7661, because ACKs can arrive in bursts and apps can do their work in bursts: Does that mean it's more than some threshold for some period time?

-- 
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/2630#issuecomment-491216034

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 16:32:20 -0700

@gorryfair : That is a question. Maybe we can get away from that by saying that a sender only increases its cwnd if it knows that it was fully utilized since the last cwnd change? Meaning that at some point since the last cwnd change, inflight >= cwnd happened at least once.

I have a separate question, one that was being discussed in #2554, and I think is still left open. If we need the entire cwnd to be used before increasing it, we lose out on 1 RTT of growth during slow start. Both Windows and Linux TCP compensate for this by doing something like increase it when > 1/2 cwnd is used... we need to write something here that's at least as performant, and not just "when inflight >= cwnd".

-- 
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/2630#issuecomment-491457145

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 16:32:36 -0700

@pravb, thoughts?

-- 
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/2630#issuecomment-491457178

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 11 May 2019 02:28:25 -0700

This seems to be digging in the correct place. I think we would agree the aim of some form of cwnd-validation is to stop cwnd growth when there is no growth of inflight data by the upper layer. And I think we'd agree tussle comes when the CC is trying to expand the cwnd - because the upper layer has more data to send, but that doesn't mean cwnd was necessarily fully utilised last RTT.

When would in-flight > cwnd ?

-- 
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/2630#issuecomment-491495325

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 18:03:36 -0700

@janaiyengar Good point about the in_flight > 1/2 CWND check in Linux.  In BBR, that only applies to the first doubling of IW, and after that it's fully bandwidth based, FWIW.

We could add a similar constraint that this rule can be applied when the window was not fully used at the time of sending, but was at the time of acknowledgement as long as the window is < 2*IW?

One clear goal of mine is I don't want the handshake alone increasing the congestion window(assuming IW10 and a moderately sized handshake).

-- 
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/2630#issuecomment-491645245

---

From: Matt Olson <[email-masked]>
Date: Wed, 22 May 2019 14:46:26 -0700

Putting this discussion into a concrete algorithm:

-Keep an in-flight high watermark, InFlightHigh, that's reset on each CWND change.
-When considering growing the CWND, only let it go as large as InFlightHigh*2.
-Justification for the "*2": it allows base-2 exponential growth, which is the fastest growth we ever want.

-- 
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/2630#issuecomment-494986042

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 22 May 2019 15:13:50 -0700

Possible expiration events: persistent congestion, ssthresh changes, app idle.

-- 
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/2630#issuecomment-494993911

---

From: ianswett <[email-masked]>
Date: Thu, 23 May 2019 02:15:33 -0700

Discussed in London, we'd like to avoid specifying this in pseudocode and the exact math, as it may be implementation dependent, but instead focus on improving the existing text.

-- 
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/2630#issuecomment-495136262