It is said that engineers start out knowing nothing about everything, then learn more and more about less and less until knowing everything about nothing. This may indeed characterize the field, more like the back porch, of computer network timekeeping. Boiled to essentials, really the only thing the protocol does is occasionally read the clock in another machine, tell whether the system clock is fast or slow, and nudge the clock oscillator one way or the other, just like the Big Ben timekeepers in London. Of course, the devil is in the details.
All NTP servers and clients in the Internet are expected to conform to the NTP Version 3 (NTPv3) protocol specification published by the Internet Engineering Task Force (IETF) as Request for Comments RFC-1305 [6]. Users are strongly encouraged to upgrade to the NTP Version 4 (NTPv4) protocol, which is the main topic of this topic. NTPv4 consists of a suite of extensions to NTPv3, but a definitive protocol specification is not yet available, even after 4 years of review by the IETF.There is a subset of NTP called the Simple Network Time Protocol Version 4 (SNTPv4) defined in RFC-2030 [7] that is compatible at the protocol level with both NTPv3 and NTPv4 but does not include the mitigation algorithms of the full NTPv4 reference implementation. SNTP server mode is intended for dedicated products that include a GPS receiver or other external synchronization source. SNTP client mode is intended for PCs or low-end workstations that for one reason or another cannot justify running the full NTP implementation and do not have clients of their own.
In previous NTP specifications, a distinction was made between what was in the specification and what was in the reference implementation. The specification specifically defined the architecture, protocol state machine, transition function, and protocol data unit. The specification explicitly did not require the crafted grooming, mitigation, and discipline algorithms that are the heart of this topic and left open the option to use different algorithms in different NTP implementations. However, the many NTP servers and clients in the Internet have become an interconnected forest of tightly coupled oscillators and feedback loops that now behave as one integrated system. To preserve stability in the forest, a full protocol specification now needs to encompass these algorithms.
If some NTP forest grove is not deep and there are no intermediate servers between the primary synchronization source (not necessarily stratum 1) and dependent clients, the particular algorithms might not matter much, even if suboptimal. But, experience has proven that the dynamics of larger NTP woodlands require a systematic approach to algorithm design, most importantly the algorithm that disciplines the system clock time and frequency.
Even small perturbations can excite a string of dependent servers and clients with badly matched discipline parameters something like the crack of a whip.
