Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!esosun!ucsdhub!sdcsvax!ucbvax!G.BBN.COM!CLYNN From: CLYNN@G.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp smooth rtt function Message-ID: <[G.BBN.COM]30-Apr-87.09:45:20.CLYNN> Date: Thu, 30-Apr-87 09:45:00 EDT Article-I.D.: <[G.BBN.COM]30-Apr-87.09:45:20.CLYNN> Posted: Thu Apr 30 09:45:00 1987 Date-Received: Sat, 2-May-87 01:06:34 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Steve, It is well known that a TCP receiving an ack for a segment does not know if the ack is for the original transmission or one of the retransmissions. The spec does not offer much help to the implementor, consequently different algorithms have been explored. IF one measures the rtt from the most recent (re)transmission, then the possibility exists that an ack of one of the prior transmissions may arrive "about the same time" as the "next" retransmission. If it is just a little before, the segment acked, it is not retransmitted, and the rtt is "reasonable", so one uses it; if it is just a little after, who knows ... one hopes for the best (and frequently looses); if it arrives at the "same time", who knows. 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. Aside: I believe one can prove that if the rtt is not measured from the original transmission (and no other information is available to decide what is being acked) then it is possible for the srtt to converge to a value less than the "correct" value; this causes every packet to be retransmitted, even if it isn't lost. I think there is enough latitude in the protocol to allow an implementer to cause the other end to unknowingly provide some good "hints" about what is being acked, but that is another discussion. Charlie