Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!LOKI.BBN.COM!craig
From: craig@LOKI.BBN.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: re: A New TCP Retransmission Algorithm
Message-ID: <8704081656.AA02575@ucbvax.Berkeley.EDU>
Date: Wed, 8-Apr-87 11:59:15 EST
Article-I.D.: ucbvax.8704081656.AA02575
Posted: Wed Apr  8 11:59:15 1987
Date-Received: Sat, 11-Apr-87 07:08:10 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 23
Approved: tcp-ip@sri-nic.arpa


Phil,

    I've been looking at the same problem from the perspective of
RDP for some months.  Some of my conclusions are in a paper I'm
presenting at the June USENIX.  Most of them are the same as yours,
except I came up with a different selection algorithm based on the
assumption that the network *usually* maintains relative order
(if packet A is sent before packet B, then is is likely that A
will reach the destination before B).

    By the way, in support of the view that we need to look at
retransmission timeouts, I've seen the SRTT explode at loss rates
below 10% on some systems.

    One other point -- your algorithm is engaged in throwing away a
certain number of good RTT values because the filtering isn't perfect.
If the RTT suddenly increases sharply, you have to throw out the first
packet that has the new RTT, and wait for the second packet to be
accepted.  Out of curiousity, what is beta in your implementation?
I.e., how much does the RTT have to increase to cause this problem?

Craig