srg@quick.UUCP (04/19/87)
Path: quick!srg From: srg@quick.UUCP (Spencer Garrett) Newsgroups: mod.protocols.tcp-ip Subject: Re: Time RFC 868 Summary: RTT can be estimated with 2 packets, not 4 Message-ID: <119@quick.UUCP> Date: 19 Apr 87 06:16:45 GMT References: <8704051517.a011510@Huey.UDEL.EDU> <194@cos.COM> Organization: Quicksilver Engineering, Seattle Lines: 11 In article <194@cos.COM>, howard@cos.UUCP (Howard Berkowitz) writes: > the slave RETRANSMITS what it received. The master > then calculates the difference (in time units) between > what it sent and what the slave received, and sends > that as a correction factor. ... This same protocol could be done with 2 packets instead of 4. The originator (master) should estimate the round-trip time (RTT) using its local clock instead of asking the responder (slave) to perform that function. The accuracy of the setting of the local clock is of no consequence. Only a time difference is needed.
howard@COS.COM (Howard C. Berkowitz) (04/22/87)
In article <8704190722.AA17818@uw-apl>, srg@quick.UUCP writes: > Path: quick!srg > From: srg@quick.UUCP (Spencer Garrett) > Subject: Re: Time RFC 868 > Summary: RTT can be estimated with 2 packets, not 4 > > In article <194@cos.COM>, howard@cos.UUCP (Howard Berkowitz) writes: > > the slave RETRANSMITS what it received. The master > > then calculates the difference (in time units) between > > what it sent and what the slave received, and sends > > that as a correction factor. ... > This same protocol could be done with 2 packets instead of 4. The > originator (master) should estimate the round-trip time (RTT) using > its local clock instead of asking the responder (slave) to perform > that function. The accuracy of the setting of the local clock is of > no consequence. Only a time difference is needed. Good suggestion. If, however, both the master and the slave compute the time difference, it is possible to isolate the time the slave needs to set the clock. This is probably trivial, but is a refinement. The round trip time contains three components: outbound network delay slave processing inbound network delay outbound (in the dial net) equals inbound; this is not necessarily true in all networks. We have not considered in this the effect of error control. Clearly, in a real-time, time-stamped application such as this, you do _NOT_ want to retransmit either a master or slave time synchronization message! A new one must be sent!
Mills@UDEL.EDU (04/23/87)
Howard, If you don't mind unslinging the big guns, see RFC-958 for techniques to accurately measure roundtrip delay and clock offset, which is equivalent to one-way delays. Improve sample estimates using a median filter as described in RFC-956. Improve statistical estimates by including all TCP segments, not just those allowing a single roundtrip estimate at a time. This last requires state variables for all outstanding segments that have not been ACKed. This topic has come up about once a year since early this decade. The last volley on this list (before Van Jacobson kicked off the current game) was between John Nagle and myself. My conclusion after all this is that the implementor should think more like a statistician and less like a protocol engineer. Dave