[e2e] TCP un-friendly congestion control

[J. Pan]

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