Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Miroslav Lichvar <mlichvar@redhat.com> Mon, 02 September 2019 12:43 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 1AA46120119 for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 05:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bLrhXI3m2NCu for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 05:43:09 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FC8120110 for <ntp@ietf.org>; Mon, 2 Sep 2019 05:43:09 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8283A308FBFC for <ntp@ietf.org>; Mon, 2 Sep 2019 12:43:08 +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 0853A1001947 for <ntp@ietf.org>; Mon, 2 Sep 2019 12:43:07 +0000 (UTC)
Date: Mon, 2 Sep 2019 14:43:03 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20190902124303.GF15024@localhost>
References: <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de> <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org> <20190828111458.GJ24761@localhost> <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org> <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de> <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se> <252618a3-d2fb-d5b1-baa4-72b16ef0f845@nwtime.org> <e5b16adb-eddb-fadd-4940-9d97685a36e4@rubidium.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e5b16adb-eddb-fadd-4940-9d97685a36e4@rubidium.se>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Mon, 02 Sep 2019 12:43:08 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/trT4IU75PKUv_Xefc_ilm8MQ2k8>
Subject: Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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: Mon, 02 Sep 2019 12:43:12 -0000

On Mon, Sep 02, 2019 at 01:32:11PM +0200, Magnus Danielson wrote:
> >> If I only had time to describe all the things I would do to enhance NTP,
> >> it has a number of built-in assumptions which is not useful or correct.
> > How about a list of at least some of the built-in assumptions that you
> > think are not useful or correct?
> 
> From the top of my head a few:
>
> The Allan interception point is based on incorrect theory of the noise.
> 
> Rather than drive things to highest stratum, going to closes
> intermediate node and then let that do aggregated questioning to
> increase the width of single stream rather than separate allows better
> noise surpression of asymmetric delays.
> 
> The frequency/phase lock-in methods is dated and has failures in
> error-handling, especially with how calibration works and can become
> incorrect. There is simpler methods with much better error-handling.

If I understand it correctly, those are not a problem of the NTPv4
format or protocol, but rather RFC 5905. I'm not sure if a new NTP
version is needed to fix that. A draft could specify that NTPv4
implementations are free to use different algorithms and models of the
clock than what is specified in RFC 5905. That would just describe the
current state. I think it was an idea for the NTPv5 specifications
that it would have no algorithms, only the message format and
protocol.

What I wanted to collect were issues that may require changes in the
format itself. Like insufficient resolution of the root delay and
dispersion, missing timescale identification, minimum length of
extension fields, etc.

-- 
Miroslav Lichvar