Re: [Ntp] An NTPv5 design sketch

[Doug Arnold <[e-mail]>]

There are other key differences between PTP and NTP.  I will list, from the point of view of people familiar with NTP:

  *   Many PTP profiles are layer 2 only, no IP, and sometimes not even Ethernet.
  *   Many users of PTP like to have a strict hierarchy of clocks, one grandmaster, and not have clients or higher stratum clocks ensemble time from multiple servers.  Some people currently using PTP hate this and would rather use a version of NTP tailored for high accuracy.
  *   The assumption of many in the PTP world is that masters have extra processing cycles available, and not slaves (the opposite assumption of NTP)
  *   Many PTP profiles want the network hierarchy to be auto configured, as in using the Best Master Clock Algorithm, which depends on multicast operation.

I think the way to make sure that NTPv5 is useful in ways which PTP isn't is to maintain and perhaps enhance the following properties of NTP:

  *   Layer 3
  *   client server
  *   unicast is primary mode of operation
  *   ensemble of time from multiple servers with voting algorithms for robustness
  *   good cryptographic security
  *   works in WANs, including the public internet

As I mentioned above there are people currently using PTP, who wish that they could use NTP, except NTP doesn't have enough accuracy.  They would have the accuracy if they could run NTP at higher message rates, and substitute different servo filters.  One company has done well with financial data center customers by creating a non standard NTP which does these things.  The proposed modular architecture for NTPv5 would accommodate this.

Doug

________________________________
From: ntp <[e-mail]> on behalf of Miroslav Lichvar <[e-mail]>
Sent: Monday, April 20, 2020 5:43 AM
To: Daniel Franke <[e-mail]>
Cc: NTP WG <[e-mail]>
Subject: Re: [Ntp] An NTPv5 design sketch

On Thu, Apr 16, 2020 at 01:34:03PM -0400, Daniel Franke wrote:
> At any rate, I second Doug Arnold that if a use case is
> already well-served by PTP, then complicating NTPv5 on their behalf is
> not solving anyone's problem.

I think PTP and NTP have different goals, but overlapping use cases.

PTP is basically NTP in broadcast mode, where the protocol is designed
for hardware support to be as easy as possible. NTP may be more
difficult to support in hardware, but if it could be supported, I
think in many cases it would be preferred over PTP.

A use case where the broadcast design of PTP is an issue (and where
NTP would be preferred) is synchronization in large networks where both
multicast and boundary clocks need to be avoided (e.g. to avoid long
chains of servos). The unicast mode of PTP requires a client-specific
state, which is an issue with larger numbers of clients (it's not
unusual for GM clocks to support only 2048 clients or less), and there
is also an issue that it has practically an infinite amplification
factor, so the access needs to be carefully controlled.

--
Miroslav Lichvar

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