[e2e] Why do we need TCP flow control (rwnd)?

Dennis Ferguson dennis at juniper.net
Wed Jul 2 13:14:16 PDT 2008


On 29 Jun 2008, at 15:53 , Lachlan Andrew wrote:
> 2008/6/28 David P. Reed <dpreed at reed.com>:
>>
>> Without fantasizing about possible imaginary justifications for  
>> which there
>> is no evidence, what real problem exists?
>
> Perhaps the biggest current problem is the one that David Wei
> mentioned, which occurs when the buffer is small relative the the BDP,
> but the receiver is fast.

For what it is worth, whether this is a "problem" or a "feature" is
still highly dependent on the application.  For some applications
severely limiting the amount of in-flight data even in the presence
of a large path BDP can be exactly what is desired.

In large networks these days most routing protocol data is carried over
TCP.  This is done primarily to take advantage of TCP flow control (this
wasn't the original reason TCP was used but in retrospect it looks like
a plan).  When the more real-time parts of the routing system come under
stress and it needs to free up processing resources to take care of the
immediate needs, it can shed substantial load by simply ceasing to read
incoming data from the TCP sockets.  The closed window will signal the
sender not to bother to format and send more data which the receiver has
no time to process, hence limiting the amount of routing data which sits
around in transport buffers getting increasingly stale and irrelevant.

So in this application the receive window not only acts as a limit on
how fast data can be transfered when things are going well, but also
as a limit on the amount of time it takes for a sender to learn of a
receiver's problems, and a limit on the amount of routing data which
won't be processed in a timely fashion, when things are going badly.
Since the behaviour when things are going badly is generally much more
important to routing then ensuring that data moves at maximum speed
when things are going well, the routing implementations I'm familiar
with generally set the receive window to be quite small to optimize
that bit.  Sometimes the receive window size has implications beyond
just the BDP and the amount of memory that is available.

Dennis Ferguson


More information about the end2end-interest mailing list