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

From: Watson Ladd <[email-masked]>
Date: Sun, 15 Nov 2020 23:35:02 -0800

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

---

From: Daniel Franke <[email-masked]>
Date: Mon, 16 Nov 2020 18:17:27 -0500

> networks, the Bloom fIlter will have a false positive.

My earlier design sketch
https://gist.github.com/dfoxfranke/4ca0443b6ff6e0473578cf3827b9ea7f
goes into more detail on the Bloom filter idea. It's based on random
self-assigned identifiers, not on IP addresses.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 26 Nov 2020 12:04:06 +0100

> early draft, and I hope my suggestions are read as contributions not

Thanks for the comments.

> one? Not sure what works for the 32 bit one?

I have no good suggestions here. Maybe "short", "medium", and "long"?

> were supposed to solve, but we might be stuck with leap smearing due

It's not clear to me how timestamps in a MJD-based format would help.

The "Monotonic Timestamp" from the draft is not supposed to have an
epoch and it actually doesn't need to be from a monotonic clock. I can
see how this could be confusing. There should be a better name for
this timestamp and concept.

> propagate this difference work instead?

How would an extension be better? Are you worried we will need more
than 16 timescales, which wouldn't fit in the 4-bit field?

There must be some demand for UT1 as NIST runs UT1-based NTP servers.
That's the main reason why I put it there. I guess it's very
convenient for some astronomers.

> selection, and so some degree of agreement across implementations is

I'd like to have a section on the metrics. Explain how they are
supposed to work and where they can be used, but unlike RFC5905 not
enforce any particular model of the clock.

> distributed seems pretty awkward. Maybe I'm imagining the application

The goal is to give clients two separate signals so they can better
measure their phase and frequency offsets. With a single signal there
is always a compromise between phase and frequency accuracy, which
leads to various issues.

As a simple example, consider the kernel PLL used by ntpd. The
monotonic timestamp could be set to the current system time adjusted
by the current PLL offset. The "monotonic" time provided by the server
would be very close to UTC (or another negotiated timescale), but its
frequency would be more stable.

I'm planning to make a demonstration of how this can improve stability
in a long chain of servers.

-- 
Miroslav Lichvar

---

From: Doug Arnold <[email-masked]>
Date: Mon, 30 Nov 2020 21:17:57 +0000

Regarding the datatypes:  What do you think of time16, time32, and timestamp64.  It makes a distinction between the first and the format used for timestamps.

Regarding the correction field: I think that the easiest route to adoption by manufacturers of switches and routers is to make it work just like PTP.  That is one field that corresponds to the dwell time, difference between the egress and ingress timestamps.  In my scheme the switches and routers do not even have to determine if the message is a request or a response.

Regarding interleaved mode:  I think that this is only important for niche applications that need high precision.  These are generally in smaller networks, where servers saving state for each client is less of an issue.  Note also that several manufacturers make ntp servers with one-step hardware timestamping, where neither follow_up messages not interleaved mode are needed.

Doug

On 11/26/20, 6:04 AM, "ntp on behalf of Miroslav Lichvar" <[email-masked] on behalf of [email-masked]> wrote:

    Thanks for the comments.

    -- 
    Miroslav Lichvar

    _______________________________________________
    ntp mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ntp

---

From: Doug Arnold <[email-masked]>
Date: Mon, 30 Nov 2020 21:31:26 +0000

One more thing on the correction field.  In my scheme only the client offset is corrected.  The delay is still the real round trip delay, rather than some kind of corrected delay.  I was thinking that the real round trip delay is what matters. Is that right?  

Doug

On 11/30/20, 4:18 PM, "ntp on behalf of Doug Arnold" <[email-masked] on behalf of [email-masked]> wrote:

    Doug

        Thanks for the comments.

        -- 
        Miroslav Lichvar

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 30 Nov 2020 22:54:54 +0100

> One more thing on the correction field.  In my scheme only the client offset is corrected.  The delay is still the real round trip delay, rather than some kind of corrected delay.  I was thinking t…

We actually don't care about what the delay is. Delay is a term that
needs to be replaced by something that describers better what we
want to do with it.

Simplified, the delay is used as an upper bound for the maximum
error. We put the offset at half the delay to minimize the maximum
error. Half the delay also happens to be our best estimate for the
time.

If devices between the client and the server indicate that it was
on that device for a certain time, with an indication for an error
on that time, we can reduce the maximum error.

Kurt