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

[Ted Faber]

On Thu, Jun 26, 2008 at 09:38:37AM +0200, Michael Scharf wrote:
> Hi,
> 
> 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?

Several folks have weighed in with useful explanations of this, but I'm
going to say it another way.  TCP Flow control is an end-to-end feature;
TCP congestion control is not.

Just like other end-to-end transport features, flow control is a
communication of endpoint state, just like the initial synchronization
of sequence numbers or options.  The protocol is designed to send only
data it knows the receiver is willing to accept regardless of the state
of the network.  That's a design decision, and other protocols may make
different ones, but TCP designers decided that sending data that they
knew would be dropped was wasteful of network and endpoint resources.

Because it's explicit communication, it can be used to set sending rates
(over a window time).

Congestion control attempts to infer network capacity and avoid
collapse.  Because of the coarse granularity of its inference
mechanism and because it's a global safety feature (it's avoiding
network collapse (or maybe path collapse)), it operates conservatively.
Because it's detecting current state, it probes for additional capacity.

The two features have very different motivations and goals.  Congestion
control will treat an endpoint that doesn't do flow control as a
congestion point, but that's subtly different than doing flow control.

Here's a somewhat contrived example to illustrate the difference.  It's
simplified a little to draw the distinction.

Consider endpoints using flow control to rate limit senders (by limiting
the drain rate of the TCP buffer).  A single connection (on an
uncongested low BDP net) would probably only see second order effects
between using congestion control and flow control for this purpose.
That assumes that endpoint TCP buffering was sufficient to smooth out
the sawtoothed sending rate that TCP congestion control creates and that
the BDP was reasonable to prevent underruns at the bottom of the tooth.
As I say, it's easy enough to make that all work out, but congestion
controlled senders keep probing the network and exhibit the saw toothed
sending rate.  These are problems that you don't have with flow
controled senders.  Flow controlled sources stop probing the network
when they're sending at the flow rate.  Their rate rises to the flow
controled limit and plateaus.

As more connections use that network, the saw toothed sending rates may
combine unpleasently.  Because losses are likely to be correlated,
there's a reasonable chance that multiple sources will synchronize and
that overall, fewer connections will be able to use the network because
of the disruptions to the network.  Multiple sources hitting their peak
at the same time create longer periods of congestion.  More flow
controlled sources can fit in the same network because there are no
disruptive probes to combine.  (You can always stack n flat rate
senders, but the number of sawtooth rate senders depends on how the
teeth align.)

As I say, this is simplified.  When resources become scarce, even flow
controled sources will enter the congestion controled regime and the
system becomes tricky to model or understand.  But the distinction
between a flow controlled source that knows when to stop probing and a
congestion controlled source that doesn't is the distinction I'm
drawing.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080626/56ff5668/attachment.bin