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

[Abraham Matta]

> isn't it up to the sending side to decide when 
> to stop probing the network?

I don't see a good reason for the sender *not* to stop probing the
network if it is told *explicitly* by the receiver about the rate at
which the sender should send?

Ideally, if the network *explicitly* tells the sender about a (fair or
not) rate at which the sender should send, then no probing by the sender
is needed (similar to the good old ATM explicit rate control ;)  

Best,
ibrahim

-----Original Message-----
From: end2end-interest-bounces at postel.org
[mailto:end2end-interest-bounces at postel.org] On Behalf Of Michael Scharf
Sent: Friday, June 27, 2008 10:50 AM
To: Ted Faber
Cc: end2end-interest at postel.org
Subject: Re: [e2e] Why do we need TCP flow control (rwnd)?

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