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

[David P. Reed]

Fred: TCP flow control (as opposed to congestion control) is not the 
subject of any significant genaralizable performance research papers I 
know of (well, Jeff Mogul did a nice paper more than a decade ago with 
others about HTTP/TCP performance in WWW servers, then, but it's 
OOOOOOLD, and I once did an unpublished[able] study paper evaluating 
performance issues in POP3/TCP server flow control).  As it should be:  
there are no "standard users" of TCP in terms of applications running on 
standardized end systems.

TCP congestion control can be isolated from flow control by presuming a 
system where the input source and consumption sink are test programs 
like "iperf" that have reproducible and standardized simple behaviors, 
and carefully controlling the OS so its control algorithm idiosyncracies 
(scheduler parameters, memory managers, etc.) are kept out of the picture.

The rwnd question (one simple question that considers the flow control 
part of TCP) is interesting, as I said.  But to consider it one has to 
consider externalities that this group and more generally the 
researchers in the field of "networking" have no good models for.   As 
just one example: does a server version of Linux running a mix of server 
applications manage its kernel buffer pool in any way similarly to a 
laptop version of MacOSX running a mix of client applications?

And since server implementations choose how they manage buffering and 
acknowledgments from a mixture of OS-dependent and TCP-dependent design 
space choices, how can a paper claim to talk about flow control problems 
as if they are a unitary and comprehensive research topic?


Fred Baker wrote:
>
> On Jun 30, 2008, at 12:55 PM, Detlef Bosau wrote:
>
>> Executive summary: TCP flow control works fine, we should leave it 
>> alone.
>
> If it did, people would. The problem is that it doesn't; there are 
> some very good papers on the reasons that statement is true. So they 
> (we) try to fix it.
>