Re: TCP (and SCTP) sucks on high speed networks

[Panos GEVROS <P.Gevros@cs.ucl.ac.uk>]

"Dr. Carsten Bormann" writes:
 |> TCP's "congestion avoidance" algorithms are not compatible with
 |> high speed,
 |> long distance networks.  The "cut transmit rate in half on packet loss and
 |> increase the rate additively" algorithm will simply not work.
 |
 |I don't believe this is just a matter of algorithm.
 |The problem is really the dynamic range of the rate adaptation equation.


-it is not a matter of algorithm -but operating range / choice of control 
parameters -
we always take b=0.5 for granted, the choice of 0.5 for AIMD multiplicative 
decrease factor b  is a wise choice (compromise due to social considerations) 
for TCP since it allowed for trade offs across a wide range of traffic 
conditions (number of flows sharing congested link)
however for a given degree of statistical multiplexing on a link (and 
reasonably long lived flows), the AIMD "b" is the factor that governs 
utilisation/performance,
the additive increase factor "a" simply is not strong enough to make a 
difference (when compared with a less congestion sensitive implementation - 
larger b)

for transfers on the same subnet when congestion avoidance/control is "turned 
off" one gets the highest possible throughput
it would be interesting to see the limiting factors to TCP performance in such 
case : disk access, copy operations, transfer to the network i/face memory 
etc. (any pointer to reports/paper discussing TCP performance decoupled from 
congestion control :0 would be much appreciated)

regards,
Panos