[e2e] Why do we need TCP flow control (rwnd)?
David P. Reed
dpreed at reed.com
Tue Jul 1 06:20:33 PDT 2008
Michael Scharf wrote:
> I absolutely agree that the "networking" community has difficulties to
> model these issues. Actually, this is another excellent motivation for
> my original question: If we can't model flow control, why we don't we
> just get rid of it?
> Just joking...
I'm serious, though.
In the case of POP3, there is an application layer "flow control" in the
handshakes. This *partly* would obviate the need for rwnd - if
messages were all shorter than a threshold. My conclusion when I
studied this is that TCP flow control and POP3 handshakes actually get
in each others' way.
If we implemented end-to-end flow control in such a way that apps could
dynamically adjust rwnd directly, I'm sure many would. The current
"conservative" approach is neither fish nor fowl.
Note that "tuning" an application often involves running a high priority
application thread to accept data as it arrives, storing it into
app-layer buffers, thus using a very indirect means to achieve better
"impedance matching" of apps to the rwnd based, excessively conservative
flow control. (doing this in POP3 is hard, because you can't "send
ahead" acknowledgments too safely, though hacks can be done).
Basically, an app would like to "pipeline" the transfer so that at the
time it is ready for a new data unit, that data unit arrives. Flow
control should be studied in the context of app-layer pipelining.
(One can also do app-layer pipelining by using multiple TCP connections
concurrently, essentially using a "rotary" protocol at the app layer
that "fetches ahead in parallel").
More information about the end2end-interest