Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

Danny Mayer <mayer@pdmconsulting.net> Thu, 21 October 2021 15:19 UTC

Return-Path: <mayer@pdmconsulting.net>
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 E68A43A17C2 for <ntp@ietfa.amsl.com>; Thu, 21 Oct 2021 08:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8m01aZxbjgvP for <ntp@ietfa.amsl.com>; Thu, 21 Oct 2021 08:19:27 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (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 10A673A17BA for <ntp@ietf.org>; Thu, 21 Oct 2021 08:19:23 -0700 (PDT)
Received: from [192.168.1.193] (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4HZrjy51TxzMNYV; Thu, 21 Oct 2021 15:19:18 +0000 (UTC)
Message-ID: <78b6fd4d-d58f-e97c-ba67-d9836e022318@pdmconsulting.net>
Date: Thu, 21 Oct 2021 11:19:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0
Content-Language: en-US
To: Hal Murray <halmurray+ietf@sonic.net>, Miroslav Lichvar <mlichvar@redhat.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <20211021092000.13DDD28C157@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <20211021092000.13DDD28C157@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/MgvPoG5iTE9hTOZnAJr6h8BNev8>
Subject: Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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, 21 Oct 2021 15:19:33 -0000

On 10/21/21 5:20 AM, Hal Murray wrote:
>
>> The other important issue is that the TAI-UTC offset is not always known.
> Yes.  I think requiring the client to know the TAI offset is reasonable.  They
> can get it from a leap-seconds type file or from a simple UDP exchange.  It's
> the same as knowing about the next leap second.
>
> We could put it in every packet, but that seems ugly to me.  It makes things
> slightly simpler for the simple/dumb client (1 packet vs 2) at the cost of
> complicating the packet on the wire.
>
> Maybe we should have a separate packet format for simple clients.  How dumb
> are current dumb clients?  Would they be happy with only a single time stamp
> from the server?  Do they even care about fractions of a second?

You need different server for that on a different port. It won't happen. 
You may as well use roughtime in that case.


>
>> NTP is a simple protocol for exchanging timestamps. It shouldn't enforce what
>> kind of timestamps are exchanged.
> We either have to pick one and hence enforce that, or put the type of
> timestamp in the packet.  I think it's cleaner to have only one on the wire.
The only way this is going to work operationally is to use UTC. Sending 
the TAI difference in the packet is sufficient if anyone actually needs TAI.
>
> ------
>
> The root of the problem is smearing.  The current implementation hides it from
> the client software.
>
> Unless we change that, we have to continue with 2 NTP worlds: one set of
> servers that returns smeared time and another set that returns non-smeared
> time.
>
> My suggestion of TAI only on the wire requires that the client implementation
> know about smearing.  The we-want-smearing information moves from hidden in
> the list of servers to an explicit flag in a config file (or whatever).
>
> The NTP stuff for DHCP could get extended to include the smear flag.
Servers have a fixed IP address and don't use DHCP. Clients like your 
laptop don't care about TAI, they only want UTC.
> How many other things could use tweaking?
>
How many other things would you have to change in order to make TAI the 
default.

Danny