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

[David P. Reed]

This is an interesting question.  However, the assertion that many hosts 
have large buffer pools is too broad and of the wrong dimensionality to 
be useful.
The key value  is the ratio:

    size_rpool * rate_service
   ------------------------------------
    size_inflite * rate_input

where size_rpool is the size of the buffer pool, the size_inflite is the 
total size of packets that will be in flight before a control signal can 
slow the source, rate_service is the service rate of the receiving 
system in terms of work it can handle, and rate_input is the input rate 
of work to the target machine (rate_input is the product of input NIC 
rate times the work-per-byte-of-input).   (Derived from Little's 
Lemma/Theorem).  That's an indicator of the probability of discarded 
work requests that will arise because the

It's a dimensionless parameter.   And in particular it illustrates that 
you need to understand how much work is done per byte and how much work 
the endpoint can actually do.

So the rwnd parameter is NOT actually measuring buffer pool size.   It 
is actually a control loop that measures the endpoint application's 
ability to do work.

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