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

[Ted Faber]

On Fri, Jun 27, 2008 at 04:50:11PM +0200, Michael Scharf wrote:
> 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).

But "reasonable value" is sometimes decided by the receiver.  Don't
think workstation; think iPhone.  Or embedded webserver on an MP3
player.  Or my $70 OpenWRT-enabled router.

If the sender has a rate limit, it just calls send at a frequency
appropriate to that rate.  This may mean that the sender has many fewer
outstanding packets that cwnd allows; it's a reason for the FlightSize
variable in RFC2581.

A rate-limited sender on an uncongested network will not show a
saw-toothed sending rate (in steady state).

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

I don't think so.  It's an agreement between the sender and receiver.
TCP doesn't make any assumptions about which (if either) endpoint is
more constrained.  Having the sender probe for capacity it cannot use
seems unnecessarily disruptive to me. 

The receiver sets one bound (the receiver window) and the sender sets
another (send buffers + rate at which it tries to send traffic).  Once
either the unconstrained sender reaches rwnd or the constrained sender
has no traffic to queue the probing stops.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080627/51a45f4f/attachment.bin