Re: [Ntp] Comments on Miroslav's NTP v5 proposal.
Doug Arnold <doug.arnold@meinberg-usa.com> Mon, 30 November 2020 21:31 UTC
Return-Path: <doug.arnold@meinberg-usa.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 F2B3F3A11BF for <ntp@ietfa.amsl.com>; Mon, 30 Nov 2020 13:31:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=meinbergfunkuhren.onmicrosoft.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 zwZX-LqjBd44 for <ntp@ietfa.amsl.com>; Mon, 30 Nov 2020 13:31:30 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40042.outbound.protection.outlook.com [40.107.4.42]) (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 A88AD3A1008 for <ntp@ietf.org>; Mon, 30 Nov 2020 13:31:28 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TNGwshTSYxpcOp8sWPQNyHYCyfNPK3ke7CMa09RK4AMaodXKPf3JEr795+33pJMGQHEOCjSjzh0kgBud2sP9ut4v/9ewTZqJXKmGo9QbDq4rNJ7AOUlFvkOuSI5QqNyTk0BnFfztuVDzIYr2G102z4STbohzcd/ECPrpnKP4riju6khcO14mpW/0a4HBBokD1CidEkXiQmIl6fuvA5OoyP+e2OWdV7ppqmX4ELNH3eIb19OHhB59kAni9lwvBPURzaLspKYz+xP12z57aBQorxZAPB2mTDMTRciuVp+Ewgt3kWEmNIqUBczd0oi8x97jJ47Q5nYTIxJyguEELzLtgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6zwE0swWc4nlPGAolvE51gZJnNhLYWgcHs27szvhalo=; b=ZA5+/CJHyls97xZ4cySis2M4NnfoQDerddyPlJ5ZhdUc8YOLWzSdqoRfIVKCYQi8GFVhQOR+zK9MAkAurkK/4QQ+zWcgsHG6YbCrueD7Z18mp3rzrO2t0zQUR8qB/qVvUtYm5mThhs6JOrr0lL5tFvABnTXSHleDMfsfctOKnwEoRoczIO/XWbR1wzJ/KwidPIMo+a2qjIS0zx5sSSnWv+FXrPt0sGfAt/o/dLJh0C01gNfo7ExqCIpbh26BhsJ4vCHi/kbt/cDkBTePxPJXzXGwU9tuXwO1All8Q5zWHMgzKoBHCK4Wr8Fwx+pm/xzEOGtfizcWt3ukzxPsegpqiQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=meinberg-usa.com; dmarc=pass action=none header.from=meinberg-usa.com; dkim=pass header.d=meinberg-usa.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinbergfunkuhren.onmicrosoft.com; s=selector1-meinbergfunkuhren-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6zwE0swWc4nlPGAolvE51gZJnNhLYWgcHs27szvhalo=; b=E4bIc2BlRuj889wntKur99ZcV3NdifSj5rPSSYEqPdpiOjYM9p43dtMOvV4q6Yeh0f9kw1LtSHnm2zjnCM4ZBZugf+iNa4FJwp38t+VeBGJyolm5V4GzRnutOi21NasEFpOa+pRgJyWeoelg4GAxWmllsG5gs0aICORhteIgWnI=
Received: from AM7PR02MB5765.eurprd02.prod.outlook.com (2603:10a6:20b:102::15) by AM7PR02MB5750.eurprd02.prod.outlook.com (2603:10a6:20b:10f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.22; Mon, 30 Nov 2020 21:31:26 +0000
Received: from AM7PR02MB5765.eurprd02.prod.outlook.com ([fe80::d022:fca0:630d:905f]) by AM7PR02MB5765.eurprd02.prod.outlook.com ([fe80::d022:fca0:630d:905f%6]) with mapi id 15.20.3611.031; Mon, 30 Nov 2020 21:31:26 +0000
From: Doug Arnold <doug.arnold@meinberg-usa.com>
To: Miroslav Lichvar <mlichvar@redhat.com>, Watson Ladd <watsonbladd@gmail.com>
CC: NTP WG <ntp@ietf.org>
Thread-Topic: [Ntp] Comments on Miroslav's NTP v5 proposal.
Thread-Index: AQHWu+sPbDZeID9FfUi710FW5mEjr6naT+AAgAahAwCAAAPFAA==
Date: Mon, 30 Nov 2020 21:31:26 +0000
Message-ID: <3C6103EB-5453-4024-8155-E9D5EA3DDE46@meinberg-usa.com>
References: <CACsn0cn8ULX5f_PQVbDsrirPnGHVPWGgMqXn52n_T4P5ELkKgQ@mail.gmail.com> <20201126110406.GQ1734865@localhost> <6B35BF9C-EC1A-4EA7-8D80-AAE7D0CFD728@meinberg-usa.com>
In-Reply-To: <6B35BF9C-EC1A-4EA7-8D80-AAE7D0CFD728@meinberg-usa.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=meinberg-usa.com;
x-originating-ip: [64.30.82.72]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b3c5530e-cb2a-4531-7f49-08d895774b37
x-ms-traffictypediagnostic: AM7PR02MB5750:
x-microsoft-antispam-prvs: <AM7PR02MB5750E69BC7C3BC17B00F709FCFF50@AM7PR02MB5750.eurprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cZ0i15IQX3SxGn7CljbXdQBtON8xrjPKAr8OQAIipSNwHjrPaw7+dHg090XFMCy440LkoxQ9pt4GXya/WKW/2sbtkHE2+iM1xOE95mKrkv12Y5VL4s6cWvBApezxeOOuXW1Jid4RGTgtGH4KftPg6DRX3NTiv5iu8kWSFDimlpE97QcmMBbhrkudQGgSZfeOEKEkS3I6aLtlN9yyXrwEOXTHP6ThgNpDxE4DJI35VHOHbnnPVjXzibW/isPSaZ1xnLhnqse1FNw5BMo8QwrXv8mNXwgwfz6m/WHMMW82ANqOrqATbw4tHlgxd/kv4FajnHwxTWQpauZgTI8AUqq0UaHEJbPcpeWmKrKkvyXdy2BkfFxpFjNRd6LsDZ1oRCYPoiHLhQ4ste/gfadBKzKwrg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR02MB5765.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(39830400003)(376002)(346002)(136003)(2616005)(86362001)(2906002)(5660300002)(6486002)(186003)(91956017)(83380400001)(26005)(966005)(316002)(33656002)(110136005)(6506007)(36756003)(8936002)(53546011)(8676002)(71200400001)(66946007)(66476007)(66446008)(64756008)(66556008)(4326008)(6512007)(478600001)(44832011)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: SyGrPrnrGq5TCB83FIZuF0yCjpjvMF+02YTqR01Ln/MCsajzFdt2UdjLXBG8FuYh5k4a8emw2xSxXzWwoylmuU1hlD4ZepOrVU/r7Id+6yrDt0D7NVCwM2HEZk0d06Lz3bC/APCJPdmGB6GBGX7tlUdiNtdE147gPR/wVTwO0upkrMEGI4uDWNEJw3QGILEVJ68+JGTTtE3hKdCv9I6rLhojawgehLs1Q4YSLDaEz3+09+4ZT/rJavfFOgxSWpdZdM5yHdI77dUybJLr/hlF9LJUPILAdXIhW5FAB6bD3S5Md6kqjBNJ55cq7PDoHgZZqhT8DljcJHBmIJb5gGjq52TqMxdI96P3KpySKwtSsPp0abrwcZ44RyU9trGXUyy2yrQKLe121nnEpjfIIbfiEJ3Biia/ydCwcz9hVn8uE/PNw20w004+j8vb5rxN+aSvxoBYUBR97KsEnsSZBQZHkIwHScnCFg1tSnRNYdMNyGfr1DE20N0dU293+GFjABcNnkfoM4uGg+Vztp37GCvQBG0/4VrSp2OYEWdGCpNxOlC6IS0sS97lRLHJS5X3Q3FKNMosrM8lQ9r/nBhkll3KMNS/0yohglY5eJStRxT4dtb34kusxx87bHRONxJXoObaKLjC1ucIcqSeJtQtxXhHvNDdtDd0lE+XJL7Vef3ULBsSCi7ZhppQ54HqQBAykeoNuZEdU2+GqNKzylwTmXeYNomJUDXD3kPS0J62kjaGThnngC524N2ev5rdBR+dw+Y5YkoCLMQgH7Q04asrLENLIrwaujUDxwmawRKPNn4OSuk1YcayqrIXmZhG4IM/l3ha7daR+ZD1ziE5zKc4uwSQ3GBzusHmqws/hfx+/jH/BlFv79Lz6TQx8jwZQ6blvhoh0f6RKGMI9F9ZDDLLePVTy9nb30ZAYILMXhsioGXD+avnhjjH8n9Edz/aeRT1XrRLKxBWvCNKoQ3KkwyUAOHldULqaOJQXfyhrJ2hGBabOUZzBilSqd38TufRWGyBAT6q
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <69989F01B0C0C04DB826B80B91C6B99F@eurprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: meinberg-usa.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR02MB5765.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b3c5530e-cb2a-4531-7f49-08d895774b37
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 21:31:26.7673 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d59904cd-769f-4368-8bd0-f5f435893a38
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: J9wLKISq5VuHK0eBBxfxux7QC0wJkQQLyy6d2plf0VcLOEfwMyyi23NIbDAYYRBSZYdBzD/h8RFOnhWROP0Mn0Yj7j5N+wYBU8apJQnDFQ4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR02MB5750
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jGUxy-IzUIa_T8FEV0O2Yye03MA>
Subject: Re: [Ntp] Comments on Miroslav's NTP v5 proposal.
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, 30 Nov 2020 21:31:32 -0000
One more thing on the correction field. In my scheme only the client offset is corrected. The delay is still the real round trip delay, rather than some kind of corrected delay. I was thinking that the real round trip delay is what matters. Is that right? Doug On 11/30/20, 4:18 PM, "ntp on behalf of Doug Arnold" <ntp-bounces@ietf.org on behalf of doug.arnold@meinberg-usa.com> wrote: Regarding the datatypes: What do you think of time16, time32, and timestamp64. It makes a distinction between the first and the format used for timestamps. Regarding the correction field: I think that the easiest route to adoption by manufacturers of switches and routers is to make it work just like PTP. That is one field that corresponds to the dwell time, difference between the egress and ingress timestamps. In my scheme the switches and routers do not even have to determine if the message is a request or a response. Regarding interleaved mode: I think that this is only important for niche applications that need high precision. These are generally in smaller networks, where servers saving state for each client is less of an issue. Note also that several manufacturers make ntp servers with one-step hardware timestamping, where neither follow_up messages not interleaved mode are needed. Doug On 11/26/20, 6:04 AM, "ntp on behalf of Miroslav Lichvar" <ntp-bounces@ietf.org on behalf of mlichvar@redhat.com> wrote: On Sun, Nov 15, 2020 at 11:35:02PM -0800, Watson Ladd wrote: > The following are unsorted, rough comments. I agree sending them > outright before the meeting is probably suboptimal, but I need > something to do to keep me awake to the meeting. Obviously this is an > early draft, and I hope my suggestions are read as contributions not > criticisms. Thanks for the comments. > The data types need some evocative names. Maybe shim for the 16 bit > one? Not sure what works for the 32 bit one? I have no good suggestions here. Maybe "short", "medium", and "long"? > The distribution of multiple scales needs some careful thought, > especially leap smearing. Insofar as we need monotonic clocks, I'm > contemplating MJD as a basis for solving the problems leap smearing > were supposed to solve, but we might be stuck with leap smearing due > to the install base. It's not clear to me how timestamps in a MJD-based format would help. The "Monotonic Timestamp" from the draft is not supposed to have an epoch and it actually doesn't need to be from a monotonic clock. I can see how this could be confusing. There should be a better name for this timestamp and concept. > I'm not sure UT1 deserves a timescale. It's a comparatively slow > moving offset from UTC, updated every month. Would an extension to > propagate this difference work instead? How would an extension be better? Are you worried we will need more than 16 timescales, which wouldn't fit in the 4-bit field? There must be some demand for UT1 as NIST runs UT1-based NTP servers. That's the main reason why I put it there. I guess it's very convenient for some astronomers. > If Root Delay and Root Dispersion are propagated something needs to be > said about their proper updating. These values are used in source > selection, and so some degree of agreement across implementations is > desirable. I'd like to have a section on the metrics. Explain how they are supposed to work and where they can be used, but unlike RFC5905 not enforce any particular model of the clock. > The monotonic additional timestamps are an intriguing idea but I'd > like to know more about it. In particular the frequency to be > distributed seems pretty awkward. Maybe I'm imagining the application > entirely incorrectly. The goal is to give clients two separate signals so they can better measure their phase and frequency offsets. With a single signal there is always a compromise between phase and frequency accuracy, which leads to various issues. As a simple example, consider the kernel PLL used by ntpd. The monotonic timestamp could be set to the current system time adjusted by the current PLL offset. The "monotonic" time provided by the server would be very close to UTC (or another negotiated timescale), but its frequency would be more stable. I'm planning to make a demonstration of how this can improve stability in a long chain of servers. -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp
- [Ntp] Comments on Miroslav's NTP v5 proposal. Watson Ladd
- Re: [Ntp] Comments on Miroslav's NTP v5 proposal. Daniel Franke
- Re: [Ntp] Comments on Miroslav's NTP v5 proposal. Miroslav Lichvar
- Re: [Ntp] Comments on Miroslav's NTP v5 proposal. Doug Arnold
- Re: [Ntp] Comments on Miroslav's NTP v5 proposal. Doug Arnold
- Re: [Ntp] Comments on Miroslav's NTP v5 proposal. Kurt Roeckx
- Re: [Ntp] Comments on Miroslav's NTP v5 proposal. Miroslav Lichvar
- [Ntp] Antw: [EXT] Re: Comments on Miroslav's NTP … Ulrich Windl
- [Ntp] Comments on Miroslav's NTP v5 proposal. Ulrich Windl
- Re: [Ntp] Comments on Miroslav's NTP v5 proposal. Miroslav Lichvar
- [Ntp] Antw: [EXT] Re: Comments on Miroslav's NTP … Ulrich Windl