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

Miroslav Lichvar <mlichvar@redhat.com> Thu, 27 May 2021 07:36 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 2C06B3A0E4B for <ntp@ietfa.amsl.com>; Thu, 27 May 2021 00:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Level:
X-Spam-Status: No, score=-3.496 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 2pIvyc9FvMW3 for <ntp@ietfa.amsl.com>; Thu, 27 May 2021 00:36:54 -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 50F213A10FE for <ntp@ietf.org>; Thu, 27 May 2021 00:36:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622101012; 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=YMTqKKg5HCAcULw/Xw8tR6ShN6zshPL7OVlndxaczwo=; b=hgSUItd49dXGOzp4R6bhaWCO8GPCRVsKcTYj0hW3Cw8xv1b8ftih3qeanLIKBxmsf4pQ+J 5uj4SodPoLD9liUZg+rgDkbkUm9ohf81xoicwWhfg4PD7vj7xvWerN3EfhX3FnU/jM4K0j 6QEH3oJdBM03UDdRRQQH6i4AJ1SR/0Y=
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-276-ywriZdJ-O22f4cUn5rlfoA-1; Thu, 27 May 2021 03:36:50 -0400
X-MC-Unique: ywriZdJ-O22f4cUn5rlfoA-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 17804107ACE6; Thu, 27 May 2021 07:36:49 +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 11A3F1F0CE; Thu, 27 May 2021 07:36:47 +0000 (UTC)
Date: Thu, 27 May 2021 09:36:46 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: Heiko Gerstung <heiko.gerstung@meinberg.de>, "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YK9MDpM5d2P+gnIa@localhost>
References: <5F0AB4A8-30FB-4EE4-904C-BCC2CDFCA552@meinberg.de> <CAJm83bA=uQb05KMtUJN_qk0J65eaa1Av5OBatrN4mAk3dPC11Q@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAJm83bA=uQb05KMtUJN_qk0J65eaa1Av5OBatrN4mAk3dPC11Q@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
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/UI9JREMMOezpxlYVAwa4R_6z3z0>
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: Thu, 27 May 2021 07:36:56 -0000

On Wed, May 26, 2021 at 12:11:31PM -0400, Daniel Franke wrote:
> If a client is going to be exchanging delay messages just as often as
> it receives sync messages, then I don't understand the point of using
> the sync messages at all. The DELAY_RESP message contains a receive
> timestamp, so it contains all the information a client needs for time
> synchronization.

The delay response doesn't have a transmit timestamp and it's not an
event message, i.e. it is not timestamped on the receiving side. In
PTP there are event messages and general messages, exchanged on two
different UDP ports.

I think the reason for that is that PTP originated in time when
hardware timestamping was difficult and expensive, so the protocol
minimizes their rate and tries to distribute them evenly over time.
Even on modern hardware, transmit timestamps can be typically captured
only one at a time, so they need to be limited to the sync messages.

> I thought the whole point of having both
> message types was that delay measurements didn't need to be sent
> nearly this often because delays are expected to be stable over time,
> and that sync messages can be broadcast.

That is a reason but not the only one, I think.

The calculation of the offset in the PTP specification uses only two
timestamps assuming the delay is constant. Implementations can use an
out-of-spec approach similar to NTP using four timestamps
corresponding to the latest sync message and latest delay request, but
the T3-T2 interval is not as tight as in the NTP client/server mode.
It's more like the NTP symmetric mode, but with a random interval.

-- 
Miroslav Lichvar