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

[Michael Scharf]

On Fri, 27 Jun 2008 at 12:18:35, John Heffner wrote:
> TCP's receiver window works far better for flow control than the AIMD
> controller used for congestion control because it is able to quickly
> announce the availability of additional capacity.  It's possible to
> announce a full BDP of available window in a single ack, whereas
> congestion control will only increase cwnd by a small amount with the
> same ack, if it is controlling the rate.  This is particularly useful
> since applications often consume data in bursts, based on availability
> of resources in the host.  They tend to be far more bursty than
> network devices that congestion control probes.  Congestion control
> does not adapt well to quickly varying capacity.

That's a good point. (But, a high-speed TCP congestion control variant
may be quite fast in grabbing additional capacity.)

> Turning the question around, what is the reason *not* to use a receive window?

Honestly speaking, I don't know. Maybe there is no reason. But I'll at
least try to name some interesting aspects:

* Less protocol complexity. Receive window auto-tuning seems to be a
  non-trivial problem. No need to agree on a fixed window scaling
  factor during connection setup, when the BDP is hardly known.
  Middleboxes have less features to mess around with.

* Users and applications would probably have to care less about buffer
  sizing. Less Web sites with TCP tweaking tips.

* Speculatively, memory management in the stack could be simpler: When
  a packet arrives, a receiver either has buffer, then the data is
  stored, or it is just dropped/marked.  Buffer space can be shared
  among several connections, no need to worry about per-flow
  allocations, window shrinking, etc.  (but, I am not an OS expert)
  
* And, well, a couple of bits in the TCP header that could be used for
  better purposes ;) 

Michael