Re: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6

[Brian Utterback <[e-mail]>]

Richard Gayraud (rgayraud) wrote:

> Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst)
> --------------------------------------------------------------
> 
> When writing the first version of this draft, one of our goals 
> was to allow better control of the tradeoff between NTP clock 
> precision and traffic generated over a LAN. IPv6 has a large 
> address space, and an IPv6 subnet can contain a huge number of 
> hosts. Thus, it may be suitable to reduce the amount of traffic 
> generated by NTP clients. On the other hand, some deployments 
> may require fast and precise clock synchronization. Hence the 
> Maxpoll, Minpoll, Burst and IBurst parameters. Again, these are 
> not mandatory and will rarely be used.
> 
> - some people says you have to be an expert to set these 
>   parameters and these should not be opened.
> 
> => I do not understand why theworkstation users (controlling 
>    their individual ntpd.conf file) would be more skilled to 
>    set these parameters than network administrators (controlling
>    the DHCP server)? 

The ntp.conf file is overly flexible for most users and
gives more than enough rope to hang yourself mightily if youstart to 
stray from the usual settings.

We strongly discourage the use of maxpoll and minpoll by naive
users. Likewise you should never configure burst unless you
know what you are doing. On the other hand, you should probably
always configure iburst and I suspect that it will someday morph
into a noiburst option with iburst being the default.

> 
> If some parameter is questionable in a DHCP option, I think it 
> is also questionable as an ntpd.conf option. Isn't it?

Yep. There are a boat load of questionable parameters in the ntp.conf
file.

> 
> I do remember examples of customers requesting that their NTP 
> clients quickly sync (and acquire time) on startup. If the network 
> administrator wants NTP this kind of behavior, he will set the 
> Burst flag to reach fast NTP convergence. Anything I missed here?

That would be iburst, not burst.

> 
> 
> Issue #4: "maxpoll is useless"
> ------------------------------
> 
> Even people who like additional parameters, agree to say that 
> maxpoll is useless (Brian, Dave). Could you explain why this is 
> useless?.

Two reasons. First, the general reason that you should not be
specifying minpoll and maxpoll, is that it is unnecessary and
detrimental to the time keeping. Any reasonable client will
use the optimum polling period. Shorter poll intervals do not
necessarily give you more accuracy, nor longer ones less. There
is an optimum poll period that the client calculates and given
the likely round trip times in most DHCP configurations, that
optimum will already be in between the current min and max polls.

While having a minpoll makes a bit of sense, (i.e. do not poll
more often then *this*) maxpoll doesn't make sense at all. If
you lower it, then you are saying "do not poll less often than
*this*, even though you would like to." This is essentially
saying to use more resources than you would like to, so that
you get lower quality time synch. Making the maxpoll higher
than the default likewise doesn't make much sense, since it
is unlikely that the clients will get higher than the default
anyway. As long as the clients are in between the min and max,
it is best to let them do their own thing.

> 
> 
> Issue #5: "delay is useless"
> ----------------------------
> 
> The delay field serves as a trigger to enable/disable the 
> client volley in multicast mode. Again, I don't understand why 
> this is useless. The goal of this parameter is not to have the 
> DHCP server to measure the network delay. It is simply to allow 
> the network administrator to manually configure a constant delay 
> to compensate for having no volley (please refer to  
> http://www.cis.udel.edu/~mills/ntp/html/confopt.html where the
> 'broadcastdelay' option has a similar purpose). I believe the 
> default 4ms might not be suitable for all network topologies.


Well, the problem is that the correct delay could be different
for different clients, and is difficult to determine by hand.
I am conflicted. While I agree it would be nice to be able
to tell the clients not to volley, you can't easily get the
right value, meaning you should probably allow the client to
volley.

-- 
blu

"You've added a new disk. Do you want to replace your current
drive, protect your data from a drive failure or expand your
storage capacity?" - Disk management as it should be.
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg