Danny and All, The work Tim Plunkett discussed at the last IETF meeting in Prague (draft-marlow-tictoc-computer-clock-accuracy-00.txt) included some results from preliminary experiments with NTP Interleave that is in NTP version 4.2.6. We got some modest improvements over previous experiments which used earlier NTP versions without Interleave. Further experimentation is needed, but we were wondering if others have data that Interleave provides a sufficient increase in performance (or another category) to standardize it?
Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Danny Mayer Sent: Thursday, June 09, 2011 7:53 To: [email protected] Cc: NTP Working Group; [email protected]; David L. Mills Subject: Re: [TICTOC] [ntpwg] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting It's not just interleave capability that needs to be added, but also: 1) mode 6 (public) command control packets which is documented in RFC 1305 but got dropped when obsoleting it; 2) add support for SHA-nnn to replace MD5 for FIPS compliance (see Rich Schmidt's bug report); 3) The work your former group has been doing that was presented at the last IETF meeting in Prague, if it's worth standardizing. I seem to remember a few other issues that we had discussed but I can't think of them right now. Danny On 6/8/2011 11:09 PM, Karen O'Donoghue wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
