Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption

[Heiko Gerstung <[e-mail]>]

> Von: ntp <[e-mail]> im Auftrag von <[e-mail]>

> Datum: Dienstag, 1. Juni 2021 um 22:42

> An: Miroslav Lichvar <[e-mail]>

> Cc: Heiko Gerstung <heiko.gerstung=[e-mail]>, "[e-mail]"

> <[e-mail]>

> Betreff: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption

> 

> I mean, you can call anything PTP if you get the 1588 WG to mention it in the ne

> xt standard version, I guess.

Yes, maybe. But from experience I can say that it is not that easy to get something into the next standard ;-)

 

> Honestly, this whole idea has potential.

> A low-effort (and low-complexity, in the spec) version would be one very good re

> sult.

 

It would certainly be an improvement for NTP accuracy. You might be wrong on the “low-effort” and “low-complexity” part, though.

 

> P.S.:

> 

> A well-made Frankensteined construct would potentially be a breakthrough.

> If we could come up with something that combines the following properties, that

> would be a dream come true:

> - Can use hardware timestamping (with existing PTP hardware!)

 

I am still a bit sceptic here, because I know that there is no standardized way how a hardware timestamper operates. Each hardware implementation has its own self-defined interface how to read out the timestamps in userspace and there are a few different packet matcher implementations available which look at different fields / parts of an incoming/outgoing packet to determine whether they have to take a timestamp or not. For IPv4/IPv6 implementations there is most likely the UDP destination port number, but some hw timestamping implementations look at other header fields in addition to that. There are also different identifiers that such a timestamping engine stores in its queue (and expects as “search criteria” when someone is looking for a timestamp for a specific packet), most likely they expect you to ask for a sequenceId, messagetype and source IP address combination, but again there might be other fields (PTP clockId or portId for example). 

 

I believe you cannot use 1-step  (which would most probably remove the requirement to deal with the software interface of a hw timestamper, because the hardware timestamps are written directly into the packet) because the timestamps for transmitted packets would be carried in the PTP part of the packet, which is unprotected by NTS4NTP. You could come up with adding an AUTHENTICATION_TLV and an ICV that is calculated by the hardware timestamper, but there is no such thing on the market (at least not widely available in COTS hardware). That might change once we have a serious security standard for PTP (hint, hint ;-) ..) but it will take most probably years before it hits your standard Intel/Broadcom/Marvell/<InsertYourFavouriteNICvendorHere> network chip of a COTS server/PC. 

 

On a server your hardware timestamper has to be synchronized by an external source, e.g. a GNSS receiver providing at least a PPS. The interface to set the time of the timestamper with very high precision is, you guessed it, not standardized and therefore has to be implemented for each hardware you want to use. 

 

Bottom line is: you have to add support for each hardware timestamping engine implementation your users should be able to use. Of course there are some which are more popular than others, but it is not going to be simple.

 

Please do not forget: PTP runs on TAI, you could use UTC instead in the timestamps and then have to deal with the occasional leapsecond or you run the hw ts engine on TAI to find out the UTC to TAI offset via a leap second file.

 

> - Uses two-way exchange with bounded error of RTT/2

Yes.

 

> - Has guaranteed authenticity/integrity and thus (because of bullet above) guara

> nteed correctness of synch except for a bounded error

Yes.

 

> - Uses two-step scheme on messages going from the time emitter to the time recei

> ver, thus offering zero (!) performance detriment (on the individual exchange) f

> rom crypto

OK.

 

> I am currently busy working on ways of defining and measuring the tradeoffs betw

> een accuracy, security and convenience that you have to make when choosing a tim

> e transfer mechanism.

> It would be very nice to have something that circumvents at least one of the tra

> deoff dimensions.

> Somewhere between making (a subset of) PTP behave like client/server NTP except

> with two-step responses, slapping NTS onto it and making it run on PTP hardware,

> there has to be a way of doing this, doesn't there?

 

Everything is possible (tm). From a vendor perspective I can say that we already offer hardware timestamped NTP for our customers, i.e. the timestamp in the outgoing and incoming NTP packets is modified in-flight at wirespeed, allowing us to claim an accuracy of 10ns in such a packet coming from one of our hardware NTP capable ports. The hardware timestamping is not NTS4NTP capable and changing that would require a lot of effort. I believe that Netnod implemented NTS4NTP in an FPGA and therefore would expect they use hardware timestamping already in their implementation. And I believe that might be a more feasible and logical way of adding accuracy to NTP4NTS. Spoiler alert: Whatever I personally believe does not necessarily have to be true.

 

Regards,

   Heiko

 


-- 

Heiko Gerstung 

Managing Director 

 

MEINBERG® Funkuhren GmbH & Co. KG 

Lange Wand 9 

D-31812 Bad Pyrmont, Germany 

Phone: [phone] 

Fax: [phone] 

 

Amtsgericht Hannover 17HRA 100322 

Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 

 

Email: 

[e-mail]

Web: 

Deutsch https://www.meinberg.de

English https://www.meinbergglobal.com

 

Do not miss our Time Synchronization Blog: 

https://blog.meinbergglobal.com

 

Connect via LinkedIn: 

https://www.linkedin.com/in/heikogerstung