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]