[ntpwg] [ntpwg Updated NTPv4 Protocol Specification/timestamplocation

[TS Glassey]

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" <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