Internet DRAFT - draft-marlow-tictoc-computer-clock-accuracy
draft-marlow-tictoc-computer-clock-accuracy
D. Marlow,
TICTOC S. Knickerbocker,
Internet Draft T. Plunkett
Intended status: Informational NSWC-DD
Expires: April 28, 2012 October 28, 2011
Network Time Mechanisms for Improving Computer Clock Accuracy
draft-marlow-tictoc-computer-clock-accuracy-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 28, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Marlow/Knickerbocker/Plunkett Expires April 28, 2012 [Page 1]
Internet-Draft Improving Computer Clock Accuracy October 2011
Abstract
This draft describes network time synchronization mechanisms that
may enable increased accuracy, beyond that possible with the current
Network Time Protocol version 4 standard, to the time of computer
clocks. The mechanisms considered are those that will provide
improved estimates as to when a packet is put on the network,
transferred across a network, or taken from the network. Potential
standardization actions will be considered for the mechanisms
considered, though no such actions are recommended at this time.
Table of Contents
1. Introduction...................................................2
1.1. Motivation for Increased Performance......................3
1.2. NTP/PTP Commonality and Differences.......................4
1.3. Performance and Security Threat/Network Error Tradeoff....4
2. Use Case Targeted..............................................5
2.1. Emerging Need for NTP and PTP Commonality.................5
3. Approach.......................................................6
4. Mechanisms Considered..........................................6
4.1. NTP Interleaved Modes.....................................6
4.1.1. Standardization Considerations.......................7
4.2. Use of IEEE 1588 PTP and 802.1AS Mechanisms in the
Underlying Network Service (e.g., Network Interface Controller
[NIC]).........................................................7
4.2.1. Standardization Considerations.......................7
4.3. Use of IEEE 1588 PTP to Synchronize Computer Clocks.......7
4.3.1. Standardization Considerations.......................8
5. Initial Experimentation........................................8
5.1. Naval Surface Warfare Center, Dahlgren Division (NSWCDD),
Experimentation................................................8
5.2. Future Metrics and Benchmarks Standard....................9
6. Analysis of Results...........................................10
6.1. Analysis of Initial NSWCDD Experimentation...............10
6.2. Analysis of Published Results............................10
7. Future Experimentation........................................11
8. Security Considerations.......................................12
9. Internet Assigned Numbers Authority (IANA) Considerations.....12
10. Conclusions..................................................12
11. Informative References.......................................13
12. Acknowledgments..............................................13
1. Introduction
The IETF Timing over IP Connection and Transfer of Clock (TICTOC)
Working Group was formed to investigate emerging needs to distribute
highly accurate time and frequency information over Internet
Protocol (IP) and Multiprotocol Label Switching (MPLS) Packet
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 2]
Internet-Draft Improving Computer Clock Accuracy October 2011
Switched Networks (PSNs). In this draft, new mechanisms beyond those
identified in the Network Time Protocol version 4 (NTPv4) standard
(i.e., Request for Comment 5905) are considered to provide increased
time synchronization accuracy for computer (i.e., operating system)
clocks' time and frequency. The mechanisms considered are those that
will provide improved estimates as to when a packet is put on the
network, transferred across a network, or taken from the network.
This draft identifies a set of mechanisms that are candidates for
experimentation. Standardization considerations will be described
for the mechanisms identified.
In this draft, the authors examine methods for improving NTPv4 time
synchronization performance. The authors are requesting comments and
contributions on the mechanisms described and on additional
mechanisms that should be considered. It is hoped that discussions
within the IETF TICTOC Working Group will motivate experimentation
that will lead to standardization actions to enable better accuracy
to those utilizing a future Network Time Protocol (NTP)
specification.
1.1. Motivation for Increased Performance
There are two reasons to improve upon the time synchronization
performance that is currently available from the NTP. Not only is
the increased performance needed for existing product designs that
would make use of the added performance if it were available, but it
is expected that new uses will be identified that are not even
possible until performance is improved. This is similar to how
network speeds are increased every several years, and the uses for
the increased network bandwidth soon follow.
The current methods for achieving an increase in time
synchronization performance involve use of a technology separate
from the existing computer network (e.g., Inter-Range
Instrumentation Group technology) or use of a technology like
Precision Time Protocol (PTP), which is defined in the Institute of
Electrical and Electronics Engineers (IEEE) 1588, "Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems." With PTP, the computer applications must interface with
the installed PTP hardware in order to read time from its
oscillator. There is a lot of resiliency built into NTP, which does
not exist in the PTP protocol. It is unknown what happens to the
time provided by the PTP hardware when a network switch in the
network path to the time source is temporarily unavailable (i.e.,
the network switch gets rebooted). It would be beneficial to have
the resiliency of the NTP algorithms be paired with the highly
accurate PTP hardware-based time distribution.
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 3]
Internet-Draft Improving Computer Clock Accuracy October 2011
1.2. NTP/PTP Commonality and Differences
NTP and PTP are both packet-based protocols for exchanging time with
a time server over a computer network. Both protocols are used to
determine the offset between two independent clocks. Both use
embedded algorithms to construct a shortest path spanning tree for
obtaining time from a master time source through intermediary time
sources to time clients. Both assume network paths are symmetric and
both have their own methods for addressing network delays that are
not symmetric. NTP uses its algorithms to determine which of several
consecutive time measurements are most accurate and uses that
measurement. PTP makes use of hardware means of measuring delays as
packets traverse intermediate network devices and corrects its
received time information based upon those measured delays. Both
have similar authentication provisions based on cryptographic
message digests. [1, page 306]
NTP is engineered to synchronize computer clocks in an extended
network, while PTP is engineered to synchronize device clocks in a
segmented LAN [Local Area Network]. [1] Because PTP has the ability
to measure actual packet delays and to correct for them, PTP can
provide the most accurate measurement of clock offset between two
clocks. PTP does not define the method for synchronizing that clock
once the highly accurate time measurements have been obtained. PTP
is normally used to synchronize a relatively high-quality hardware
clock located on an interface card and does not synchronize the
operating system clock. NTP, on the other hand, possesses the
ability to synchronize the commodity-quality system clock based on
received clock offset measurements. NTP is normally utilized where
relatively long update intervals are required to minimize network
load, while PTP is normally utilized on a high-speed LAN with no
such requirement and operates with update intervals on the order of
2 seconds. On a LAN with reduced phase noise and shorter update
intervals, PTP can provide far better performance than NTP, even if
using the same commodity oscillator. [1, page 306] The NTP
algorithms have a lot of resiliency so that operating system clocks
stay stable despite the conditions on the network.
1.3. Performance and Security Threat/Network Error Tradeoff
Through discussions in the TICTOC Working Group, it has been pointed
out that one of the differences between NTP and PTP are security
threats and network errors that each is designed to work around.
While PTP has few capabilities to work in the presence of security
threats and network errors, NTP has been designed to work "in the
wild." The inherent resiliency built into the NTP protocol
contributes directly to its security, by handling security threats
via the detection of duplicate, unsynchronized, or bogus packets.
Thus PTP needs private isolated network interconnections, while NTP
can run on the Internet in the presence of major threats (e.g., man-
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 4]
Internet-Draft Improving Computer Clock Accuracy October 2011
in-the-middle attacks). In an e-mail to the TICTOC working group on
June 8, 2011, Dr. David L. Mills wrote "... 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(s) between the PTP and NTP protocol designs; however, the
NTP design might be considered overkill in a sheltered, isolated
Ethernet network." [2]
2. Use Case Targeted
The use case considered in this Internet-Draft is a dense
concentration of computing elements connected by a network. A
satellite-based time source (e.g., Global Positioning System [GPS])
is used for synchronizing primary time servers. Secondary time
servers and leaf computing elements are synchronized to the primary
time servers over the network. In this use case, there are
approximately 150 or so total computers where there are three to
four levels of time servers. These time servers may have to
communicate to each other through layer 2 and layer 3 network
switches, which could be 10-20 different layer 2 subnetworks. All of
the computers are connected together through gigabit or faster
network connections. In this environment, there will be some groups
of computers that will need to synchronize to each other to within a
microsecond, while other groups of computers only have to be
synchronized to each other to within a millisecond. In this use
case, there is one interconnected time synchronization scheme where
NTP, PTP, or a combination of both is used to meet all time
synchronization needs. The use case presented here does not identify
a defined set of security threats or network errors in which a
network time synchronization mechanism is to be able to safely work;
however, proposed network time synchronization solutions need to
identify the tradeoff taken between the performance achievable and
the security threats and network errors within which it is intended
to work.
2.1. Emerging Need for NTP and PTP Commonality
Because of its accuracy capabilities, PTP is beginning to replace
NTP as the base protocol for time clients in dense computing sites.
This results in an implementation in which some hosts use PTP while
others within the same building and sometimes within the same room
use NTP. Over time, hosts are being changed from NTP to PTP. This
leads to an emerging need to provide similar approaches for basic
time service functions for operational ease of managing time
distribution assets. Examples of functions where commonality is
considered to be an emerging need include providing synchronization
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 5]
Internet-Draft Improving Computer Clock Accuracy October 2011
of computer clock, providing management to time clients, and
configuring timeservers. A standard means of synchronizing computer
clocks for both protocols is of particular interest; there appears
to be no value in using different methods when the hosts that both
protocols are supporting are often working within the same system.
In addition, there are highly accurate PTP time clients that could
serve as highly accurate secondary timeservers for NTP time clients
if this capability were supported in vendor products.
3. Approach
The approach taken by the authors includes determining what the
current accuracy capabilities are with NTPv4 and investigating
additional mechanisms that may provide improvements in accuracy. Any
degradation in security capabilities and/or the ability to work
through network errors needs to be assessed for any mechanism for
which a standards action is pursued. Through experiments of those
additional mechanisms, estimations of improvements can be
calculated. Depending on the standardization difficulty and
potential benefits offered, more than one standardization action may
be recommended in the future.
4. Mechanisms Considered
4.1. NTP Interleaved Modes
The NTP interleaved modes are an extension of the NTPv4 protocol,
which is included in the current NTP distribution [1]. It utilizes
Broadcast and Symmetric modes (client/server is not supported) and
is designed to be backward compatible (i.e., not affecting NTP
implementations that do not use the interleaved extensions). It also
utilizes the same NTP packet format as the current standard NTPv4.
Security and network robustness capabilities were a major design
factor for NTP interleaved; thus, it is expected that an NTP
interleaved configuration is at least as secure or resistant to
network errors as any other NTP operational mode. NTP interleaved
uses an IEEE 1588 PTP-like feature that provides a follow-up packet
with a better estimate of when a previous NTP packet was sent on the
network and a message exchange sequence to determine network mean
path delay.
This mechanism could be used by some of the primary time servers for
synchronizing secondary (i.e., lower stratum) time servers and leaf
computing elements, which have very accurate time synchronization
requirements.
Future experimentation may identify what gains are possible with
this mechanism. Dr. David L. Mills pointed out in TICTOC Working
Group discussions that the interleaved modes provide a major
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 6]
Internet-Draft Improving Computer Clock Accuracy October 2011
performance benefit when large Protocol Data Units are used (e.g.,
when NTP is used with the Autokey Protocol for time server
authentication). [3]
4.1.1. Standardization Considerations
There are additional reasons beyond time accuracy improvements to
standardize NTP interleaved modes of operation. As noted earlier,
its operation with large Protocol Data Units may be reason enough to
standardize the NTP interleaved modes. NTP interleaved modes also
provide additional measurement parameters not available with other
NTP modes. Follow-on IETF TICTOC Working Group discussions are
needed to decide whether to initiate a standardization action to add
interleaved options to the NTP standard.
4.2. Use of IEEE 1588 PTP and 802.1AS Mechanisms in the Underlying
Network Service (e.g., Network Interface Controller [NIC])
The purpose of investigating this mechanism is to determine if using
special capabilities in the underlying network service can improve
the timestamp estimates when NTP packets are put on the network,
transferred across networks, or taken from the network. It is
apparent there are many new network integrated circuit devices as
well as general purpose processors that perform IEEE 1588 PTP
hardware time stamping to support emerging interactive multimedia
services. Such integrated circuits are identifying IEEE 1588 PTP;
however, they appear to be programmable, and it is possible that key
NTP operations or encryption algorithms could be supported as well.
This is an area where research and experimentation is needed.
Identifying the security threats and network errors that can be
handled is an important part of this research and experimentation.
4.2.1. Standardization Considerations
If the investigation of these mechanisms generates promising
results, this may initiate a standardization proposal for additions
to the NTPv4 standard to make use of these capabilities.
Alternatively, a modification to the NTPv4 standard may be proposed,
which would enable hardware assists to be incorporated into future
NICs.
4.3. Use of IEEE 1588 PTP to Synchronize Computer Clocks
The purpose of investigating this mechanism is to determine the
viability of using PTP to synchronize computing elements, which
require very accurate synchronization. This mechanism considers
bringing the PTP synchronization all the way to the computer clock
through a standardized clock discipline algorithm. Computing
elements synchronized by PTP are candidates to be time servers (by
the use of NTP) for computing elements not synchronized by PTP.
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 7]
Internet-Draft Improving Computer Clock Accuracy October 2011
Based on their respective strengths, the natural way to merge NTP
and PTP would be to use PTP as the means of obtaining extremely
accurate time information from across the network and to let the NTP
algorithms use that time to keep local clocks synchronized.
Tradeoffs between performance and security or network error handling
capabilities are needed to fit each deployment environment
considered.
4.3.1. Standardization Considerations
If the investigation of this mechanism generates promising results,
it may initiate a standardization proposal to specify a PTP profile
for use by NTP. It may be possible to replace the current NTP clock
coordination services without affecting the NTP time management
services or the clock access mechanisms used by each operating
system. A variety of studies will be needed if this approach is to
be pursued, including a study to determine if there are any issues
for secondary time servers to run both NTP and PTP. If such issues
are identified, standards activities may be needed in the IETF or in
IEEE 1588. A study would be needed to identify the security threats
and/or network errors that can be handled.
5. Initial Experimentation
5.1. Naval Surface Warfare Center, Dahlgren Division (NSWCDD),
Experimentation
Some preliminary experiments tested the new interleaved mode
available in NTP v4.2.6. This mode mimics the operation of PTP
defined by IEEE 1588 where an additional follow-up message is sent
so that a more accurate transmission time can be used. In this
experiment, seven workstations running Red Hat Enterprise Linux 5
were used. These workstations are 3 years old and make use of two
dual core processors. Since the GPS-based (i.e., stratum 1) time
server does not currently have NTP v4.2.6 available, which supports
the interleaved modes, one of the seven workstations was
synchronized to the stratum 1 time server, which then served as the
stratum 2 time server to the other six stratum 3 workstations. The
stratum 2 server and four of the six other workstations were
upgraded to use NTP v4.2.6, while the remaining two workstations
were left running NTP v4.2.2 that was included with Red Hat
Enterprise Linux 5.
Interleaved mode was achieved by using the "xleave" option when
either the broadcast mode or peer mode was used under NTP. The
stratum 2 server was configured as a broadcast server, making use of
the standard multicast address and using the xleave option. Two of
the workstations running NTP v4.2.6 were configured as multicast
clients so that the Interleaved Broadcast mode was utilized. The
other two NTP v4.2.6 workstations were configured to synchronize to
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 8]
Internet-Draft Improving Computer Clock Accuracy October 2011
the stratum 2 server using standard Client/Server (unicast) mode.
The two workstations running NTP v4.2.2 were configured to be
broadcast clients; however, they did not use interleaved mode since
NTP v4.2.2 does not include interleaved support. All NTP polling
intervals were configured to 16 seconds.
Offset measurements were obtained between the six clients and the
stratum 2 server using the "ntpdate" command with the "-q" option.
Measurements were taken every minute over approximately 4 days.
These workstations were not running any other major tasks, and NTP
ran over a network with no discernable network load. All of the
workstations were connected through the same Virtual LAN on the same
network switch (i.e., no routers involved). All of the network
connections were 100 Mbit/sec Ethernet.
Some experiment results were obtained where the average and standard
deviations of the absolute value of clock offset were measured. The
worst-behaved NTP Interleaved Broadcast client was able to stay
synchronized with an average clock offset of 9 microseconds with a
standard deviation of 8 microseconds. The worst-behaved computer
that synchronized using Client/Server mode was able to maintain an
average clock offset of 11 microseconds with a standard deviation of
10 microseconds. The worst-behaved Broadcast (without NTP
interleaved) client stayed synchronized with an average clock offset
of 49 microseconds and with a standard deviation of 58 microseconds.
These results illustrate that NTP Interleaved Broadcast does provide
results that are better than having every client poll the server via
unicast. However, the result is not significantly better (e.g., not
an order of magnitude better). Preliminary experiments with
hardware-based PTP have been performed in the past where the average
offsets between PTP NICs and the PTP Grandmaster clock are in the
hundreds of nanoseconds with standard deviations in the tens of
nanoseconds.
5.2. Future Metrics and Benchmarks Standard
One thing that would help to perform computer time synchronization
experiments is a set of time-synchronization performance metrics; no
standard or even a paper was found on this topic. Developing a
standard to define time synchronization performance metrics would be
beneficial by allowing different experimental efforts to be
performed in a way that the results are comparable.
An Internet-Draft addressing Benchmark Methodology for network time
synchronization devices may be a good path to provide the needed
metrics and guidance on experiments to be run. This benchmark
methodology would be similar to those that the IETF Benchmarking
Methodology Working Group has standardized for other areas. This
document would include methodology specific to benchmarking the
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 9]
Internet-Draft Improving Computer Clock Accuracy October 2011
performance of devices used for synchronizing time over a network.
This document could define a model for time offset measurement,
describe test setups, metrics to be collected, and background test
environments. Specific benchmarks may vary between testing a single
device and an entire system under test. The methodology could
identify requirements for identifying test accuracy and for ensuring
that measurements are independent of the devices being measured
(e.g., that the measurement techniques are not profoundly influenced
by the delay of the network upon which the measurement is made).
6. Analysis of Results
6.1. Analysis of Initial NSWCDD Experimentation
In 2008, it was reported [4] that the synchronization of computer
clocks using NTPv4 over a LAN can approach values on the order of
~145us (mean plus 3 sigma). This has been demonstrated in the
laboratory and was achieved across a single stratum (e.g., stratum 1
to stratum 2). Recently, using newer hardware and a newer NTP
version, time synchronization values were measured on the order of
~40us (mean plus 3 sigma). The variation in the time synchronization
comprises the majority of the 40us value. The results need to be
analyzed in detail, but in a little over two years, the time
synchronization of computer clocks over a LAN has improved; most
likely due to hardware improvements and minor software enhancements.
If this 40us synchronization can be maintained from stratum to
stratum for all subsequent tiers in a well-engineered network with 3
to 5 stratums, a maximum theoretical time synchronization offset on
the order of 120-200us could be achieved. A 50 percent improvement
in the variability of clock synchronization from stratum to stratum
would reduce this number to less than 125us. This does not imply
that stratum-to-stratum accuracy should not be improved. On the
contrary, by working on the accuracy and variability together, all
users of time synchronization will benefit. This needs to be
accomplished without overloading the computer or the network.
A 50 percent improvement appears to be a reasonable goal; however,
if the stratum-to-stratum synchronization variability could be
improved by an order of magnitude, it is reasonable to anticipate
maximum theoretical time synchronization offsets of 50us or less in
a well-behaved LAN and potentially in the hundreds of microseconds
for a Wide Area Network.
6.2. Analysis of Published Results
In Dr. Mills' second edition of Computer Network Time
Synchronization [1, pages 323-327], results are reported for two
sample networks: a backroom LAN (a 100Mb/s switched Ethernet with
very little traffic) and the campus LAN (a 100Mb/s switched Ethernet
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 10]
Internet-Draft Improving Computer Clock Accuracy October 2011
with two very busy servers and NTP traffic volume of well over 1000
packets per second). For the backroom LAN, the measured offset for
two identical machines from the GPS server was ~20us (operating in
Client/Server mode) while the offset between machines operating in
Interleaved Symmetric mode was less than 5us with a round-trip delay
of roughly 100us. These machines were also operating in Interleaved
Broadcast mode to support a third machine on the network with time
synchronization offset averaging 40us or less and a round-trip delay
of roughly 200us. In the case of Interleaved Broadcast, the
experiments we performed showed roughly a 10 microsecond offset
while the backroom LAN in Dr. Mills' book was ~3x greater. This
difference in offset could be caused by differences in the size of
the Protocol Data Units (PDUs) sent (since the backroom LAN used
Autokey for all interleaved operations), the clients' processing
power, and the client and server operating systems.
In the case of the campus LAN, one of dozens of subnets was used for
testing purposes. This subnet contained two busy NTP servers and two
test hosts dedicated to the experiment. The NTP servers were again
synced with each other via Interleaved Symmetric mode while the test
hosts were synced to one of the servers using the Client/Server mode
and to each other using Interleaved Symmetric mode. The round-trip
delay between the NTP servers was measured at roughly 600us and the
offset for each was ~180us but of opposite sign, indicating an
asymmetric path between machines. The test machines were able to
maintain ~20us offset to the NTP server in Client/Server mode and
less that 40us offset between each other with a round-trip delay on
the order of 300us using Interleaved Symmetric mode. The heavy
network traffic appears to have increased the round-trip delay by
~3x over the backroom LAN with roughly an 8x change in offset
measurement. This emphasizes the need for standardized test methods
that are necessary for estimating accurate improvements in network
time synchronization.
7. Future Experimentation
While the results so far are good, further experiments are needed to
draw conclusions. One concern is that the clock offsets are in the
microsecond range. The use of ntpdate may not be a valid way to
accurately measure clock offsets at this level since ntpdate makes
measurements across the network and is susceptible to errors caused
by variations in network delay. Further work is needed to ensure
valid offset measurements. An out-of-band measurement technique,
which is not affected by variations in network delay, needs to be
investigated for use in future experiments.
With the results published by Dr. Mills on the campus LAN, we now
have information on Interleaved Symmetric when put under load both
from a processor and network perspective, and Interleaved Broadcast
when put under a network load. Additional experiments should be
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 11]
Internet-Draft Improving Computer Clock Accuracy October 2011
performed to measure and characterize the resiliency of the NTP
interleaved modes while under network and processor load and then
make comparisons to the other time synchronization methods. The
experiments that have been run up to now had the test workstations
connected to the same network switch. Future experiments should be
conducted to determine how performance is affected when a more
complex network configuration is used.
The experiments conducted so far have provided data concerning
various interleaved modes of operation in a few configurations;
however, there is no thorough, systematic set of results that would
help in deciding whether to run one NTP mode versus another in real
systems. Still needed is guidance on when to use the various NTP
mode options and what the advantages and disadvantages are in using
the various modes. For example, when a time server is available that
is directly connected to a satellite time receiver, what are the
relative tradeoffs in using either Client/Server or Interleaved
Broadcast with other clients? In both of Dr. Mills' experiments,
Interleaved Symmetric mode was used to obtain additional measurement
data, but can this mode be used to gain higher time accuracy among
peers? A set of best-use scenarios would also be very helpful.
8. Security Considerations
Security aspects of the mechanisms described is a major concern and
will need to be considered in more detail.
9. Internet Assigned Numbers Authority (IANA) Considerations
No IANA actions are required as a result of the publication of this
document.
10. Conclusions
Results from our experiments and those described in Dr. Mills' book
[1] indicate that an interleaved capability can provide a modest
improvement to the time accuracy achieved with NTPv4. A stronger
reason to standardize NTP interleaved may be to achieve better
performance when large PDUs are used (e.g., providing server
authentication). Initial results also indicate that interleaved
modes will not provide accuracies in the range that PTP with
hardware assists can; thus, the other two mechanisms described in
this paper should be pursued using experimentation in parallel with
any action to standardize NTP interleaved.
It would be of benefit to the IETF TICTOC Working Group to
standardize the performance metrics and/or benchmark methodology for
use in describing the behavior and testing of devices for clock
synchronization. Such a standard would enable better comparisons
between considered mechanisms. In addition to the same definitions
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 12]
Internet-Draft Improving Computer Clock Accuracy October 2011
of the metrics used, better agreement should be obtained in
experiments being performed by different organizations.
The authors are interested in contributions on the mechanisms
described in this draft as well as on additional mechanisms that may
improve the accuracy of computer clocks synchronized over a network.
The authors request that other experimental results on mechanisms
that can improve NTPv4 accuracy be shared. It is hoped that
discussions on this topic in the IETF TICTOC Working Group will lead
to standardization actions to enable better accuracy to those
utilizing a future NTP specification.
11. Informative References
[1] Mills, David, L., 2011, "Network Time Synchronization-the
Network Time Protocol on Earth and in Space, Second Edition",
CRC Press
[2] Mills, David, 8 June 2011, forwarded (by Karen O'Donoghue)
email on the TICTOC (and NTP)Discussion Archive,
http://www.ietf.org/mail-
archive/web/tictoc/current/msg00945.html
[3] Mills, David, 10 June 2011, email on the TICTOC (and
NTP)Discussion Archive, http://www.ietf.org/mail-
archive/web/tictoc/current/msg00952.html
[4] O'Donoghue, K., Glass, M., and Plunkett, T. (2008). "Next
Steps In Network Time Synchronization for Navy Shipboard
Applications" [Electronic Version]. 40th Annual Precise Time
and Time Interval (PTTI) Meeting, pp. 187-195.
12. Acknowledgments
The authors wish to thank Karen O'Donoghue (Internet Society) for
her valuable comments.
Approved for public release. Distribution is unlimited.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
David Marlow
NSWCDD
17214 Avenue B Suite 126
Dahlgren, VA 22448-5147
USA
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 13]
Internet-Draft Improving Computer Clock Accuracy October 2011
Email: david.marlow@navy.mil
Sterling Knickerbocker, PhD
NSWCDD
18372 Frontage Road, Suite 318
Dahlgren, VA 22448
USA
Email: sterling.knickerbocker@navy.mil
Timothy Plunkett
NSWCDD
17214 Avenue B Suite 126
Dahlgren, VA 22448-5147
USA
Email: timothy.plunkett@navy.mil
Marlow/Knickerbocker/Plunkett Expires April 30, 2012 [Page 14]
