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

[Dave Hart <[e-mail]>]

On Wed, 27 Dec 2023 at 13:04, David Venhoek <[e-mail]> wrote:

> >From my perspective, the fact that apparently (at least as harlan
> seems to claim in his original email) the algorithm specified in
> RFC5905 is fragile would be all the more reason to not specify it as
> "the standard". If this is really the case, we should rather be
> looking harder for solutions that are more resilient and not so
> sensitive to
>

Fortunately this is not the case.  Harlan did not claim in his original
email of this thread that NTPv4 is fragile.  Your apparent misunderstanding
may come from his mention that Dr. Mills showed that _violating_ the
specification can easily break a synchronization.  That is quite the
opposite of claiming RFC5905's algorithms are fragile.

[...]
>
> Looking at the current moment, we are now in a situation where there
> are 3 algorithms operating in the space, with the one in the
> "reference" implementation, the one from chrony and the one from
> ntpd-rs. I have personally not seen any indication of problems caused
> by this, rather the oposite. From measurements it looks very likely
> that both chrony and ntpd-rs are capable of, with similar poll
> intervals, synchronizing to about an order of magnitude larger
> precision.
>

Your use of precision is confusing in this context.  In NTP parlance,
precision is the minimum change in the system clock, in ancient systems,
the clock tick, in modern systems, the time to read the system clock.  I
look forward to you documenting your claim of an order of magnitude better
performance from Chrony and ntpd-rs compared to the reference
implementation.  I would love to improve the performance of NTP across a
wide variety of situations and then promote standardizing those
improvements.

> [...]
>
> Also, the fact that David L Mills apparantly had the tendency to just
> change the algorithm without changes to the standard at least on the
> surface feels also just wrong to me. That gives a lot of vibes of
> "innovation, but only by us" from the "reference" implementation
> people, which is I think highly harmful. I sincerely hope that that is
> just a wrong impression from my side.
>

It sounds like you're not familiar with the history of NTP.  In the
beginning, there were fuzzball routers and Arpanet...  I don't think it
would be productive for me to spend a lot of time repeating what can be
easily discovered with a little effort.  I refer you to Dr. Mills' papers
at https://www.eecis.udel.edu/~mills/, the NTP RFCs, and his second edition
NTP book "Computer Network Time Synchronization: The Network Time Protocol
on Earth and in Space, Second Edition 2nd Edition" ISBN 978-1439814635.

Suffice it to say Mills invented NTP and nurtured it personally for 30
years.  He maintained various iterations of the reference implementations
over that timeframe, eventually with the assistance of Harlan Stenn.  Dr.
Mills' health no longer allows him to participate substantially.  During
that time, he naturally evolved the design _before_ codifying it in
standards, and I know of no other reasonable approach.  He never wavered
from the position that NTP was not simply a wire protocol, but a suite of
algorithms carefully engineered, simulated, and tested over time to have
predictable and consistently beneficial behavior in synchronizing networks
of devices within the limits of their oscillators, reference clocks,
communications channels, hardware, and underlying software.

If you want to use the on-wire protocol without the algorithms, please see
the SNTP RFCs.

Cheers,
Dave Hart



> On Wed, Dec 27, 2023 at 8:22 AM Harlan Stenn <[e-mail]> wrote:
> >
> > 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!
> >
> > _______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>


-- 
Cheers,
Dave Hart