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

[Michael Scharf]

On Thu, 26 Jun 2008 at 10:41:32, Ted Faber wrote:
> Because it's explicit communication, it can be used to set sending rates
> (over a window time).
> 
> [...]
> 
> Consider endpoints using flow control to rate limit senders (by limiting
> the drain rate of the TCP buffer).  A single connection (on an
> uncongested low BDP net) would probably only see second order effects
> between using congestion control and flow control for this purpose.
> That assumes that endpoint TCP buffering was sufficient to smooth out
> the sawtoothed sending rate that TCP congestion control creates and that
> the BDP was reasonable to prevent underruns at the bottom of the tooth.
> As I say, it's easy enough to make that all work out, but congestion
> controlled senders keep probing the network and exhibit the saw toothed
> sending rate.  These are problems that you don't have with flow
> controled senders.  Flow controlled sources stop probing the network
> when they're sending at the flow rate.  Their rate rises to the flow
> controled limit and plateaus.

Just to uphold my point a little bit: This could also be achieved by a
sender-side mechanism that just clamps the congestion window at some
reasonable value (for instance, Linux allows to configure such a
threshold independent of the flow control).

True, the receiver-driven flow control inherently realizes an
equivalent function if the receive buffer sizes are small. But, isn't
it up to the sending side to decide when to stop probing the network?

Michael