[ntpwg] NTPv4 draft-8 to draft-9 changes / alternative paragraph

[TS Glassey]

Greg,
The question is whether that 'detection' is also impacted by the 
nondeterministic performance of the hosts IP Stack. The concept that the 
packet has to be framed is a key one here, since no one seems to be figuring 
in what evaluates the frame itself. So the real question to ask is whether 
we are talking about the instant in time when that data-point entered the IP 
Frame Buffer in the Card, or in the NIC Chip, or if there is no HW stack 
produced, the OS itself.

My point is that the issue is simply that there is no real way of defining 
how long in time it will take from the point where the electrical-edge 
transition marks the 'On Time' marker of the frame itself  enters the 
interface from the serial stream of data (OSI layer 0), to when the hosting 
SW based TCP/IP Stack passes some data to some control process where the 
time-instance is important (*what is actually layer 3 of the TCP/IP model). 
The existing system reduces the control model to one where the completed 
message represents the instant in time. So that would mean the proper 
framing and checksuming at the very least is necessary.

The problem is that without any standard of performance for how quickly 
those datagrams are processed, i.e., where to assert the on-time status, the 
assertion means nothing since the NTP protocol is currently interpreted in 
most all instances, compiled or not. That is to say, that the 'software 
evaluation' of the packet is 'emulation' per se, so without a statement on 
the performance of the emulator and how fast it MUST process to meet the 
standard, or how quickly it passes data between the layers here, there is no 
real value, except to people trying to implement HW based timekeeping...

Todd Glassey


----- Original Message ----- 
From: "Greg Dowd" <GDowd at symmetricom.com>
To: "STUART VENTERS" <stuart.venters at adtran.com>; <jack.burbank at jhuapl.edu>
Cc: <ntpwg at lists.ntp.org>
Sent: Thursday, February 28, 2008 1:59 PM
Subject: Re: [ntpwg] NTPv4 draft-8 to draft-9 changes / alternative 
paragraph


>I still think the quasi-leading edge (SOF) is a good compromise.  If you
> can only timestamp after you have received a complete packet, I wonder
> if you have the intended definition of access to the physical layer.  If
> you do, common practice is to strike a timestamp on SOF and then make a
> decision to save once you've analyzed the frame. If you have physical
> layer access only at the end (but it's deterministic), it seems like you
> could make an empirical or predefined adjustment to approximate ingress
> time.
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>
> -----Original Message-----
> From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of
> STUART VENTERS
> Sent: Thursday, February 28, 2008 1:25 PM
> To: jack.burbank at jhuapl.edu
> Cc: ntpwg at lists.ntp.org
> Subject: [ntpwg] NTPv4 draft-8 to draft-9 changes / alternative
> paragraph
>
> Jack,
>
> It looks like the changes from NTPv4 draft-8 to draft-9 are editorial
> except for a couple of new paragraphs.
>
> The editorial changes mostly clean up how references are cited.  (Nice
> job, it's much better.)
>
> The new paragraphs are as follows:
>
> On page 23 the following was added:
>   If NTP has access to the physical layer, then the timestamps are
>   associated with the beginning of the symbol after the start of frame.
>   Otherwise, implementations should attempt to associate the timestamp
>   to the earliest accessible point in the frame.
>
>
> On page 25, the following was added:
>   The Receive Timestamp and the Transmit Timestamp (set by the server)
>   are undefined when in a KoD packet and MUST NOT be relied upon to
>   have valid values and MUST be discarded.
>
>
> As an implementer, I'm ok with everything except the new page 23
> paragraph.
>
>
> I'm working on transporting time to the edge of an access network for
> one-way packet delay measurements.  The server is back in the cloud with
> 1G interfaces.  The client is at the end of a T1 link.  The goals are
> modest, to make 1mS accurate measurements.  After adding up all the
> tolerances, in order to get enough accuracy, I'm going to have to
> violate the page 23 paragraph.
>
>
> Here's an alternative paragraph which documents current practice, works
> on existing packet paths, and leaves wiggle room for future spec efforts
> with more time for careful study.
>
>
> For interoperatability with existing equipment (switches, routers, and
> the reference NTP implementation), implementations should use the
> following guidelines for associating timestamps with physical layer
> transitions.  Receive timestamps should be at the first point which
> indicates a complete, good frame has gone by.  Transmit timestamps
> should be at the first point which indicates that a frame transmission
> has started.  Accuracy requirements and media specific details are FFS.
>
>
> Regards,
>
> Stuart Venters
>
>
>
>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg