Subject: [quicwg/base-drafts] Add a section on flow control performance (#3793)

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Jun 2020 00:31:03 -0700

QUIC doesn&#39;t really address the question of tuning flow control very
well.  This just admits that fact.

It also indicates why: which essentially boils down to &quot;RAM is cheap&quot;.

Closes #3722.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3793

-- Commit Summary --

  * Add a section on flow control performance

-- File Changes --

    M draft-ietf-quic-transport.md (18)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3793.patch
https://github.com/quicwg/base-drafts/pull/3793.diff

-- 
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/pull/3793

---

From: Marten Seemann <[email-masked]>
Date: Fri, 26 Jun 2020 00:40:29 -0700

@marten-seemann commented on this pull request.

> @@ -968,6 +968,24 @@ signal before advertising additional credit, since doing so will mean that the
 peer will be blocked for at least an entire round trip, and potentially for
 longer if the peer chooses to not send STREAMS_BLOCKED frames.
 
+## Flow Control Performance
+
+Unlike TCP, QUIC decouples flow control from congestion control. This can
+release pressure on implementing a good flow control algorithm that governs both
+how limits are increased and when new limits are advertised. An endpoint can
+use flow control to constrain resource commitments without an optimized
+algorithm by allocating buffers for receiving data that are significantly larger
+than the bandwidth-delay product (BDP).  That is, by a factor of 2 or more.

That will still hurt you if you wait until the window has completely filled up before issuing a flow control update. If you do this and you have a window of 2 BDP, you'll decrease the usable bandwidth by 33%.

> @@ -968,6 +968,24 @@ signal before advertising additional credit, since doing so will mean that the
 peer will be blocked for at least an entire round trip, and potentially for
 longer if the peer chooses to not send STREAMS_BLOCKED frames.
 
+## Flow Control Performance
+
+Unlike TCP, QUIC decouples flow control from congestion control. This can
+release pressure on implementing a good flow control algorithm that governs both
+how limits are increased and when new limits are advertised. An endpoint can
+use flow control to constrain resource commitments without an optimized
+algorithm by allocating buffers for receiving data that are significantly larger
+than the bandwidth-delay product (BDP).  That is, by a factor of 2 or more.
+
+An endpoint that is unable to ensure that a peer has flow control credit in the
+order of the current BDP will have receive throughput limited by flow control
+and not other limiting factors like congestion control.  Timely sending of
+updates to flow control limits can improve performance, however an excessive
+rate of updates can also adversely affect performance.

I'm not if I agree with this statement. You'd really have to take it to the extreme to affect performance. MAX_STREAM_DATA frames are small, and even if you bundle one of them with every ACK you send, this would likely not be a significant overhead.

-- 
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/pull/3793#pullrequestreview-438075521

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 26 Jun 2020 00:54:39 -0700

@gorryfair commented on this pull request.

I tend to agree, the present working sounds like a "significant" warning, but the penalty of updating too infrequently is also severe - perhaps and  example of frequently might help? such as 1/8 RTT? 

-- 
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/pull/3793#discussion_r446026721

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Jun 2020 03:59:04 -0700

@larseggert commented on this pull request.

TCP doesn't couple CC and FC either? The receive window is independent of cwnd. (There are some autotuning implementations that couple them, but the spec doesn't.)

-- 
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/pull/3793#pullrequestreview-438203166

---

From: evolodina <[email-masked]>
Date: Fri, 26 Jun 2020 04:19:45 -0700

@evolodina commented on this pull request.

> TCP doesn't couple CC and FC either? The receive window is independent of cwnd. (There are some autotuning implementations that couple them, but the spec doesn't.)

Exactly right, TCP does not copule them. I know RFC 813.
I wonder if there is another RFC, where the TCP FC is described. 

-- 
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/pull/3793#discussion_r446123448

---

From: evolodina <[email-masked]>
Date: Fri, 26 Jun 2020 04:27:02 -0700

> I tend to agree, the present working sounds like a "significant" warning, but the penalty of updating too infrequently is also severe - perhaps and example of frequently might help? such as 1/8 RTT?

Can the example of frequently lead to SWS?

-- 
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/pull/3793#discussion_r446126568

---

From: evolodina <[email-masked]>
Date: Fri, 26 Jun 2020 05:33:01 -0700

It probably works for FC_threshold equal to FC_Limit/2, but not for every threshold

-- 
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/pull/3793#discussion_r446155019

---

From: Nick Banks <[email-masked]>
Date: Fri, 26 Jun 2020 07:25:08 -0700

@nibanks commented on this pull request.

I'd also like to understand why you're saying it's going to adversely affect performance. MsQuic bundles FC updates with ACKs and as far as I have seen, we've been able to reach some of the highest perf numbers in testing out there.

-- 
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/pull/3793#discussion_r446216247