Subject: [ntpwg] [ntpwg Updated NTPv4 Protocol Specification/timestamp location

From: "STUART VENTERS" <[email-masked]>
Date: Mon, 21 Jan 2008 11:31:59 -0600

Dave,

>From the Dec 13 minutes it looks like they chose a timestamp location.  It's different, but maybe a good compromise (notes below).  Except for lacking text specifying the new location and how to know if the message uses the old or new plan, do you feel it still needs to be on the stove or is it nearly soup?

(Perhaps soup, when the text shows up.)

Regards,

Stuart

David L. Mills wrote:
> Karen,
> 
> Your meeting minutes said that some aspects of the timing point issue 
> were not discussed. From the absence of the point I made, I assumed that 
> point had not been discussed. In any case, I am glad the issue is still 
> on the stove and is to be resolved.
> 
> Dave

Karen's Dec 13 meeting notes:
>>*	Text is still lacking that clearly defines which bit in the packet 
>>the timestamp represents. The WG needs to decide on the 
>>precise approach. Three options were discussed:  
>>a) The timing bit be the first bit of the IP packet or  
>>b) the timing bit be located at the beginning of NTP payload or  
>>c) Use the start of the Ethernet frame.  
>>Discussion: The timestamp should reference the start of the 
>>NTP header. Yaakov Stein, Stewart Bryant, and Greg Dowd to 
>>work offline and submit proposed text. 

Didn't get to hear the discussion, but it looks like the start of the NTP header was chosen.

It seems doable with 1588 measuring H/W if the S/W does a correction to move the timestamp to the NTP header start. (Compensating for 42 bytes of header on a 10Meg link might cost 10 nS of uncertainty if the Ethernet clock is off by 300ppm.  Faster links have less uncertainty.)

There may be an existing versus new implementation interoperability issue if one end uses start of packet and the other uses start of NTP. (Looks like a 3us time offset for a 100Meg point to point link, correctable if the S/W knows about it.  Could be ignored or fixed in the new implementation with negotiation or configuration.)

On non point to point packet paths, it probably depends on the link speeds and header sizes on the intermediate links and the forwarding behaviors of the intermediate boxes.  Hopefully if the client and server have the same kind of links and the forwarding behaviors are symmetric, then it will all cancel out.  If the client and server have different link speeds, then putting the timestamp near the middle of the packet nearly cancels out the timeoffset.  Without knowing the exact forwarding behavior of the intermediate boxes, this seems a reasonable compromise.

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

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 21 Jan 2008 11:43:46 -0800

I have been meaning to ask - why this is necessary since what you are 
betting on is the performance of the TCP/IP (or in this case the UDP/IP) 
Stack, and since there are no performance metrics for it, that makes the 
issue of which edge represents which point in time somewhat moot I would 
think.

Todd Glassey

