As far as I can recall slow start is not the problem here, and the
problem will be present with 2.0.x kernels as well. The problem is not
quite so simple as slow start detecting the correct maximum window when
a drop occurs. I seem to recall seeing actual extra delays being introduced
in some traces that could not be attributed to simple packet loss.
Also, slow start behaves rather badly (correctly implemented mind you)
when the bandwidth*delay product of your real path is significantly
smaller than your window size setting. Van Jacobson noted this in his
original paper on slow start and stated that this should be considered
punishment for failing to correctly choose window size settings.
Alternatively this can also be viewed as TCP performs badly when the
available queueing on a path for a particular flow greatly
exceeds badwidth*delay. The problem is that a packet loss detection will
be delayed a long time due to the long queue length, and this starts
to have bad effects on the timing of the whole enterprise.
Summary: until someone deploys a TCP that actually tries to detect
bandwidth*delay for its path, window size settings are going to be
necessary to achieve best performance.
Cheers,
--
Eric Schenk www: http://www.loonie.net/~eschenk
email: eschenk@loonie.net, eschenk@rogers.wave.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu