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

Miroslav Lichvar <mlichvar@redhat.com> Wed, 02 June 2021 13:21 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA4A3A42CE for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 06:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdDjk8vKLFpO for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 06:21:22 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1163A42CD for <ntp@ietf.org>; Wed, 2 Jun 2021 06:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622640081; 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=obbuTZmRV4MyLYiGz5abzN35Aro0/4+eXyn4m9ol0ok=; b=BsTegu+f4xjwv9DSYeRMEj7tWMM+ftyo5XwkBCU4K8z4qpgbe6ClwEh+GOuAeFNY/UvaQH vSaHcnP1sjNYfk8eivXuv8GA+t8RWpWlyzy0sVTh1paHahwlZAM3t80u5RW6JVwueu3Nhx TBLdr/tveb4ME89Vc4FxQWKEVpzwR1k=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-164-Opxn6JEOOpudpOIOZTrwXg-1; Wed, 02 Jun 2021 09:21:18 -0400
X-MC-Unique: Opxn6JEOOpudpOIOZTrwXg-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 52DFE14EE; Wed, 2 Jun 2021 13:21:17 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A047B60BD9; Wed, 2 Jun 2021 13:21:16 +0000 (UTC)
Date: Wed, 2 Jun 2021 15:21:14 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Heiko Gerstung <heiko.gerstung@meinberg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YLeFyqZp6bZY9nY9@localhost>
References: <7F9B8D13-BC90-4E15-9BDF-81714DF0F0C6@meinberg.de> <YLYCLIEA4/unB6/5@localhost> <1DAA3605-CC04-46DE-8CFC-975BED7D4160@meinberg.de> <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost> <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de> <YLZVS4jwGOnMIk6g@localhost> <24DF9BF2-3072-4152-80D6-9F10D53A59AF@meinberg.de>
MIME-Version: 1.0
In-Reply-To: <24DF9BF2-3072-4152-80D6-9F10D53A59AF@meinberg.de>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/lEGZztirsIQ8u7SPNIeNf-QaBNo>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 13:21:27 -0000

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