Folks,
This came to me personally, and I neglected to send it on to the ntp and
tictoc wg lists. My apologies for the delay. The question before us is
whether or not the interleave capability should be properly documented
and where the resources will come from to complete the effort.
Karen
-------- Original Message --------
Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in
today's tictoc meeting
Date: Tue, 12 Apr 2011 18:18:43 +0000
From: David L. Mills <[email protected]>
To: [email protected]
Karen,
The following is in response to the ID you distributed. I offer it as a
candidate for distribution to th eWG members.
Dave
This internet draft describes experiments using the interleaved
broadcast mode recently incorporated in the NTP reference
implementation. The experiments do not include the interleaved symmetric
mode, which provides similar functionality in peer-to-peer
configurations. For reference, these modes, their relevance to PTP and
related information are discussed in detail in Chapters 15 through 17 of
the book "Network Time Synchronization - the Network Time Protocol on
Earth and in Space, Second Edition, CRC Press 2011, as cited on my web
page www.eedis.udel.edu/~mills. However, most of the information
relevant to the followings discussion can be found in the white papers
at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the
documents "Analysis and Simulation of the NTP On-Wire Protocol" and
"Security Analysis of the NTP Protocol." Both of these documents
represent an update since the book was published late last year.
Readers may wonder why these documents have not been published as an
update to the protocol specification RFC-5905, which would have been the
expectation several years ago in the adolescent Internet. However, the
effort necessary to publish an ID with figures, tables and equations is
nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906
over the last five years of publishing effort is not sustainable. Thus,
unless some collaboration, perhaps the TICTOC working group, chose to
publish them as IDs, I will not commit that adventure myself.
First some nomenclature that may help in the following discussion.
Timestamps captured for the clock discipline are classed as hardstamps,
drivestamps and softstamps. Softstamps are captured during the course of
user-space processing; they may be corrupted by operating system and
device latencies, as well as transmission delays. Drivestamps are
captured during the packet interrupt routines, so are much less affected
by operating system scheduling and competition with other programs.
Hardstamps are captured by dedicated hardware means, typically in the
PHY layer of the network interface card (NIC). While the details vary,
the typical intercept point is the media independent interface (MII),
which monitors the frame level interface on a character by character
basis. The capture means is usuallt a field-programmable gate array
(FPGA) that parses the packeet, inserts timestamp data and recomputes
the UDP checksum.
The interleaved capability was originally not intended for NTP, but for
the Proximity-1 protocol specified by the Consultive Committee on Space
Data systems (CCSDS). The Proximity-1 protocol is designed for
communication between spacecraft in the vicinity of Mars and for future
missions in the vicinity of the Moon. Space data links are often
operated at very low data rates compared to typical Ethernet links.
Typical rates range from 1 kb/s to 256 kb/s with very different data
rates in each direction. Due to various queuing and transmission
operations, the output delay can reach 30 s, so it is imparities that
timestamps be captured close to the PHY layer. In the Proximity-1
desing, hardstamps are captured upon the passage of the ASM code
combination at the beginning of each transmitted frame..
Queuing and transmission delays are not the only contributors to space
data link delay. Reed-Solomon and convolutional encoding delays can be a
large contribution to the link delay; however, these delays are a
constant contribution to the lightwave transmission delay. These
contributions -- up to many seconds -- can dwarf the lightwave
transmission delays.
In the NTP interleaved design, drivestamps are captured in the device
interrupt routine - on input immediately after the frame has been
received and before copying to an input buffer; on output shortly after
the frame has been transmitted and before the buffer is released for the
following input or output frame. This can become rather awkward in the
case of NICs of the PCNET architecture, as data are copied directly from
user space to device buffers directed by DMA descriptors. Drivestamps
have been used on input for many years, but for output this is possible
only using the interleaved modes. The result avoids the latencies due to
the message digest computation, Autokey protocol data units, output
queuing and frame transmissions, typically some 10-40 microseconds.
It should be obvious from the documents that a primary motivation for
the NTP interleaved design was protection from network errors and
intruder attack. The detailed analysis and simulation are designed to
demonstrate resistance to common corruptions such as dropped or
duplicate packets and possible bogus attacks. The NTP design includes a
four-level security model, the lower two levels might be considered for
a PTP application. This is one of the most important difference between
the PTP and NTP protocol designs; however, the NTP design might be
considered overkill in a sheltered, isolated Ethernet network.
Careful observers may notice an interesting anomaly with the interleaved
broadcast mode. The preliminary volley intended to measure the roundtrip
time uses basic mode, not interleaved mode. The reason for this requires
some explanation. In times of old, the dominant concern was the 6-bone,
an international consortium of multicast application developers. In that
context with historic multicast configurations, including DVMRP and PIM,
the multicast spanning tree was far different than the unicast spanning
tree. Therefore, the preliminary volley was important to estimate the
offset of the multicast server to the multicast client and thus the
apparent one-way delay. In principle, with adroit protocolmanship, it
would be possible to change the protocol to measure the interleaved
roundtrip delay, which would be more appropriate for modern high-speed
Ethernet networks.
Karen O'Donoghue wrote:
-------- Original Message --------
Subject: [TICTOC] reminder for remote participation in today's tictoc
meeting
Date: Thu, 31 Mar 2011 09:56:35 +0200
From: Karen O'Donoghue <[email protected]>
Reply-To: [email protected]
Organization: ISOC
To: [email protected], NTP Working Group <[email protected]>
Folks,
This is a reminder that the tictoc working group will meet today from
17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF
meeting (http://tools.ietf.org/agenda/80/) has links for the drafts,
presentations, jabber chat room, and audio streaming to facilitate
remote participation.
Regards,
Karen
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
------------------------------------------------------------------------
_______________________________________________
ntpwg mailing list
[email protected]
http://lists.ntp.org/listinfo/ntpwg
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
