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

[Michael Scharf]

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