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

From: "STUART VENTERS" <[email-masked]>
Date: Thu, 28 Feb 2008 15:24:45 -0600

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
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "Greg Dowd" <[email-masked]>
Date: Thu, 28 Feb 2008 13:59:04 -0800

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=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
STUART VENTERS
Sent: Thursday, February 28, 2008 1:25 PM
To: [email-masked]
Cc: [email-masked]
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.)

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

---

From: "STUART VENTERS" <[email-masked]>
Date: Thu, 28 Feb 2008 17:12:27 -0600

Greg,

(Assuming I guessed right on which common practice you were thinking about...)

Yes, the rx timestamp words were as intended. The reason is as follows:

Placing the rx timestamp at SOP is a common practice in IEEE-1588.  Another common practice is the forwarding behavior of packet switching gear.  It tends to start sending a packet after receiving it.

A consequence of the choice that 1588 made is that it needs on-path to support time transfer to accuracy's better than a packet time for surprisingly simple packet paths.

Since NTP is interoperating with packet switches and not 1588 gear, it seems better to choose a practice compatible with the gear NTP is interoperating with.

Regards,

Stuart

ps. I used to think that SOP was a good compromise too.  Now, with an available, better alternative, it's just a compromise.

>Greg Dowd said:

>>Stuart Venters said:

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 28 Feb 2008 17:20:57 -0800

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" <[email-masked]>
To: "STUART VENTERS" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 28, 2008 1:59 PM
Subject: Re: [ntpwg] NTPv4 draft-8 to draft-9 changes / alternative 
paragraph

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 29 Feb 2008 15:19:13 +0000

Greg,

What does the Symmetricom grandmaster do on a 100BAS-TX networ? I assume 
the NIC chip strikes the timestamp on the JK symbol pair, right? Does it 
assume a preamble is present and adjust the timestamp to the SOF octet?

Stuart's comment about the trailer timestamp is very real. If the two 
ends of the path are at different rates and a switch/router is in 
between, one or the other ends cannot produce a trailer timestamp from a 
preamble timestamp, even if the rates and packet lengths are known. This 
is very clearly evident in the note we sent. The only way to fix this is 
using preamble timestamps at the transmitter and trailer timestamps at 
the receiver. You can argue the need to do this on the basis of the 
improvement in accuracy obtained, but it is an engineering reality.

Dave