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

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 09:38:52 +0100

On Mon, Nov 30, 2020 at 09:31:26PM +0000, Doug Arnold wrote:
> 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?  

No, the delay needs to be corrected to not break weighting and
filtering of the measurements.

>     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.

Ok, maybe. What do others think?

>     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.

PTP uses two correction fields and it corrects the delay too. They are
just in separate messages. Sync messages have their own correction and
delay requests have their own correction. In NTP the two measurements
happen in a single exchange, so there need to be two fields in one
message. For the switch it does not matter, it will always update only
one field as the fields are swapped on the server.

>     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.

That's a good point. However, I suspect one-step timestamping would
difficult to implement with authentication.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 09:39:45 +0100

>>> Doug Arnold <[email-masked]> schrieb am 30.11.2020 um 22:17
in
Nachricht <[email-masked]>:
> 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.

I wonder considering the classical NTP timestamp: Could it be "time_64_32",
meaning (64 bits alltogether with a fractional part of 32 bits), if the first
is signed and the latter is unsigned, one might even use time_64s_32u. If you
want to point out the standard timestamp, you could use a "meta define" like
"typedef time_64_32 timestamp64", but I'd really prefer something sohorter like
"ts_64_t" (or without suffix "_t").

> 
> 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.

But do not specify as "like PTP"; instead "copy (and adapt). A comment can
explain that it's modelled after PTP...

> 
> 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.

There is a difference between "needed" and "possible", defining possibly two
ends of the quality scale.

Regards,
ulrich

> 
> Doug
> 
> On 11/26/20, 6:04 AM, "ntp on behalf of Miroslav Lichvar" 
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     On Sun, Nov 15, 2020 at 11:35:02PM -0800, Watson Ladd wrote:
>     > 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.
> 
>     Thanks for the comments.
> 
>     > The data types need some evocative names. Maybe shim for the 16 bit
>     > one? Not sure what works for the 32 bit one?
> 
>     I have no good suggestions here. Maybe "short", "medium", and "long"?
> 
>     > 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.
> 
>     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.
> 
>     > 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?
> 
>     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.
> 
>     > 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.
> 
>     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.
> 
>     > 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.
> 
>     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
> 
>     _______________________________________________
>     ntp mailing list
>     [email-masked] 
>     https://www.ietf.org/mailman/listinfo/ntp 
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp