[e2e] Why do we need TCP flow control (rwnd)?
michael.scharf at ikr.uni-stuttgart.de
Fri Jun 27 11:34:21 PDT 2008
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 ;)
More information about the end2end-interest