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

[Luca De Cicco]

Dear Michael,

an elegant explanation of the flow control is given in the paper:

S. Mascolo, "Modeling the Internet congestion control using a Smith
controller with input shaping", Control Engineering Practice, Vol 14,
Issue 4, April 2006

In particular, in the paper it is shown how the flow control can be
modeled as the outer loop of the congestion control machinery.
Flow control is more efficient than AIMD since it relies on
explicit feedback as opposed to the implicit feedback that congestion control 
algorithms normally take. Moreover, since flow control happens when
receiver acts as the bottleneck, isn't dropping at the receiver side
(not counting retransmissions) a waste of network resources?

However, flow control just asks for 16 bit each ACK to work, isn't it
cheap enough? :)

Best,
Luca De Cicco

On Thu, 26 Jun 2008 09:38:37 +0200
Michael Scharf <michael.scharf at ikr.uni-stuttgart.de> 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?
> 
> It is well known that TCP realizes both congestion control and flow
> control, and that a TCP sender therefore maintains two different
> windows (cwnd and rwnd). Obviously, the congestion control protects
> the path from overload, while the flow control protects the receiver
> from overload.
> 
> However, I have some difficulties to understand why the flow control
> part and receiver advertized window is actually needed.
> 
> Instead of reducing rwnd, an overloaded receiver running out of buffer
> space could simply drop (or mark) new arriving packets, or just
> refrain from sending acknowledgements. As a reaction to this, the
> sender probably times out and the TCP congestion control significantly
> reduces the sending rate, which reduces the load on the receiver, too.
> 
> To my understanding, a fine granular receiver advertized window is
> much more efficient if the buffer sizes are of the order of a few
> packets only. But I guess that most of today's Internet hosts have
> larger buffers, and therefore they hardly need a fine granular flow
> control.
> 
> Are there reasons why TCP can't just use its congestion control to
> handle slow receivers?  Do I overlook some aspect?  Any hint or
> reference would be welcome.
> 
> Michael


-- 
Luca De Cicco
PhD Candidate 
Politecnico di Bari (Italy)
http://c3lab.poliba.it/index.php/LDC