Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!sundc!hadron!cos!howard
From: howard@COS.COM (Howard C. Berkowitz)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Submission for mod-protocols-tcp-ip
Message-ID: <206@cos.COM>
Date: Wed, 22-Apr-87 13:43:00 EST
Article-I.D.: cos.206
Posted: Wed Apr 22 13:43:00 1987
Date-Received: Fri, 24-Apr-87 05:26:24 EST
References: <8704190722.AA17818@uw-apl>
Organization: Corporation for Open Systems, McLean, VA
Lines: 33
Summary: Even more refinement

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!