----- Original Message ----- 
From: "STUART VENTERS" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 21, 2008 9:31 AM
Subject: [ntpwg] [ntpwg Updated NTPv4 Protocol 
Specification/timestamplocation

> Dave,
>
>>From the Dec 13 minutes it looks like they chose a timestamp location. 
>>It's different, but maybe a good compromise (notes below).  Except for 
>>lacking text specifying the new location and how to know if the message 
>>uses the old or new plan, do you feel it still needs to be on the stove or 
>>is it nearly soup?
>
> It seems doable with 1588 measuring H/W if the S/W does a correction to 
> move the timestamp to the NTP header start. (Compensating for 42 bytes of 
> header on a 10Meg link might cost 10 nS of uncertainty if the Ethernet 
> clock is off by 300ppm.  Faster links have less uncertainty.)
>
> There may be an existing versus new implementation interoperability issue 
> if one end uses start of packet and the other uses start of NTP. (Looks 
> like a 3us time offset for a 100Meg point to point link, correctable if 
> the S/W knows about it.  Could be ignored or fixed in the new 
> implementation with negotiation or configuration.)
>
> On non point to point packet paths, it probably depends on the link speeds 
> and header sizes on the intermediate links and the forwarding behaviors of 
> the intermediate boxes.  Hopefully if the client and server have the same 
> kind of links and the forwarding behaviors are symmetric, then it will all 
> cancel out.  If the client and server have different link speeds, then 
> putting the timestamp near the middle of the packet nearly cancels out the 
> timeoffset.  Without knowing the exact forwarding behavior of the 
> intermediate boxes, this seems a reasonable compromise.
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "STUART VENTERS" <[email-masked]>
Date: Mon, 21 Jan 2008 14:40:09 -0600

You're right, you've got to have either predictable, precisely calibrated software paths, or special hardware for this to matter.  Depending on the application, some folks do.

-----Original Message-----
From: TS Glassey [mailto:[email-masked]]
Sent: Monday, January 21, 2008 1:44 PM
To: STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [ntpwg Updated NTPv4 Protocol

Todd Glassey

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 21 Jan 2008 22:38:59 +0000

Todd & Co.,

There may be a fundamental disconnect happening here. The NTP on-wire 
protocol develops four timestamps T1, T2, T3 and T4 from which the 
offset, delay and error bound are calculated. IEEE 1588 does the same 
calculations, but using hardware derived timestamps. So, neither NTP nor 
1588 provide the time directly, they provide an offset corrected for 
delay and with an error bound. This says nothing about the protocol 
stack nor the delay between T4 and actually doing the calculations, nor 
does it say anything about the delay up or down the stack, just that the 
delays on the reciprocal paths are the same.

 From this point of view where in the loop the timestamps are captured 
makes no difference as long as the delays on the reciprocal paths 
between which the timestamps are captured are the same. Notice I say 
nothing about making any provision for where the timestamps capture 
point is nor whether any "correction" is necessary to compensate for 
whatever point is actually chosen. You need not worry about whether the 
capture point is the beginning of the frame, packet or header, just that 
the reciprocal delays are the same.

My agenda is that, if it is necessary to declare an capture point for 
the purpose of the specification, then an obvious choice is the same as 
for 1588, the beginning of the first bit following the SOF. But, this is 
really not an NTP issue at all; it is an issue for the hardware and 
operating systems subject to the constraints above. The spec might well 
say the best choice for capture point is as close to the media as 
possible and this might be different for Ethernet, FDDI, satellite and 
serial (modem) media.

Dave

TS Glassey wrote:

> betting on is the performance of the TCP/IP (or in this case the 
> UDP/IP) Stack, and since there are no performance metrics for it, that 
> makes the issue of which edge represents which point in ti1me somewhat 
> moot I would think.
>
> Todd Glassey
>
> ----- Original Message ----- From: "STUART VENTERS" 
> <[email-masked]>
> To: <[email-masked]>
>>> From the Dec 13 minutes it looks like they chose a timestamp 
>>> location. It's different, but maybe a good compromise (notes 
>>> below).  Except for lacking text specifying the new location and how 
>>> to know if the message uses the old or new plan, do you feel it 
>>> still needs to be on the stove or is it nearly soup?
>>
>>
>> It seems doable with 1588 measuring H/W if the S/W does a correction 
>> to move the timestamp to the NTP header start. (Compensating for 42 
>> bytes of header on a 10Meg link might cost 10 nS of uncertainty if 
>> the Ethernet clock is off by 300ppm.  Faster links have less 
>> uncertainty.)
>>
>> There may be an existing versus new implementation interoperability 
>> issue if one end uses start of packet and the other uses start of 
>> NTP. (Looks like a 3us time offset for a 100Meg point to point link, 
>> correctable if the S/W knows about it.  Could be ignored or fixed in 
>> the new implementation with negotiation or configuration.)
>>
>> On non point to point packet paths, it probably depends on the link 
>> speeds and header sizes on the intermediate links and the forwarding 
>> behaviors of the intermediate boxes.  Hopefully if the client and 
>> server have the same kind of links and the forwarding behaviors are 
>> symmetric, then it will all cancel out.  If the client and server 
>> have different link speeds, then putting the timestamp near the 
>> middle of the packet nearly cancels out the timeoffset.  Without 
>> knowing the exact forwarding behavior of the intermediate boxes, this 
>> seems a reasonable compromise.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 21 Jan 2008 18:58:48 -0800

Thanks Stuart - that was my point. That NTP runs in a vacuum of uncertainty 
based on the system running it, the overhead, and a number of other things 
which I think make it unsuitable for this time of precision work. Rather NTP 
is a trust process tool which allows one to synchronize a set of distributed 
systems in an interreliant manner... that said I am more in favor of 
building HW dual-purpose systems that run both 1588 and NTP than to ...

Anyway, I understand your response Dave, it also is valid.

Todd
----- Original Message ----- 
From: "STUART VENTERS" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 21, 2008 12:40 PM
Subject: RE: [ntpwg] Updated NTPv4 Protocol Specification/timestamp location

You're right, you've got to have either predictable, precisely calibrated 
software paths, or special hardware for this to matter.  Depending on the 
application, some folks do.

-----Original Message-----
From: TS Glassey [mailto:[email-masked]]
Sent: Monday, January 21, 2008 1:44 PM
To: STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [ntpwg Updated NTPv4 Protocol

Todd Glassey