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
