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

[David P. Reed]

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").