[Ntp] Comments on Miroslav's NTP v5 proposal.

[Watson Ladd <[e-mail]>]

Dear all,

The following are unsorted, rough comments. I agree sending them
outright before the meeting is probably suboptimal, but I need
something to do to keep me awake to the meeting. Obviously this is an
early draft, and I hope my suggestions are read as contributions not
criticisms.

The data types need some evocative names. Maybe shim for the 16 bit
one? Not sure what works for the 32 bit one?

The distribution of multiple scales needs some careful thought,
especially leap smearing. Insofar as we need monotonic clocks, I'm
contemplating MJD as a basis for solving the problems leap smearing
were supposed to solve, but we might be stuck with leap smearing due
to the install base.

When smearing it seems the offset will get added to the timestamps set
by the server on the receiving end to reconstruct UTC, which will then
be used to update estimate of true time, and apply whatever smear was
needed. There's no way to avoid this because of the kinds of smear in
use and the need for recipients to understand the smearing of the
source when propagating downward.

I'm not sure UT1 deserves a timescale. It's a comparatively slow
moving offset from UTC, updated every month. Would an extension to
propagate this difference work instead?

If Root Delay and Root Dispersion are propagated something needs to be
said about their proper updating. These values are used in source
selection, and so some degree of agreement across implementations is
desirable.

The monotonic additional timestamps are an intriguing idea but I'd
like to know more about it. In particular the frequency to be
distributed seems pretty awkward. Maybe I'm imagining the application
entirely incorrectly.

I think we need to see the companion document with algorithms
suggested to evaluate some of the potential ideas. What we've seen
from experience is deviation from RFC 5905 can produce better
timekeeping in certain circumstances and doesn't threaten stability.
What we've also discovered is that some changes in common deployment
have led to undesirable impulse response characteristics.

When we introduce something like this auxiliary monotonic timestamp
for a separate frequency distribution that could introduce all sorts
of fun complications and options into the stability calculation. Now
we have two different chains of oscillators, and different algorithms
putting the results together. I have a lot to learn about modeling and
estimating stability here.

Bloom filters of addresses to prevent loops have a problem: if the
synchronization tree traverses two RFC 1918 hosts in different
networks, the Bloom fIlter will have a false positive.

Sincerely,
Watson Ladd

--
Astra mortemque praestare gradatim