[e2e] TCP un-friendly congestion control

[Cottrell, Les]

We have some early comparisons of various TCP stacks on lightly loaded production networks that may be of some interest.  See 
http://www-iepm.slac.stanford.edu/monitoring/bulk/tcpstacks/

There are also some measurements on dedicated testbeds available at:
http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/

-----Original Message-----
From: J. Pan [mailto:jpan at fla.fujitsu.com] 
Sent: Friday, June 06, 2003 7:25 PM
To: Craig Partridge
Cc: Luigi Rizzo; end2end-interest at postel.org
Subject: Re: [e2e] TCP un-friendly congestion control



Maybe what I want to say should be off this thread. I think that TCP was designed for a moderate-to-high multiplex scenario. All TCP sender wants to do in congestion control is to infer a reasonable bottleneck share with other competing flows. It was never intended to fit the scenario with a very low multiplex. E.g., a TCP with a fixed (long and fat) data pipe should give 75% utilization (router buffer is also counted as network resource), due to the fact that TCP only takes packet losses as control signal. So comparing the friendliness in the Internet and in those dedicated networks does not give too many meaningful results.

For TCP in those low multiplexed networks, the problems are two-fold. Slow Start does not scale with fat pipe (exponential increase overshoots too much when the number becomes too large); once there is a loss, it takes too many rtts for TCP to catch up with long and fat pipe. I think that it is a good idea to use other control signals such as round trip delay, but they are not as robust as packet losses (although packet loss also suffers robustness issue when there are both congestion loss and transmission error in many not-so-perfect links).

It should be nice if there are more experimental results in those low multiplexed and dedicated networks (as well as experiment settings) published, so the third party can take a deep look.


Just my two cents,

Jianping