Subject: [ntpwg] RFC 2030 Errata Error.

From: MS <[email-masked]>
Date: Tue, 15 Dec 2009 15:31:08 +0000

Hi,

First of all I hope it is all right to post to this mailing list - as an NTP 
newbie I'm hesitant to send email to the heavy weights, but having found an 
RFC 2030 Errata error this seemed to be the most appropriate place to inform 
those who can make the changes. That said...

I have some comments on a proposed correction to RFC 2030 in its Errata, 
specifically Errata ID: 515.

"Errata ID: 515, Reported By: vijeeshep, Date: 2005-12-16"

RFC 2030: http://www.rfc-editor.org/rfc/rfc2030.txt
RFC 2030 Errata: http://www.rfc-editor.org/errata_search.php?rfc=2030

Errata ID: 515 makes a 'correction' to the local clock offset formula 
published in RFC 2030. I believe this 'correction' is wrong.

Originate Timestamp T1   - time request sent by client
Receive Timestamp T2     - time request received by server
Transmit Timestamp T3    - time reply sent by server
Destination Timestamp T4 - time reply received by client

Formula for the local clock offset T, from RFC 2030 and from Errata ID: 515:

RFC 2030:
T = ((T2 - T1) + (T3 - T4)) / 2

Err. 515:
T = ((T2 - T1) + (T4 - T3)) / 2

To make it a little easier to think about, I'll put that into words:

RFC 2030:
((Server Receive - Client Send) + (Server Send - Client Receive)) / 2

Err. 515:
((Server Receive - Client Send) + (Client Receive - Server Send)) / 2

In the notes for Errata ID: 515 it says:

"Because T4 always will be greater than (or equal to) T3".

Why would the destination timestamp, the timestamp the client received at, 
always be greater than or equal to the transmit timestamp, the timestamp the 
server sent at?

The answer is that it would not be. The destination timestamp is only 
greater than the transmit timestamp in one of these 3 cases:

1) The times of both clocks are already the same.
2) The client's clock is ahead of the server's clock.
3) The client's clock is behind the server's clock by less time than the 
time taken to transmit the message from server to client.

Here is a real world example in which the client's clock was set to 
1900-01-01 00:00:00, just before sending to the server.

NOTE: These are not figures that I've created for the purposes of 
demonstration but the actual figures from sending and receiving a NTP 
message using the NTP server, 'nist1.datum.com'.

The relevant timestamps from the incoming NTP message along with the 
destination timestamp:

Round Trip Delay: 656
Formula: (T4 - T1) - (T3 - T2), as corrected in RFC 2030 Errata ID: 517.

Originate Timestamp: 687
1900-1-1 - 01 January 1900
0:0:0:687

Receive Timestamp: 3469869414195
2009-12-15 - 15 December 2009
12:36:54:195

Transmit Timestamp: 3469869414195
2009-12-15 - 15 December 2009
12:36:54:195

Destination Timestamp: 1343
1900-1-1 - 01 January 1900
0:0:1:343

Local Clock Offset Calculations:

RFC 2030: T = ((T2 - T1) + (T3 - T4)) / 2:
((3469869414195 - 687) + (3469869414195 - 1343)) / 2 = 3469869413180

Err. 515: T = ((T2 - T1) + (T4 - T3)) / 2:
((3469869414195 - 687) + (1343 - 3469869414195)) / 2 = 328

If setting the client's clock immediately after receipt of the NTP message.

Using the local clock offset formula from RFC 2030 would set the client's 
clock to:

Local Clock Offset + Destination Timestamp: 3469869413180 + 1343 = 3469869414523
Client Clock Time To Set Timestamp: 3469869414523
2009-12-15 - 15 December 2009
12:36:54:523

Using the local clock offset formula from Errata ID: 515 would set the 
client's clock to:

Local Clock Offset + Destination Timestamp: 328 + 1343 = 1671
Client Clock Time To Set Timestamp: 1671
1900-1-1 - 01 January 1900
0:0:1:671

Conclusion:

Using the local clock offset formula as specified in RFC 2030 results in the 
client's clock being set to 328 milliseconds greater than the server's 
transmit timestamp. With the round trip delay being 656, the calculation 
appears reliable.

Using the local clock offset formula as specified in Errata ID: 515 results 
in the client's clock being set to 1.671 seconds after midnight on the 
1900-01-01, incorrect by approx. 15.5 days short of 110 years.

Clearly the proposed correction made by Errata ID: 515 is incorrect.

I really hope I haven't made any mistakes, this has all been checked so I am 
pretty sure it is all accurate.

Regards,

Matthew
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Sun, 17 Jan 2010 23:25:28 -0500

MS wrote:
> Hi,
> 
> First of all I hope it is all right to post to this mailing list - as an
> NTP newbie I'm hesitant to send email to the heavy weights, but having
> found an RFC 2030 Errata error this seemed to be the most appropriate
> place to inform those who can make the changes. That said...
> 

That RFC is about to be obsoleted. See the draft that replaces it:
http://tools.ietf.org/id/draft-ietf-ntp-ntpv4-proto-13.txt

in particular section 8.

> Why would the destination timestamp, the timestamp the client received
> at, always be greater than or equal to the transmit timestamp, the
> timestamp the server sent at?
> 

I agree. That's an error. It is incorrect to assume that T4 is always
greater than T4. I better way of writing the function is:

theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]

> Formula: (T4 - T1) - (T3 - T2), as corrected in RFC 2030 Errata ID: 517.

delta = T(ABA) = (T4-T1) - (T3-T2

is the way it is written in the draft.

Danny
> Using the local clock offset formula from RFC 2030 would set the
> client's clock to:
> 
> Using the local clock offset formula as specified in RFC 2030 results in
> the client's clock being set to 328 milliseconds greater than the
> server's transmit timestamp. With the round trip delay being 656, the
> calculation appears reliable.
> 
> Using the local clock offset formula as specified in Errata ID: 515
> results in the client's clock being set to 1.671 seconds after midnight
> on the 1900-01-01, incorrect by approx. 15.5 days short of 110 years.
> 
> I really hope I haven't made any mistakes, this has all been checked so
> I am pretty sure it is all accurate.
> 
> Regards,
> 
> Matthew

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.