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

[Watson Ladd <[e-mail]>]

On Tue, Apr 21, 2020 at 12:00 PM Doug Arnold
<[e-mail]> wrote:
>
> 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.

On the matter of policy, are we ever going to unify posting formats? *ducks*
>
> 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.

I wouldn't call chrony's algorithm proprietary. We've seen widespread
deployment and the sky hasn't fallen.

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

I definitely agree with this sentiment. There is considerable
administrative overhead involved with running an additional service,
ensuring it is up, fixing it when it is not, etc.  Having unified
implementations and permitting gradual improvement in intermediate
network hardware and configuration is far nicer to administrators.
That said in order to get there we need people who make high precision
timekeeping devices to express their opinion about NTPv5 and what will
or won't work for them.

Certainly for leaves in the timing hierarchy there isn't a problem
with alternative devices.

Sincerely,
Watson Ladd

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.