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

[John Day]

At 10:22 -0700 2008/06/27, Ted Faber wrote:
>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.

Well, strictly speaking it is. ;-)  Not very interesting feedback. 
You can't send until there is an ack.  No ack, retransmit.

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

True.  I wasn't trying to claim that was all there was to say! ;-) 
Just the seminal property.

Although, a good textbook is process control would tell you that you 
should always put the feedback as close to the resource to be 
controlled as you can get it.  It is just not practical sometimes. 
And it is also good to have . . . shall we say, a little slop in the 
system.  ;-)  For safety.  Too much control is as bad as too little.

>
>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.

In some cases, this is true.

>
>The goals are different -  efficiency vs. safety.

Well, ;-) safety is in the eye of the beholder.  Flow control can be 
just as much for safety as efficiency, especially with pooled buffers.

>
>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.

Strictly speaking, flow control is time shifted as well. By the time, 
information gets to the sender it is out of date and may be wrong 
(something unexpected may have happened back at the receiver).  With 
congestion control, things are much more out of date and hence even 
more chance that information could be very wrong.

If something can go wrong in the meantime, it will!  ;-)

But largely I think we agree.

>--
>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
>
>Attachment converted: Macintosh HD:Untitled 1 (    /    ) (002CF8F0)