Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbatt!ucbvax!UCBVAX.BERKELEY.EDU!karels%okeeffe
From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: tcp smooth rtt function
Message-ID: <8704302051.AA22704@okeeffe.Berkeley.EDU>
Date: Thu, 30-Apr-87 16:51:47 EDT
Article-I.D.: okeeffe.8704302051.AA22704
Posted: Thu Apr 30 16:51:47 1987
Date-Received: Sat, 2-May-87 02:02:10 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 17

I presume that you are using 4.3BSD; discussions of implementation
quirks are easiest to follow if the implementation is identified.
Things will behave strangely in 4.3 TCP if the smoothed round-trip
time becomes zero after the connection is established; it would do
just what you described.  The value of 0 is used to mean "unknown",
and causes the default (fairly long) value to be assumed.  The first
RTT sample (from first send of SYN to its ack) becomes the initial
value of the smoothed RTT.  It was assumed that the smoothed RTT
would never again be 0, as the RTT starts at 1.  I don't understand
how this can happen.

To respond to an early point in this discussion: this implementation
discards RTT estimates for segments that are retransmitted.  This
sometimes reduces the number of RTT estimates that are obtained,
but is much better than restarting the RTT timer when retransmitting.

		Mike