Subject: [ntpwg] question regarding RFC 5907

From: Yaakov Stein <[email-masked]>
Date: Tue, 24 Aug 2010 18:16:50 +0300

NTP experts, 

The NTPv4 MIB RFC starts with the following sentence
   The NTPv4 MIB module is designed to allow Simple Network Management
   Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
   entities.

While I see the monitoring elements, I do not see the management (i.e. configuration) ones.

In particular, RFC 5905's global parameters are all in #defines in the Appendix,
rather than being configurable via the MIB.

For example, I would like to be able to change MINPOLL or MINDISP
from a management entity instead of having to recompile.
I am obviously not the only one who sees an advantage to changing these 
as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.

ooops!!

Can someone explain the design considerations that led to leaving these out of the 5907 MIB ?
Perhaps it was considered better to use netconf ;) 

Y(J)S

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 25 Aug 2010 02:22:17 +0000

Yaakov,

Engineering parameters like MINPOLL and others establish ranges over 
which the algorithms are intended to work reliably. The hardcoded 
defines cannot be changed unless all engineering considerations have 
been explored. In the case (only) of MINPOLL, and as the result of the 
rate management improvements, MINPOLL has been reduced to 8 s from the 
former 16 s. Any attempt to lower this number will result in clock 
feedback loop instability. The preferred way to control the poll 
interval is using ntpq and the configuration commands.

There are zillions of ways to monitor and/or modify ntpd behavior in 
legitimate ways using ntpq and ntpdc, most of which are awkward or 
impossible with presents SNMP. Floating around here somewhere is a SNMP 
agent designed to interface with the NTP monitoring and control protocol 
first implemented in 1981. There are at present no plans to support SNMP 
directly in ntpd.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Sat, 28 Aug 2010 22:19:17 -0400

> rather than being configurable via the MIB.

You need to ask the author of the MIB RFC about that. I'm copying him on
this message.

> while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.

In the reference implementation ntpd uses them in lieu of values entered
on the server configuration lines. In other words if you don't specify
the minpoll and maxpoll values it will use the defined macro values.
That's a pretty standard way of specifying it.

I don't think that the reference implementation of a MIB client includes
a management option. ntpd always uses ntpq and ntpdc to manage the ntp
server. I know of no plans to change that. It doesn't mean that another
implementation might not provide it, merely that the reference
implementation doesn't.

Danny

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 30 Aug 2010 08:25:42 +0200

> You need to ask the author of the MIB RFC about that. I'm copying him on
Yes, thanks for that, Danny. I would say that mentioning management is
wrong at this point, although I would like to see this being added in a
future version of the MIB.

> That's a pretty standard way of specifying it.
Yes, and thats perfectly fine for default values. After all, you need
default values being defined at compile time. But it sounds like Yaakov
wants to configure the values at run time.
> implementation might not provide it, merely that the reference
A lot of my customers and myself would like to see that ntpd allows to
use broadly accepted and implemented standard protocols like SNMP for
monitoring and management instead of using implementation specific
protocols. It is even worse with ntpdc which is not even compatible
between different versions of NTP and therefore is simply not usable for
central configuration management of a diverse population of ntpd's.

Someone else brought up the ntpq argument during the discussions about
the MIB and although I have no problems with ntpq and ntpdc when it
comes to manually look at ntpd's from time to time, they are pretty
clumsy when it comes to automated central monitoring and management.
Therefore I would like to see a future version of the MIB to include
management objects as well and I would want to see this being
implemented in the SNMP daemon of the reference implementation. But it
simply did not make it into RFC 5907, just because I did not have the
ressources to work on that and nobody else brought this up before(!) the
RFC has been published.

Best Regards,
  Heiko

-- 

Heiko Gerstung

*MEINBERG Funkuhren* GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone: +49 (0)5281 9309-25
Fax: +49 (0)5281 9309-30
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Email: [email-masked] <mailto:[email-masked]>
Web: www.meinberg.de <http://www.meinberg.de>

------------------------------------------------------------------------
*MEINBERG - Accurate Time Worldwide*

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 30 Aug 2010 13:33:49 +0300

Dave, 

Thanks for the response.

Yes, I realize that changing values of parameters requires care
and, perhaps more importantly, understanding.

However, I can change a broad range of variables in my present
frequency distribution implementations (based on TDM PWs or 1588),
including relatively sensitive ones such as packet rates,
filter bandwidths, thresholds for constant delay change detection, 
various Kalman filter parameters, etc.

This feature is extremely useful as the same algorithm may be called
upon to run in many different scenarios, e.g., a large number of 
network elements that are typically not very highly loaded (i.e. Gaussian PDV),
a small number of more heavily loaded ones (i.e., with delta function at minimum delay),
a single switch with other high-rate synchronous flows, etc.

