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

[Ted Faber]

On Fri, Jun 27, 2008 at 09:31:05PM -0400, John Day wrote:
> 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.

I was thinking of a hard reservation system.  You could send, say
streaming voice in such a system without waiting for an ACK - lost
packets would be a gap in the voice.

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

I understand. :-)

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

Feedback congestion control is a tricky problem to solve correctly. :-)

Not only is all the data an endpoint has to go on out of date (and
probably inferred), the different endpoints may be out of date by
different amounts.  Worst cases can get very exciting. :-)

Fortunately, slowing down when there's trouble and being conservative
seem to provide a reasonably fail-safe environment.  Today.

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

Sure.  But with flow control someone knows all the players (in this case
the receiver) and you know who will lose if your flow control fails.  In
a reservationless network like the Internet, you don't (generally) know
who will suffer if a router collapsed from congestion, nor do you know
the set of endpoints that are cooperating (loosely) to keep a router
from collapsing.

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

Indeed.  Flow control information is time shifted just as much as
congestion information, but at least it isn't a guess as well. :-)

-- 
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/20080630/afe1c041/attachment.bin