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

[Doug Arnold <[e-mail]>]

I agree with Philip.  And I also like the terms protocol and policy.  In my mind the protocol is what has to be the same for implementations to communicate and the policy is what allows a specific node to make use of information received via the protocol.  It is possible to have nodes in the same network using the same protocol, but with different policies.

There could be a generic NTPv5 which works for 90% or more of the users, but a modular architecture which allows for some alternative policies for niche uses.  People are already doing this for NTPv4, its just that its proprietary.

A little reminder of history: an early draft of NTPv4 was based on a modular approach, but was later revised to be a monolithic complete solution.  The monolithic solution works very well for setting clocks in servers and routers for general IT purposes.  However, the collapse of the modular approach drove the telecom timing community out of the NTP working group and into the IEEE 1588, where we ended up defining unicast PTP.  Unicast PTP is incompatible with traditional multicast PTP and in some ways is more like NTP than it is like multicast PTP.  So we created a new find or PTP to fit an application which could have been served by a more flexible NTPv4.

Now the same thing is happening in data centers.  People are installing PTP.  Many of these people tell me they would prefer to install a high precision variant of NTP.  They keep asking me to change PTP to be more like NTP.  It might be better to make NTP a little more flexible than to create more incompatible flavors of PTP.

Doug

________________________________
From: ntp <[e-mail]> on behalf of Philip Prindeville <[e-mail]>
Sent: Tuesday, April 21, 2020 10:56 AM
To: Harlan Stenn <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Ntp] The bump, or why NTP v5 must specify impulse response



> On Apr 17, 2020, at 4:48 AM, Harlan Stenn <[e-mail]> wrote:
>
> [snip]
>
> More to the point, NTPv4 and all of its predecessors specified:
>
> - the packet format
> - the algorithms
> - a set of behavioral limits and specifications
>
> This means others were allowed to write specifications (regulations)
> assuming and/or relying on "NTP" - the packet format, algorithms, and
> behavior.
>
> Removing or separating the algorithmic and behavioral specifications
> from the NTP specification at best cost-shifts that discussion
> elsewhere, and I submit it does this to groups that are likely
> completely unaware that they can no longer rely on behavior that they
> had no idea they previously relied on.
>
> Are you planning to just do a protocol spec and "do the algorithms and
> behavior spec later", or worse yet, let others do that if they think
> it's important?


Not to throw gasoline on the fire, but Postel told me decades ago, “don’t confuse protocol and policy” (he was [ahem] encouraging me to drop 3 paragraphs from the draft of RFC 1048).  It was good advice then and it holds.

Algorithms are, in essence, a “policy” for disciplining a clock.

A compromise might be to define requirements for the protocol parametrically, in terms of drift, jitter, etc. while not defining the algorithms to do that.

This opens the field up to more active research in ways to improve the protocol and the use of clocks without tying anyone’s hands.

The protocol could provide a “reference algorithm” that’s used as a baseline and as an example of a certain performance “envelope” under well-defined circumstances.

Given how long NTPv4 has been around (for both right and wrong reasons), it’s reasonable to expect NTPv5 to live at least half as long.  A lot of technology can potentially emerge during that time and we should have the flexibility to incorporate it as it develops.

Look how far we’ve come since Cesium ovens as reference clocks.

-Philip

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