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

[Ted Faber]

On Tue, Jul 01, 2008 at 10:08:01AM +0100, Jon Crowcroft wrote:
> on the duality of flow control & congestion control 
> and the real "end" in end-to-end:
> 
> so i think keshav made a useful point - 
> one could have a predictive rwnd window scheme -

Keshav's right as usual, both about how one could extend receiver window
and that it's basically a simple concept.

> 1.
> so in this situation one can send a receive window that gets a
> sensible rate.  on the other hand, one could ALSO send a gratuitious
> ECN instead from the end point.
> 
> since the end point of the session (not transport) is a hop away from
> the tcp end point (not such a rare occurance in these wireless spliced
> days:) then this seems entirely the same as a router sending an ECN
> (or dropping a packet:)

This is true as far as it goes, and it's pedagogically interesting,
which I'm sure is your point.

But for all the folks who think there's some engineering reason to
substitute ECN for receiver window: using ECN this way is foolish.  It
sends less information to the endpoint ("something got lost" vs. "I can
accomodate x more bytes") at exactly the same speed.  The receiver
window parameter is there to address this common case in the simplest
manner possible.  Use it.

One of the biggest problems in TCP congestion control is lack of
information.  When you have a channel to communicate with precision, use
it. 

> 
> 2.
> corrollary:
> of course, routers could also change the receive window on returned packets 
> (If the route was symmetric) and recompute the checksum appropriately,
> instead of using precious ECN bits or dropping packets:)
> 
> 
> mind you, a router has a harder task to predict things than a host.

As I recall there were a set of network appliances in the 1990's that
manipulated the receiver window to do traffic shaping.  Packeteer comes
to mind, but that name may be my foggy memory.  So folks have played
with this, though I think it's a misuse of the field.

Your concerns about symmetry are spot on.

> so maybe the tcp/ip people got things roughly right, eh? 

As far as the receiver window, I agree.

-- 
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/20080701/c26440b6/attachment-0001.bin