karn@MOUTON.ARPA (Phil R. Karn at mouton.ARPA) (12/20/85)
I believe the behavior you describe is the fault of the 4.2BSD implementation, not the adaptive algorithm in RFC-793 (although it could be improved; see Mills' RFC-889 on Internet delay experiments). The version we had (which admittedly had been hacked extensively before we got it) restarted the round trip timer whenever a retransmission timeout occurred. If the retransmission is caused by a low RTT estimate rather than a dropped packet, resetting the timer causes it to measure the time between the second (or later) transmission attempt and the arrival of the first transmission's ack. Obviously this results in an erroneously low round trip estimate, thus perpetuating the problem. Since the initial RTT estimate was far too short to begin with (.5 sec), this guarantees lousy performance over a slow link, with little or no chance for adaptation. I've hacked our version to leave the round trip timer alone during retransmissions. This does compute an erroneously LONG estimate of RTT when the path is lossy, but since network congestion is probably the single biggest cause for dropped packets anyway it seems better to err in this direction. An initial estimate of 5 seconds seems to work well over our (very slow) X.25/CSNET connection to the Internet. I also highly recommend the Nagle tinygram-avoidance technique (RFC896). It makes a world of difference when running across slow links. Phil Karn