Please do. Once again, TCP dumps are necessary for me to analyize
your observed problems. However, no unexpected behavior is observed
in tests with articifically induced packet losses. In periods
of high congestion TCP performs misserably, but this is inherent to
TCP, not to Linux's implementation of TCP.
>The patch that I posted essentially disables this slow-start.
No, it does quite a bit more than this. It starts the backoff over
for every single packet that is retransmitted. This definitely
violates the RFC's and completely disables Karn's algorithm.
This will result in going into congestion collapse if the path
RTT suddently increases. Even worse, it starts the backoff at a
fixed point (200 ms). This would be a total disaster on any medium
that that necessarily has a RTT of more than 200ms, since it will
force every packet to be retransmitted again before the RTO is increased.
Slow start is a bit of a misnomer. It actually refers to an exponetial
increase in the number of packets up to the point of loss. The RFC's
require a slow start after recovering from retransmission. Linux 2.0.x
starts the slow start early, which actually means that it sends more
packets than it strictly should.
-- Eric Schenk www: http://www.dna.lth.se/~erics Dept. of Comp. Sci., Lund University email: Eric.Schenk@dna.lth.se Box 118, S-221 00 LUND, Sweden fax: +46-46 13 10 21 ph: +46-46 222 96 38