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

[Michael Welzl]

Hi,

If the receiver limits the rate, you don't get the sawtooth
behavior, with packets being lost whenever you exceed the
congestion limit. No fluctuating rate, but a static one -
this is more efficient.

Cheers,
Michael


On Thu, 2008-06-26 at 09:38 +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?
> 
> 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
>