[e2e] Why do we need TCP flow control (rwnd)?
detlef.bosau at web.de
Mon Jun 30 07:33:20 PDT 2008
Lachlan Andrew wrote:
> On 26/06/2008, David P. Reed <dpreed at reed.com> wrote:
>> So the rwnd parameter is NOT actually measuring buffer pool size. It is
>> actually a control loop that measures the endpoint application's ability to
>> do work.
> That is a good point. However, most systems still do set rwnd
> based on the buffer pool size (as, I believe, the RFCs still require).
Isn't the buffer size a consequence of the application's ability to work?
When a WWW server does not fetch requests from the incoming queue,
doesn't this decrease the free buffer sprace and thus rwnd?
> There has been work on using rwnd for congestion control instead of
> to signal the buffer pool size. Mukhtar, Hanly and I did some
> <http://netlab.caltech.edu/lachlan/abstract/CLAMP-TMC07.pdf>, but were
> by no means the first.
I know. And my question is still: How does a receiver know the path
capacity? Doesn't you (either silently or explicitely) assume the "last
mile" of a network to be the bottleneck?
> There has also been work on senders selectively ignoring rwnd when
> the buffer pool is small compared to the BDP, but the receiver is
> still keeping pace with the sending rate. Sorry, I don't have refs
> for that.
Hm. Isn't this exactly the point? How does a receiver keep pace with the
sending rate (whatever this may be in a self clocking system) when the
application does not? And wouldn't particulary a large BDP cause
unnesserary delays in a proper reaction of the receiver when the
(E.g. the search engines in Google are that much overloaded it would
simply take several seconds to respond? And therefore, the search engine
will intendedly throttle the number of requests?)
Detlef Bosau Mail: detlef.bosau at web.de
Galileistrasse 30 Web: http://www.detlef-bosau.de
70565 Stuttgart Skype: detlef.bosau
Mobile: +49 172 681 9937
More information about the end2end-interest