Add a section on flow control performance #3793
Conversation
QUIC doesn'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 "RAM is cheap". Closes #3722.
martinthomson
added
editorial
draft-ietf-quic-transport.md
Outdated
| 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. |
There was a problem hiding this comment.
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%.
There was a problem hiding this comment.
It probably works for FC_threshold equal to FC_limit/2, but not for every FC_threshold
draft-ietf-quic-transport.md
Outdated
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I suspect "excessive" means "more frequently than ACKs and/or in their own packets." Should we say that?
draft-ietf-quic-transport.md
Outdated
| @@ -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 | |||
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.
|
On Fri, Jun 26, 2020, 12:31 AM Martin Thomson ***@***.***> wrote:
QUIC doesn'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 "RAM is cheap".
Hi Martin. I stumbled across this. I don't know if you are joking, but if
not I'd like to disagree. There are a significant class of devices,
commodity streaming devices, which are very large volume but for which the
trend is to shave as much RAM budget as possible, HD video devices in
markets like India, Brazil, etc. In aggregate, these devices consume a
significant amount of overall internet traffic. RAM is cheap is most
definitely not true there, and they certainly don't ship with TCP receive
windows anywhere near as large as other device segments. This is not a
legacy issue either, for the foreseeable future it looks like the amount of
RAM in newer devices will be lucky to stay stable as opposed to even
decrease.
… Closes #3722 <#3722>.
------------------------------
You can view, comment on, or merge this pull request online at:
#3793
Commit Summary
- Add a section on flow control performance
File Changes
- *M* draft-ietf-quic-transport.md
<https://github.com/quicwg/base-drafts/pull/3793/files#diff-db016291106766877c4921a79f8596e0>
(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, view it on GitHub
<#3793>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABRABBQI2QR6RBOI65V4JCLRYRFDHANCNFSM4OJCIA6A>
.
|
draft-ietf-quic-transport.md
Outdated
| 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. |
There was a problem hiding this comment.
I suspect "excessive" means "more frequently than ACKs and/or in their own packets." Should we say that?
draft-ietf-quic-transport.md
Outdated
| updates to flow control limits can improve performance. However, an excessive | ||
| rate of updates can also adversely affect performance. |
There was a problem hiding this comment.
| updates to flow control limits can improve performance. However, an excessive | |
| rate of updates can also adversely affect performance. | |
| updates to flow control limits can improve performance. An excessive | |
| rate of updates sent in their own packet increases network load and | |
| can adversely affect performance. Bundling updates with ACK | |
| frames provides frequent updates without adding significant load. |
There was a problem hiding this comment.
Should we instead say "Sending of packets just to provide flow control updates can increase network load and adversely affect performance. Sending flow control updates along with other frames, such as ACK frames, can reduce the cost of those updates."
There was a problem hiding this comment.
SGTM, there's no reason it only needs to be ACK frames.
draft-ietf-quic-transport.md
Outdated
| updates to flow control limits can improve performance. However, an excessive | ||
| rate of updates can also adversely affect performance. | ||
|
|
||
| This document does not specify techniques for tuning flow control performance |
There was a problem hiding this comment.
I don't think this paragraph is necessary, but that's me.
Co-authored-by: ianswett <ianswett@users.noreply.github.com>
Co-authored-by: ianswett <ianswett@users.noreply.github.com>
QUIC doesn'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 "RAM is cheap".
Closes #3722.