[e2e] Why do we need TCP flow control (rwnd)?
michael.scharf at ikr.uni-stuttgart.de
Fri Jun 27 05:17:07 PDT 2008
On Fri, 27 Jun 2008 at 12:01:30, Saverio Mascolo wrote:
> you are missing main points here:
> 1. flow control is aimed at avoiding overflow of the receiver buffer. the receiver buffer is assigned on a per-flow base, i.e. it is not a shared resource. This makes flow control a mechanism that is 100% perfect from the point of view of control, i mean that all the feedback required for perfect control is available;
> 2. congestion control does not know buffer available at routers because they are shared; this is the reason you need a probing mechanism to estimate cwnd. you do not need this probing mechanism with the receiver buffer since the advertised window tells you the exact available buffer.
> this is why we need flow control. moreover, saturating cwnd with receiver-buffer size (f.i. 64Kb) avoids that any single flow congest network using probing.
Very generally speaking, memory _is_ a shared resource on a host.
On the one hand, you are probably right, since most network stacks
will have a buffer allocation strategy that somehow ensures that the
free buffer space, which is signaled in the receiver advertized
window, is indeed available. But since memory allocation in an
operating system is a rather complex issue, I am not sure whether
there is a 100% guarantee that the receive buffer has really (at
least) the announced size. Note that modern TCP stacks announce
windows much larger than 64K (e. g., up to 16MB), and this could be an
incentive to somehow share buffer space if there are many parallel
On the other hand, the flow control is not 100% perfect, because of
the inherent delay of feedback signals. For instance, many TCP stacks
use receive window auto-tuning and dynamically increase their buffer
size during the lifetime of a connection. This means that, at a given
point in time, there might be more buffer space allocated in the
receiver than the sender is aware of.
BTW, if window scaling is negotiated and receiver window auto-tuning
is enabled, single TCP flows should be able to fill almost any
pipe. And, this propobably just what an app expects from TCP...
More information about the end2end-interest