Messages in this thread | | | From | Eric.Schenk@dna ... | Subject | Re: TCP timer bug in 2.0.x | Date | Sun, 01 Jun 1997 18:16:04 +0200 |
| |
Matthew Ghio <ghio@temp0088.myriad.ml.org> writes: >I first saw it on 2.0.29. I don't recall now whether I checked it on >an unpatched 2.0.30; I'll have to recompile and test it further.
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
| |