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

[Marten Seemann <[e-mail]>]

@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