Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!CS.UCL.AC.UK!seasterb
From: seasterb@CS.UCL.AC.UK (Steve Easterbrook)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: tcp smooth rtt function
Message-ID: <8704301837.AA16215@ucbvax.Berkeley.EDU>
Date: Thu, 30-Apr-87 15:53:27 EDT
Article-I.D.: ucbvax.8704301837.AA16215
Posted: Thu Apr 30 15:53:27 1987
Date-Received: Sat, 2-May-87 10:56:16 EDT
References: <[G.BBN.COM]30-Apr-87.09:45:20.CLYNN>
Sender: usenet@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 25


>   It sounds like the
>   implementation you were measuring decided that it was a case of the
>   retransmission being acked and therefore didn't want to corrupt the
>   srtt by including what the implementors thought was bogus data.

Ah, excellent point, but I've managed to rule this one out. I'm monitoring
retransmissions as well, and there aren't any happening at the right time to
account for the behaviour I described. It seems
the SRTT is falling to zero purely due to rounding errors with very
small round trip times. However, this doesnt preclude the resulting
behaviour being due to the implementors allowing for the circumstances
you describe. 

There seems to be two possible approaches (given that it is undesirable to
have a SRTT of zero):
Let the SRTT do whatever it wants, but never let the RTT be rounded to zero,
or do something different with the SRTT if it does reach zero. Clearly
the second approach (whether intentionally or not) is taken in the tcp
I'm using. 
Given this, what alternative value should it be set to? Has anyone
tackled this problem before? And what happens if it *is* left at zero?
(I shall now go away and find out the answer to the last question!)

Steve