Re: [Ntp] Antwort: Re: The bump, or why NTP v5 must specify impulse response
Daniel Franke <dfoxfranke@gmail.com> Fri, 17 April 2020 14:52 UTC
Return-Path: <dfoxfranke@gmail.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 7EE963A0C7E for <ntp@ietfa.amsl.com>; Fri, 17 Apr 2020 07:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 uNdXdj-TjTQd for <ntp@ietfa.amsl.com>; Fri, 17 Apr 2020 07:52:56 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83F83A0C79 for <ntp@ietf.org>; Fri, 17 Apr 2020 07:52:55 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id y17so2540811iow.9 for <ntp@ietf.org>; Fri, 17 Apr 2020 07:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8o1rU8AtP2zgcjTXEL2PH8ipQHXa55doKvkr2Gi1wbY=; b=YJ7XwJEpDMF3nTlFvgMuAGc8oroQoifYJVcLZu0p2/1D/W4zeR1sQ/ByF0zT4PTFXa 8IWeBm6ym9GJH030BUhKMsMeCTNCM29X7jwnsfYUCzUi90KJrIkgHVYsfQAntz3LadZ8 +GRsGLs4Jo2HVgV4DZdT0BNrhGNtOUYmp5In0JLgMCLS+4yaXbLr53Tdp+/riFP6Lia7 GNa1OZg7pwTtlf8gu9g1zSgEofYx/osn7G4uncnj+BWL+DW5TpG818ygbTij3RgZNcnb XjN9klEYaOUaLrNbw5RkRRcsLxG4x9na9lAMIps7BmmjCf6Jpgjm/Cg3zaoWitoCBQEz Y4Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8o1rU8AtP2zgcjTXEL2PH8ipQHXa55doKvkr2Gi1wbY=; b=hD2TeKWXH5+e3uELxfSGwzIXOS6cUi61BlrI5UJPC6MKiCnFYUK8GhcPe8K+Pzuk3Y KpATF13zcsKbQoDlmdvdKJXcelGquR4gl580rKRkSZMHwF2C8TBjFOM3MXH4jmTLvrqK c5ZaUD2ZluusI9RtzTo8KrmBS/waJVLN19hUXAgIdfxc3591/CtCXt9BqQo5HG6zICuJ IMew/zgyN5/pkCK0KHG7w18ANvmIabxxqVkmUmT0VI2RKBlsv2+l9dh4ImqHmIUNDYRv dZCamlkVY/XasjdR/lLLxWSh/Jt3x2WQHDf2BpBts3tYyM1TC84BQqZ5KymW9Dhal+n/ 51YA==
X-Gm-Message-State: AGi0PubRHEfAHBM43uilreyeIH7laTr4dNgFOmnS27wp+sJBuC/Do5od yOH54eElZDStKn3uvd+uA1SC6rWX8Z9VvZ71jKVRrqSy
X-Google-Smtp-Source: APiQypKpE6EsrOtrzn+p4bhyRceuvbyxcNcp/sKnRbLlbSRluWelAQUl9ngww1nG1r6uB5nXyJIUdPSx/mCw2gMzWzY=
X-Received: by 2002:a05:6602:199:: with SMTP id m25mr3422099ioo.13.1587135175065; Fri, 17 Apr 2020 07:52:55 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0c=zzDKP6iBjPJWGF0rkqSaY3AY738ynGwDZO14sdBJ-Bg@mail.gmail.com> <CAJm83bB2A3VUxXX47Y0ubmS9Xne7PRSyV_xHY_D9YvHjqE-vFA@mail.gmail.com> <CACsn0cm3jpKZTUQ=novTgVaFhc1xCJgmUF3oOgdrzQa-HgOCUQ@mail.gmail.com> <CAJm83bAqbMMs2W3SyH+3c17wcC85paY4-_jk2SxczgsxBLyYyA@mail.gmail.com> <CAJm83bAQeR_6U3jgmbWzdus3pu+OO2_KP+M9RtbCFYOfDQy4dw@mail.gmail.com> <DB8PR02MB56111CCA23CDCF97A3C9F3E8CFDD0@DB8PR02MB5611.eurprd02.prod.outlook.com> <F7E5836A-4C7A-4A1A-B769-65EADE2C8F5C@gmail.com> <7d909ae3-a830-1270-6920-fa088a56525e@nwtime.org> <6C9832A9-E18B-4DE2-934F-9E471FC22F7B@akamai.com> <bc7920e2-dc81-ba7f-ec24-7926cda8589d@nwtime.org> <E591F38A-A303-4077-BC4C-A61AB7867F83@gmail.com> <OFF6FE7A91.279129DD-ONC125854D.00379455-C125854D.0038D979@ptb.de>
In-Reply-To: <OFF6FE7A91.279129DD-ONC125854D.00379455-C125854D.0038D979@ptb.de>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Fri, 17 Apr 2020 10:52:43 -0400
Message-ID: <CAJm83bAUqCyy6iKVkGNyHN9hoaEbchuR4bx+kmc=Z-iOrZ3Bgg@mail.gmail.com>
To: kristof.teichel@ptb.de
Cc: NTP WG <ntp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/HDdi0g3aKiVaHoGxWS01PVZozZU>
Subject: Re: [Ntp] Antwort: Re: The bump, or why NTP v5 must specify impulse response
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: Fri, 17 Apr 2020 14:52:58 -0000
On Fri, Apr 17, 2020 at 6:21 AM <kristof.teichel@ptb.de> wrote: > > Hey all, > > I wanted to offer my point of view on the question of modularity for NTPv5 as discussed here. > As many of you may know, the place that I'm coming from is not decades of practical experience in NTP implementation and/or maintenance, but instead years of close academic and theoretic scrutiny concerning guarantees for time synchronization methods. > > For me personally, the separation of NTP would ideally not only be made into protocol on the one hand and algorithmic and response behavior on the other hand, but go one step further. > I would prefer separation into three layers, specifically: > > 1) Network protocol (what kinds of messages can one send, and how does one have to respond to incoming messages); this should be specified on a per-association basis and security should be handled mostly here. > 2) Algorithmic offset calculations to the desired "true" time scale (how does one calculate time offset, frequency offset, perhaps offset of higher-order derivatives); this can involve multiple associations; security of the individual associations should be known so it can be taken into account if desired; this is the module that needs to be aware of the use of different time scales such as TAI vs. UTC, the handling of leap seconds etc.; this module should also be aware of how clock steering is handled (see below) and account for it. > 3) Clock steering (how is the participant's clock manipulated in order to accomodate the measured offset(s) and make the clock read something close to the "true" time, e.g. hard-setting the counter vs. manipulating the frequency via counter increment vs. manipulating the clock in other ways such as via the oscillator's voltage vs. handling all of that via virtual clocks); this can differ between machines, specifically between OS and hardware and should be treated appropriately. > > With this separation, we need well-defined interfaces between 1) and 2) and between 2) and 3). > Not dealing with 3) in a specification and leaving it to implementations should be seen as a real option, keeping in mind that knowledge of 3) can increase accuracy of 2). > > Regarding the nomenclature, I would strongly suggest getting consensus first on which of the many ways forward is going to be taken in order to arrive at something that can be called "NTPv5". > Specifically, it should be decided early which of 1), 2) and 3) that document should treat, the options as I see them being 1) only, or 1) and 2), or all three. > > What do you all think? My ontology is similar, but quite identical, to Kristof's: I. The syntax and semantics of the wire protocol IIa. The algorithm for estimating the offset between your clock and that of your peers IIb. The algorithm for combining estimates collected from multiple peers into one "consensus" estimate IIIa. How to use that estimate to steer the clock used for capturing the timestamps used in the wire protocol IIIb. How to use that estimate to steer the clock that other applications see when they ask for the system time The central question of this thread so far, up until Kristof entered, could be expressed as "How much is (IIIa), and by extension (IIa) and (IIb), really a part of (I)? When we say that the timestamps on the wire confer an estimate of the current time, how particular do we need to be about the properties of that estimate?". NTPv4 and prior don't distinguish at all between (IIIa) and (IIIb), but NTPv5 might have to. My sketch allows discontinuous adjustments to the `tai_loc_offset` field with each new data point obtained. But a lot of applications depend on having a single system clock that's all at once monotonic, reasonably accurate, and reasonably frequency-stable, which means there has to be some further smoothing step involved (perhaps a PLL, perhaps something else). In an ideal world, the contract between the OS and the NTP daemon would be the same on all platforms, and would be something like this: the OS provides the NTP daemon with a monotonic time counter driven by the hardware oscillator, and the NTP daemon provides the OS with a running estimate (maybe with error bars included) of the first few Taylor series coefficients of the function from that counter to TAI. What the OS does with this information and in particular how it communicates it to other applications on the system is none of the NTP daemon's concern. Unfortunately, currently *no* OS provides us with anything this clean, and even if one did we'd still have to accommodate all the ones that don't if we want our spec to be platform-agnostic. Since we don't control the OS landscape and it changes on a different and faster schedule than NTP spec does, there's only so much we can do here. We can specify what we wish the interface would look like and maybe some kernel hackers will feel inspired by it, but for the foreseeable future NTP implementers are going to have to contend with less-than-ideal interfaces, and the most the IETF can do for them is give some abstract general guidance on that.
- [Ntp] The bump, or why NTP v5 must specify impuls… Watson Ladd
- Re: [Ntp] The bump, or why NTP v5 must specify im… Daniel Franke
- Re: [Ntp] The bump, or why NTP v5 must specify im… Watson Ladd
- Re: [Ntp] The bump, or why NTP v5 must specify im… Daniel Franke
- Re: [Ntp] The bump, or why NTP v5 must specify im… Daniel Franke
- Re: [Ntp] The bump, or why NTP v5 must specify im… Doug Arnold
- Re: [Ntp] The bump, or why NTP v5 must specify im… Miroslav Lichvar
- Re: [Ntp] The bump, or why NTP v5 must specify im… Dieter Sibold
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Salz, Rich
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Ulrich Windl
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Warner Losh
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Salz, Rich
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Harlan Stenn
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Kyle Rose
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Harlan Stenn
- Re: [Ntp] The bump, or why NTP v5 must specify im… Harlan Stenn
- Re: [Ntp] The bump, or why NTP v5 must specify im… Salz, Rich
- Re: [Ntp] The bump, or why NTP v5 must specify im… Harlan Stenn
- Re: [Ntp] The bump, or why NTP v5 must specify im… Tony Finch
- Re: [Ntp] The bump, or why NTP v5 must specify im… Harlan Stenn
- Re: [Ntp] The bump, or why NTP v5 must specify im… Kurt Roeckx
- Re: [Ntp] The bump, or why NTP v5 must specify im… Dieter Sibold
- Re: [Ntp] The bump, or why NTP v5 must specify im… Harlan Stenn
- Re: [Ntp] The bump, or why NTP v5 must specify im… Daniel Franke
- [Ntp] Antwort: Re: The bump, or why NTP v5 must s… kristof.teichel
- Re: [Ntp] The bump, or why NTP v5 must specify im… Harlan Stenn
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Doug Arnold
- Re: [Ntp] The bump, or why NTP v5 must specify im… Kurt Roeckx
- Re: [Ntp] The bump, or why NTP v5 must specify im… doug.arnold
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Daniel Franke
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Doug Arnold
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Warner Losh
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Daniel Franke
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Warner Losh
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Daniel Franke
- Re: [Ntp] The bump, or why NTP v5 must specify im… Hal Murray
- [Ntp] Antw: [EXT] Re: The bump, or why NTP v5 mus… Ulrich Windl
- [Ntp] Antwort: Re: The bump, or why NTP v5 must s… kristof.teichel
- Re: [Ntp] The bump, or why NTP v5 must specify im… Doug Arnold
- Re: [Ntp] Antwort: Re: The bump, or why NTP v5 mu… Doug Arnold
- Re: [Ntp] The bump, or why NTP v5 must specify im… Salz, Rich
- Re: [Ntp] The bump, or why NTP v5 must specify im… Philip Prindeville
- Re: [Ntp] The bump, or why NTP v5 must specify im… Doug Arnold
- Re: [Ntp] The bump, or why NTP v5 must specify im… Philip Prindeville
- Re: [Ntp] The bump, or why NTP v5 must specify im… Watson Ladd
- Re: [Ntp] The bump, or why NTP v5 must specify im… Harlan Stenn
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Ulrich Windl
- Re: [Ntp] The bump, or why NTP v5 must specify im… Watson Ladd
- [Ntp] Antw: [EXT] Re: The bump, or why NTP v5 mus… Ulrich Windl
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Dieter Sibold
- [Ntp] Antw: Re: [EXT] Re: The bump, or why NTP v5… Ulrich Windl
- Re: [Ntp] The bump, or why NTP v5 must specify im… Miroslav Lichvar
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … Miroslav Lichvar
- Re: [Ntp] The bump, or why NTP v5 must specify im… Danny Mayer
- Re: [Ntp] The bump, or why NTP v5 must specify im… Doug Arnold
- Re: [Ntp] The bump, or why NTP v5 must specify im… Philip Prindeville
- Re: [Ntp] The bump, or why NTP v5 must specify im… Kurt Roeckx
- [Ntp] Antw: [EXT] Re: The bump, or why NTP v5 mus… Ulrich Windl
- Re: [Ntp] Antw: [EXT] Re: The bump, or why NTP v5… Hal Murray
- Re: [Ntp] Antw: [EXT] Re: The bump, or why NTP v5… Doug Arnold
- Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must … David L. Mills
- Re: [Ntp] The bump, or why NTP v5 must specify im… Heiko Gerstung
- Re: [Ntp] The bump, or why NTP v5 must specify im… Watson Ladd