(I just joined this list so my apologies if this has been said before.)
Regarding how to improve TCP performance in the face of link
outages, I agree with Phil (see below) that long retransmission
backoffs are the main problem to attack. I also think that an
explicit signal to restart TCP is the best way to address
this problem. I didn't know that Phil had done something like
this for packet radio until I read his message to this list.
In the work described in
R. Caceres and L. Iftode, Improving the Performance of
Reliable Transport Protocols in Mobile Computing Environments,
IEEE JSAC, Vol. 13, No. 5, June 1995.
http://www.research.att.com/~ramon/papers/jsac95.ps.gz
we implemented such explicit signals to trigger TCP fast
retransmissions after an abrupt handoff between wireless cells
(e.g., in an infrared LAN). When the handoff completed,
the mobility management code on the mobile (which knew that
connectivity had been restored) sent an internal signal
to the TCP code on the mobile, which then went into fast
retransmission.
The TCP code on the mobile also sent a signal to the remote
TCP. We tried this two ways. In one, the signal was carried
in an ICMP packet. In the other, the mobile sent three
duplicate TCP acknowledgements. The remote TCP also went
into fast retransmission when it received this signal.
For the handoff situation, these signals worked pretty well
in the end-to-end fashion I just described. For the general
link outage situation, the ICMP message could be sent in both
directions of communication from any network node that knows
the link is back up.
--Ramon
> From: Phil Karn <karn@homer.ka9q.ampr.org>
>
> Yes, but. Yes, it's unreasonable to expect TCP to continue working if
> you pull out the network plug. But I would like TCP to recover more
> quickly when the plug is put back in. Right now, if the plug has been
> out for a while TCP won't discover that the link has returned until
> the next retransmission timeout. And with the exponential backoff in
> effect, this can get pretty long.
>
> I suggest something along the lines of a "ICMP Reachable" message sent
> by routers to recent senders of packets it had to discard due to a
> broken link that has since returned. Receipt of this packet would
> cause TCP to force an immediate retransmission, or to transmit an
> empty ACK if no send data is pending.
>
> I did something like this 10 years ago in my TCP/IP package for
> amateur packet radio. I called it a "remote kick" command packet and
> carried it in UDP. While it had to be manually invoked, it worked very
> well.
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST