I just did this. It worked fine. When I put the route back the first
packet to go through got acked, and TCP started feeding the rest of
the packets into the network as fast as the ACKs came back.
Note that this test is over a local ethernet with no packet loss to
speak of.
So, a few questions for you. First, what is the latest 2.0.x kernel
you tried this with? There was a problem prior to 2.0.30 that would
have caused the behavior you observe specifically in the case of
a route drop.
Second, if you have tried this with 2.0.30 or pre-2.0.31 and still
see the behavior, then I need to see the output of a "tcpdump -S -n -tt"
trace of the problem. After the route is restored please do let things
run till the end of the transmission. I know it might be painful to wait,
but I really do need to see the whole thing. Also, make sure that tcpdump
includes the start of the session. I need to see everything from the SYN
packets to the FIN to feed it to my TCP graphing tools.
Two notes on this. The 2.0.x TCP goes into slow start when doing
retransmissions. This is probably a mistake on reflection. Packets
should only be send one for every ACK received during retransmission.
Second, if your path is lossy it can be very hard to get out of
retranmission mode. What tends to happen is that every packet you send
just after a retransmission also gets lost, and then has to be retransmitted.
In this way you never get a good time sample, and never get to reset your
RTO timer. The slow start behavior I mention above probably agravates this.
-- 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