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

[John Heffner]

On Fri, Jun 27, 2008 at 8:17 AM, Michael Scharf
<michael.scharf at ikr.uni-stuttgart.de> wrote:
> 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.

This feedback delay is intrinsic, and exactly as long as for ECN or
loss feedback.  This is where buffers help.

TCP's receiver window works far better for flow control than the AIMD
controller used for congestion control because it is able to quickly
announce the availability of additional capacity.  It's possible to
announce a full BDP of available window in a single ack, whereas
congestion control will only increase cwnd by a small amount with the
same ack, if it is controlling the rate.  This is particularly useful
since applications often consume data in bursts, based on availability
of resources in the host.  They tend to be far more bursty than
network devices that congestion control probes.  Congestion control
does not adapt well to quickly varying capacity.

TCP implementations also use the receive window to ensure that they
don't need to drop packets if they are unable or unwilling to commit
additional memory, since the penalty for dropping a packet is
relatively high.

Turning the question around, what is the reason *not* to use a receive window?

  -John