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

[Miroslav Lichvar <[e-mail]>]

On Wed, Jun 02, 2021 at 01:00:27PM +0200, Heiko Gerstung wrote:
> Yes, it needs to be fleshed out in more detail in a draft. My point is that you could use a different approach than what we chose in our proposal, but you then have to put this down in writing and submit a draft if you are convinced it has enought benefits when compared to our approach. If you believe it would be a lot shorter, more compact document with less complexity and provides the same or a higher level of protection/efficiency, then please write it down so we can compare it in its entirety.

I'm not interested in writing a new NTS4UPTP draft, at least not at
this time. I'm asking you to reconsider your design or at least
describe how it compares to possible alternatives.

> > If you used only NTP4NTS over PTP, you would still have only one sync
> > protocol. Just the transport is different. That's a couple lines of
> > code.
> 
> A couple lines of code? OK, if you volunteer to modify chrony, I would volunteer to test this with our hardware time stamping engine. Just add a comment where you want to get the hw timestamp from our engine and we will add the necessary function call to actually get it from the hardware. Please ensure that you need to read out at least the sequenceId and MessageType from the PTP header as that is required to find the correct timestamp in the queue. See my comments to Kristof earlier today regarding the requirement to add support for different timestamping hardware, but a first test if this actually works would certainly be interesting, so why not give it a shot if it's only a couple lines of code!

It is 7 lines for a quick hack that hardcodes a PTP prefix for all NTP
messages [1]. Both server and client ports need to be configured to
the PTP port. If your timestamper doesn't use the Linux timestamping
API, it will probably require significant changes. I'll leave that up
to you if you think it's worth the trouble.

I tested it on two NICs: Intel XL710 (40Gb) and Broadcom BCM5720
(1Gb). Both seem to work as expected. It seems their filter only
checks the message type and version, ignoring the length and other
fields. If all HW worked like that and it was acceptable to generate
invalid PTP messages, the messages could be only two octets longer.

> The NTS_TLV is not used for the actual sync / delay / announce messages in our draft, that means you have the authentication_TLV as an overhead compared to standard unicast PTP. This TLV has a size of 42 octets (if I assume a ICV size of 256 bit). The Common PTP message header is 34 octets in size, the size of the Sync and Delay_Req messages is another 10 octets, resulting in 44 octets in total, which proves your point. 

Another thing to consider is that PTP exchanges more messages per
measurement than NTP. In NTP it's 2 messages to get all 4 timestamps.
In PTP it's 4 or 5 to get the timestamps and there are also announce
messages and unicast-specific messages. NTP4NTS over PTP might
actually save some network bandwidth.

[1] https://fedorapeople.org/~mlichvar/chrony/chrony-ntpoverptp.patch

-- 
Miroslav Lichvar