Re: [Ntp] Hard NO: Re: WGLC - draft-ietf-ntp-ntpv5-requirements

[Harlan Stenn <[e-mail]>]

On 12/26/2023 3:23 PM, Dave Hart wrote:
> On Thu, 14 Dec 2023 at 17:18, Miroslav Lichvar <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On Thu, Dec 14, 2023 at 03:16:29AM -0800, Harlan Stenn wrote:
>      > The core "mission" of NTP is time synchronization with a (well)
>     defined
>      > response to a "time impulse".  This is the reason why previous NTP
>      > specifications have included the algorithms.  Prof. Mills and
>     some others
>      > have done a LOT of testing to ensure reliable and predictable
>     behavior of
>      > time synchronization, in the "normal" and "time impulse" cases
>     over a very
>      > wide range of circumstances.
> 
>     If the RFC 5905 PLL+FLL is so great, why is nothing using it, not even
>     the "reference" implementation in default configuration?
> 
> 
> Would you mind elaborating how the reference implementation's PLL+FLL 
> feedback loop differs from the NTPv4 spec?  I'm not aware of any 
> intentional deviation, but Dr. Mills wasn't shy about making changes to 
> the implementation that he felt was an improvement before documenting it 
> in another RFC.
> 
>     ntpd in default configuration has a poor response with longer polling
>     intervals. It suffers from oscillations,
> 
> 
> If verified that would seem to me a reason to improve the algorithms, 
> rather than decide it's time for a wild west where every NTP 
> implementation is free to behave in any way, as that would invite 
> pathological results in situations where differing implementations sit 
> on the synchronization path between the reference clock and the ultimate 
> client.

Or better describe the conditions for these problems?

If you are saying that the default config can show oscillations as poll 
intervals increase, all I can say is we haven't seen reports of this.

If we had, we'd be taking steps to fix it.

If you have seen this, perhaps you'd be kind enough to post about how 
one might change the default values to ones more suitable for longer 
poll intervals, or even telling us how to demonstrate the problem.

>     which can be sometimes seen
>     even on monitoring graphs of pool.ntp.org <http://pool.ntp.org>.
> 
> 
> That public pool uses primitive monitoring that does not take into 
> account the delay or jitter between the monitoring station and the 
> server.  Moreover, the requirements for participating are very lenient, 
> allowing clocks that appear to be up to 70ms off of UTC.  That pool is 
> therefore not a good example of a well-engineered and well-maintained 
> synchronization source.  It's fine to get the clock within a few hundred 
> milliseconds, but stricter requirements call for a more precise source 
> and better error budgeting.
> 
>     Nobody seems to care. Maybe
>     it's a bug, but after so many years I think we can conclude that
>     Internet will not break if all NTP implementations don't have the
>     "well defined" response.
> 
> 
> The internet will not break even if all NTP sources were only good to a 
> few seconds.  Those who require tight sync (such as distributed 
> databases) engineer solutions to meet their requirements.

I'm negatively impressed with your conclusion, Miroslav.

"The Internet" probably won't break, because "the internet" doesn't 
exchange time that way, and I would bet that you know this.

A single machine will either have a crafted config file, well-tended or 
not, and static or pool servers.  How well do you think the vast 
majority of these machines are monitored to see if there are problems? 
How badly would they have to screw up to be noticed?

If somebody bothers to look and sees one of the hosts in their static 
config file is bad, they will likely just throw out the bad site and 
replace it.

If they are using the "pool" directive and there are misbehaving servers 
*that otherwise survive the pool monitoring service* then ntpd will 
notice the bad performers and throw them out automatically.

In an enterprise, the odds are quite high that time for the enterprise 
is sync'd from a set of curated machines.  These machines are likely 
getting their time from reliable sources.  They won't be talking to 
poorly-behaving time sources.  This translates to the (internal) 
machines that get their time from the (well-behaved/reliable) internal 
time sources.

So sure, the stuff the NTP Project has put out there is very resilient 
and well-behaved.  There's a good chance it will continue to behave well 
even in an increasingly hostile environment.

But why would any <positive-intentioned> person want to take steps to 
increase the environment's hostility?

As I have said before, the world of time-synchronization is not the 
place to use creative destruction as a method to promote evolution.

> Cheers,
> Dave Hart
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!