Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!esosun!net1!sdcsvax!ucbvax!LOKI.BBN.COM!craig
From: craig@LOKI.BBN.COM (Craig Partridge)
Newsgroups: mod.protocols.tcp-ip
Subject: RTT's revisited
Message-ID: <8611121019.AA16479@ucbvax.Berkeley.EDU>
Date: Wed, 12-Nov-86 05:21:05 EST
Article-I.D.: ucbvax.8611121019.AA16479
Posted: Wed Nov 12 05:21:05 1986
Date-Received: Wed, 12-Nov-86 21:37:31 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 41
Approved: tcp-ip@sri-nic.arpa


As the guy whose message started this debate, I thought it might be
worthwhile to describe the mechanism I chose to try.

Basically I'm using a solution suggested by Lixia Zhang, with some tweaking.
Lixia suggested that the best estimate of the round-trip time was the
time it takes the first packet to make the loop (in RDP's case, the
time between the opening SYN and its ACK).

The idea sounded good so I put it in and promptly hit a small problem.
My simple minded implementation tended to pick timeouts
that were either too long or too short.  The problem was one of defining
where to measure the round trip from.  If you measure from the first
time you send a SYN, you tend to get a timeout estimate that is too 
high (if you had to resend the SYN several times, the likelihood that
the ACK you finally get is for the first one is rather small).  If
you measure from the time you send the most recent SYN, the estimate
is too low (again, it is unlikely that having sent several packets, the
ACK is for the most recent one).

So I tweaked the implementation.  First off, SYNs are retransmitted using
a roughly exponential backoff for the timeouts.  Then when
the ACK comes back, the estimated round-trip time is set to the timeout
currently in use.  Now this is still probably too short (if packets were
sent out at time 0, 1, 2, 4, and 8, and the ACK comes back at time
14, the estimated RTT is only 8 and if the ACK was for the second packet
the RTT should be 12), so I feed the estimated RTT for each packet
sent into the roundtrip computation.  (E.g. I set the estimated
RTT to 8, but then adjust the estimate by feeding in RTTs of 12, 16,
17, and 18).

A little testing today suggests that this makes the RTT slightly high
but close to right (and mail on the list has made it clear that if you
are going to be wrong, you'd like to be wrong on the high side).
Connecting via Goonhilly ECHO a dozen or so times always worked,
gave reasonable throughput and didn't appear to suffer excessive
retransmissions.  Of course a dozen tests really isn't enough so
I'm still fiddling, and (at the risk of increasing the mail
traffic still further) am still interested in further suggestions.

Craig