[ntpwg] [ntpwg Updated NTPv4 Protocol Specification/timestamplocation

[David L. Mills]

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:

> 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 ti1me somewhat 
> moot I would think.
>
> Todd Glassey
>
> ----- Original Message ----- From: "STUART VENTERS" 
> <stuart.venters at adtran.com>
> To: <mills at udel.edu>
> Cc: <ntpwg at lists.ntp.org>
> 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?
>>
>>
>> (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
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg 
>
>