Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!A.ISI.EDU!MILLS
From: MILLS@A.ISI.EDU
Newsgroups: mod.protocols.tcp-ip
Subject: Re: RTT's revisited
Message-ID: <8611122315.AA00325@ucbvax.Berkeley.EDU>
Date: Wed, 12-Nov-86 15:47:32 EST
Article-I.D.: ucbvax.8611122315.AA00325
Posted: Wed Nov 12 15:47:32 1986
Date-Received: Wed, 12-Nov-86 23:48:59 EST
Sender: mis@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26
Approved: tcp-ip@sri-nic.arpa

In response to the message sent  Sat, 08 Nov 86 20:46:12 -0500 from craig@loki.bbn.com

Craig,

Experiments I did several years ago (some results are in RFC-889) suggest
RTT estimators be based on the interval between the first transmission and
the first reply. Arguments supporting this have been made by RSRE and UCL
as long ago as 1979. A backoff has proved a very good idea and, so far as I
know, has been implemented in every TCP in common use. As you point out, it
is much better to err on the high side than the low, especially  especially with SYN/ACK
exchanges, since data packets tend to be fatter (longer delay) than
SYN/ACK packets. Other suggestions for tweaking the estimator are in
RFC-889.

It has been my experience that the performance of the estimator can be much
improved by increasong the rate of sample collection. This can be done by
keeping a stack of recently sent timestamps and associated sequence numbers,
then checking each off as ACKs are received. Depending on the allowable
number of outstanding packets, this can increase the rate several times.

I blow hot and cold on the usefulness of statistics based on these
data, especially when high variances are involved, as seems to be the case
now with ARPAnet navigation.

Dave
-------