Re: [Ntp] Antwort: Re: The bump, or why NTP v5 must specify impulse response

[Doug Arnold <[e-mail]>]

I support this proposed top level architecure, and would be happy to help.

Doug

________________________________
From: ntp <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: Friday, April 17, 2020 3:20 AM
To: NTP WG <[e-mail]>
Subject: [Ntp] Antwort: Re: The bump, or why NTP v5 must specify impulse response

Hey all,

I wanted to offer my point of view on the question of modularity for NTPv5 as discussed here.
As many of you may know, the place that I'm coming from is not decades of practical experience in NTP implementation and/or maintenance, but instead years of close academic and theoretic scrutiny concerning guarantees for time synchronization methods.

For me personally, the separation of NTP would ideally not only be made into protocol on the one hand and algorithmic and response behavior on the other hand, but go one step further.
I would prefer separation into three layers, specifically:

1) Network protocol (what kinds of messages can one send, and how does one have to respond to incoming messages); this should be specified on a per-association basis and security should be handled mostly here.
2) Algorithmic offset calculations to the desired "true" time scale (how does one calculate time offset, frequency offset, perhaps offset of higher-order derivatives); this can involve multiple associations; security of the individual associations should be known so it can be taken into account if desired; this is the module that needs to be aware of the use of different time scales such as TAI vs. UTC, the handling of leap seconds etc.; this module should also be aware of how clock steering is handled (see below) and account for it.
3) Clock steering (how is the participant's clock manipulated in order to accomodate the measured offset(s) and make the clock read something close to the "true" time, e.g. hard-setting the counter vs. manipulating the frequency via counter increment vs. manipulating the clock in other ways such as via the oscillator's voltage vs. handling all of that via virtual clocks); this can differ between machines, specifically between OS and hardware and should be treated appropriately.

With this separation, we need well-defined interfaces between 1) and 2) and between 2) and 3).
Not dealing with 3) in a specification and leaving it to implementations should be seen as a real option, keeping in mind that knowledge of 3) can increase accuracy of 2).

Regarding the nomenclature, I would strongly suggest getting consensus first on which of the many ways forward is going to be taken in order to arrive at something that can be called "NTPv5".
Specifically, it should be decided early which of 1), 2) and 3) that document should treat, the options as I see them being 1) only, or 1) and 2), or all three.

What do you all think?


Best regards,
Kristof


-----"ntp" <[e-mail]<mailto:[e-mail]>> schrieb: -----
An: "Harlan Stenn" <[e-mail]<mailto:[e-mail]>>
Von: "Dieter Sibold"
Gesendet von: "ntp"
Datum: 16.04.2020 19:29
Kopie: "Watson Ladd" <[e-mail]<mailto:[e-mail]>>, "NTP WG" <[e-mail]<mailto:[e-mail]>>, "Doug Arnold" <[e-mail]<mailto:[e-mail]>>, "Daniel Franke" <[e-mail]<mailto:[e-mail]>>, "Salz, Rich" <rsalz=[e-mail]<mailto:rsalz=[e-mail]>>
Betreff: Re: [Ntp] The bump, or why NTP v5 must specify impulse response

The problem with this combination is that we currently have no
implementation that conforms to RFC5905 completely.
There are different use cases for potential clients. Some of them are
not well served with the current algorithm other are. A modular approach
would allow both: to apply an algorithm most suitable to the application
and to be compliant with the protocol spec.

Dieter


On 16 Apr 2020, at 11:58, Harlan Stenn wrote:

> On 4/15/2020 6:38 AM, Salz, Rich wrote:
>>>    We had the same discussion at the transition from ntpv3 to ntpv4.
>>>    If you do this, please do not call it NTP.
>>
>> Can you explain why 3->4 could still be called NTP but 4->5 should
>> not?
>
> You didn't quote enough context.
>
> NTP is a combination of two parts:
>
> - the protocol/packet structure
> - algorithmic and response behavior
>
> If you are only specifying the protocol in this new thing then it is
> dangerous/misleading/irresponsible to call this v5 document "NTP".
>
> It is only slightly less dangerous/misleading/irresponsible to call it
> "NTPv5 Protocol", regardless of whether or not there is also an "NTPv5
> Algorithms and Response Behavior".
>
> --
> Harlan Stenn <[e-mail]<mailto:[e-mail]>>
> http://networktimefoundation.org - be a member!

_______________________________________________
ntp mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ntp