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

[STUART VENTERS]

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.