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

Heiko Gerstung <> Wed, 02 June 2021 07:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55E263A3842 for <>; Wed, 2 Jun 2021 00:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TN1ZBabUbxTY for <>; Wed, 2 Jun 2021 00:02:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E19C3A3840 for <>; Wed, 2 Jun 2021 00:02:41 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 664EE71C0C8D; Wed, 2 Jun 2021 09:02:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1622617359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NrfoqGc467M2vsQ//0iwzO2gOHRgXvPbdIL0of3FZJc=; b=S2fD+xR7cMblAn5s5NiWzDQwjS/YFxiX7Av8F2G9lJdmh80FjvdAagLd8ciAPlwuKusKd+ M4mBm9Fu80iVKG93BEAbgk76pTU9k1/2lfPTsg2/g5QhvXUAA4xgscA2Jjx1DgYuzZmJF0 a1ynlDGB1WJZpFLf75o4CetSPY47OmxGHOZdfdM4Y/bxC7egxlnBvlaIPw3WajvFzqPt7d YCm+uE2f+kCW4Z2Zhl0Be4lfnsPXStkvJFkfVScwmQEMRuj9m0wrL5Fy4S9wHetBw+4mhF WSYJhB5WOx+7wHU4rRUf7Hvx+cF+9YnkK/w77mvnlRWO8OFxWOTclkc6pHV/TQ==
Received: from ( []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 2 Jun 2021 09:02:38 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Wed, 2 Jun 2021 09:02:33 +0200
Message-ID: <>
Thread-Topic: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption
References: <YLZVS4jwGOnMIk6g@localhost> <> <YLYCLIEA4/unB6/5@localhost> <> <YLYheZYTSflAdlrF@localhost> <> <YLY3f2/5k1Hjebf7@localhost> <> <>
In-Reply-To: <>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MmU5NjkzNTVjNTJiY2Q2Yw==
From: Heiko Gerstung <>
To: "" <>, Miroslav Lichvar <>
Cc: Heiko Gerstung <>, "" <>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----88FD01C9EF24F90F5BFDBAB2CD6EDBA8"
Archived-At: <>
Subject: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Jun 2021 07:02:49 -0000

> Von: ntp <> im Auftrag von <>

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

> An: Miroslav Lichvar <>

> Cc: Heiko Gerstung <>rg>, ""

> <>

> 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



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

> nteed correctness of synch except for a bounded error



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



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






Heiko Gerstung 

Managing Director 


MEINBERG® Funkuhren GmbH & Co. KG 

Lange Wand 9 

D-31812 Bad Pyrmont, Germany 

Phone: +49 (0)5281 9309-404 

Fax: +49 (0)5281 9309-9404 


Amtsgericht Hannover 17HRA 100322 

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







Do not miss our Time Synchronization Blog:


Connect via LinkedIn: