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

[Ted Faber]

On Fri, Jun 27, 2008 at 08:04:43AM -0400, John Day wrote:
> The definitions I have come to use are:
> 
> Flow control is a feedback mechanism colocated with the resource 
> being controlled.
> 
> Congestion control is a feedback mechanism not co-located with the 
> resource being controlled.
> 
> And there in lies the rub.

For TCP this is a key distinction.  I'm going to pick nits below, but
I agree that the difference in information age and accuracy is key to
the function of these components in TCP.

However, with things like ECN (or re-ECN or XCP) it gets fuzzier.  And
if you get outside TCP one might use a strict reservation policy to
avoid congestion (stop-and-wait queueing anyone?), which isn't feedback
at all.

There is a distinction in goals between the two in addition to the
distinction in mechanism.

Flow control is 2 endpoints cooperating to properly use a
connection-specific resource (specifically receive buffers).

Congestion control is an unknown number of players trying to avoid
exhausting shared resource(s) and compromising everyone's connectivity.

The goals are different -  efficiency vs. safety.

In TCP an endpoint makes it's congestion control decisions using
feedback based on a time-shifted sample of network buffer state.  And I
agree with you: therein lies the rub.  

-- 
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/20080627/30ed32e2/attachment.bin