[e2e] Why do we need TCP flow control (rwnd)?
David P. Reed
dpreed at reed.com
Thu Jun 26 05:23:42 PDT 2008
This is an interesting question. However, the assertion that many hosts
have large buffer pools is too broad and of the wrong dimensionality to
The key value is the ratio:
size_rpool * rate_service
size_inflite * rate_input
where size_rpool is the size of the buffer pool, the size_inflite is the
total size of packets that will be in flight before a control signal can
slow the source, rate_service is the service rate of the receiving
system in terms of work it can handle, and rate_input is the input rate
of work to the target machine (rate_input is the product of input NIC
rate times the work-per-byte-of-input). (Derived from Little's
Lemma/Theorem). That's an indicator of the probability of discarded
work requests that will arise because the
It's a dimensionless parameter. And in particular it illustrates that
you need to understand how much work is done per byte and how much work
the endpoint can actually do.
So the rwnd parameter is NOT actually measuring buffer pool size. It
is actually a control loop that measures the endpoint application's
ability to do work.
Michael Scharf wrote:
> maybe this is a stupid question: Is there really a need for the TCP
> flow control, i. e., for signaling the receiver window back to
> the sender?
> It is well known that TCP realizes both congestion control and flow
> control, and that a TCP sender therefore maintains two different
> windows (cwnd and rwnd). Obviously, the congestion control protects
> the path from overload, while the flow control protects the receiver
> from overload.
> However, I have some difficulties to understand why the flow control
> part and receiver advertized window is actually needed.
> Instead of reducing rwnd, an overloaded receiver running out of buffer
> space could simply drop (or mark) new arriving packets, or just
> refrain from sending acknowledgements. As a reaction to this, the
> sender probably times out and the TCP congestion control significantly
> reduces the sending rate, which reduces the load on the receiver, too.
> To my understanding, a fine granular receiver advertized window is
> much more efficient if the buffer sizes are of the order of a few
> packets only. But I guess that most of today's Internet hosts have
> larger buffers, and therefore they hardly need a fine granular flow
> Are there reasons why TCP can't just use its congestion control to
> handle slow receivers? Do I overlook some aspect? Any hint or
> reference would be welcome.
More information about the end2end-interest