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

[Doug Arnold <[e-mail]>]

The accuracy of time at a client or a higher stratum number server has almost nothing to do with the stratum 1 server or servers from which the time is derived.  The accuracy is mostly due to the conditions in the network.  Also different applications require a different approach.  Consider the two different use cases for ntpv5:
User case A:
A Stratum 2 server get it's time from a pool of stratum 1 servers through the public internet and distributes it to clients in computers, servers and routers in a large enterprise network.  The clients need time to about 1 second for log file entries and security time out intervals.  Accuracy at the stratum 2 server and clients is almost completely determined by queuing noise from so many hops that the noise is almost Gaussian.  After removal of outliers the stratum 2 server and clients average clock corrections in a PLL based on a low pass filter.  Because accuracy requirements are loose, clients request updates only every few minutes.

Use case B:
A financial traders network needs microsecond level timing for regulatory requirements and network latency requirements in their enterprise network.  They have their own stratum 1 server inside their firewall, and just a few hops to the clients.  They can achieve their accuracy goals with a high rate of ntp packets, non-linear lucky packet filters, and by turning off encryption to make hardware timestamping easier.

Both of these use cases can use the same ntp packets and the same sequence (client -> server -> client).  But the servo loops are different, the packet rates are different, and the security requirements are different.  The use cases there for could use the same protocol (ntp) but different policies (servo, security settings, packet rate)

Now certainly the security is part of the protocol, but whether you turn it on or not, is policy.  Or whether it is encryption or just an authentication hash could be policy.

The easiest way to specify ntpv5 for both these use cases, and many others, is to make the policies separate from the over the wire protocol, so that there can be different policy subsystems which work with the same protocol.

Use case B is currently solved either with PTP, or with a non-standard variant of ntpv4.  It seems that if people in the field need to violate the ntpv4 standard to get their job done, then maybe ntpv5 should be more flexible.

Doug


________________________________
From: ntp <[e-mail]> on behalf of Danny Mayer <[e-mail]>
Sent: Thursday, April 23, 2020 7:59 AM
To: Kurt Roeckx <[e-mail]>; Harlan Stenn <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Ntp] The bump, or why NTP v5 must specify impulse response


On 4/17/20 10:41 AM, Kurt Roeckx wrote:
> On Fri, Apr 17, 2020 at 03:48:56AM -0700, Harlan Stenn wrote:
>> 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.
> Maybe it's useful to have performance guarantees specified, but
> leave the algorithm how to get there either to the
> implementations, or in a separate document.

This makes no sense. You can't get performance out of a clock. The
things you have to rely on is the reliability of the clocks your NTP
server are referencing, it's stability, error estimates, jitter,
accuracy, and closeness to UTC (if that can be measured). You need to
remember that NTP is a set of loosely coupled networked clocks
interacting with each other. They cannot be easily separated as if you
are running a computer game.

Danny


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