The standard way such configuration is handled is via a management station
over the network with SNMP. Yes, I realize that NTP was born in another
type of environment, where other modes of configuration 
(or even simply recompilation) are prevalent; 
but it is being used in service provider networks, and this kind of management is needed.

I would appreciate hearing what modifications of NTP behavior
are easy using ntpq but awkward or impossible using SNMP.

Y(J)S

-----Original Message-----
From: David L. Mills [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 05:22
To: Yaakov Stein
Cc: NTP Working Group
Subject: Re: [ntpwg] question regarding RFC 5907

Yaakov,

Dave

---

From: Danny Mayer <[email-masked]>
Date: Mon, 30 Aug 2010 08:05:39 -0400

Right now it's impossible using SNMP since the interface does not exist
in the reference implementation. To add that to ntpd would require
building a whole new interface capability which would have to be
architectured, designed and implemented. A second possibility is to have
SNMP interface with ntpq to perform the actual changes which have the
same if less onerous problems as ntpd. Heiko has build an SNMP interface
to ntpq for reading the data but not for updating ntpd. Another option
is to build an SNMP application which uses the NTP mode 6 packets to do
it directly. That could be done but has the same hurdles as above.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 30 Aug 2010 18:54:24 +0000

Yaakov and others,

There may be some misunderstanding here. There are literally dozens of 
parameter that can be changed using ntpq, all of them carefully chosen 
to avoid instability. The poll interval can be limited to any range 
within 8s and 36 h. Associations mobilized from a configuration file or 
upon arrival of a packet can also be mobilized or changed with ntpq. 
However, certain things like the damping factor of the impulse response 
cannot be changed. The next anticipated toy is to allow such changes 
using a fuzzy controller that clamps overshoot.

The NTP control/monitoring protocol began life in the early 1980s and 
first appeared in RFC 1305 in 1992. The design was very much in the 
spirit of protocols such as ftp, smtp, http and other early Internet 
adventures. A user can interact using telnet or a purpose-designed 
management protocol like ntpq. The NTP model departs from the telnet 
model, since it uses UDP, but the principle is the same - send ASCII 
strings and expect ASCII strings in response. In the design named 
variables can be read and written and certain canned billboards can be 
produced.

There is in principle no reason why all this could be rebuilt using snmp 
MIB communicating in ASN.1 syntax. The real problem, however, is the 
limited number of data types in SNMP. Just as the units in NASA space 
missions are km, kg and s, the units in ntpq are in ms and fraction, PPM 
and fraction and precision, resolution and interval units in powers of 
two in seconds. It is intended that the ntpq data be parsable using 
convenient Unix tools and many have actually done that.

The design of the MIB could be improved by considering a top-down 
approach and what is intended in the monitoring function. For both 
servers and clients, the fundamental bottom line is how well the 
contraption is working, which needs only the NTP datestamp at the last 
update and the offset, root delay, root dispersion and system jitters at 
that date. If a client, the data for each server surviving the cluster 
algorithm might be useful. There is no real need for the unselectables 
or falsetickers. From these, the estimated clock offset, estimated error 
relative to that offset (jitter) and maximum error due all causes (root 
dispersion plus one-half root delay) can be determined. At this level, 
stratum, mode and poll interval are not that important. Casual watcher 
really don't need anything else, unless poking around for broken things.

The MIB has a number of packet counters, which is a good thing, but 
maybe overdone. Servers and clients don't really care about packet mode 
and stratum, only the number of packets gazinna, gazoutta gadroppa 
packets. The reference implementation is intricately concerned about the 
gadroppas as a debugging tool, but the number different counters has 
varied over the years. For casual monitoring, only the authentication 
failure, access denied and rate exceeded (KoD) counters are really 
significant.

The MIB  calls out a number of notifications (called traps in ntpd), 
some of which are quite specific. These tend to change from time to 
time, currently defined in the ntpq documentation and the status words 
and event messages page. Rather than cast these in concrete, the trap 
includes a short text alert message along with a code that directs the 
user to the relevant documentation. The intent of the traps is for the 
monitoring station to watch for the big ones and text to the sysadmin 
via  cellphone.

 From a management point of view, the most important indicators are the 
system status word and the status word for each association as revealed 
in the documentation. The association status word reveals the selection 
status (tally code) and last event message code. Much more useful 
operational detail is available in the flash code for each association. 
Again, these codes direct the user to the relevant documentation. From 
almost thirty years of watching NTP rascals, that's all I need for the 
gauges on the monitor screens.

The MIB refers to a heartbeat function, presumably so some manager can 
make sure the service is still alive and functioning. The reference 
implementation includes a set of statistics called sysstats, which are 
updated at hourly intervals. These are intended for operators such as 
NIST and USNO to monitor the packet flux. While not done at present, 
these or alternatives could be sent as traps.

Dave