[Ntp] Fwd: Roughtime protocol suggestion....

Marcus Dansarie <marcus@dansarie.se> Tue, 09 July 2019 11:17 UTC

Return-Path: <marcus.dansarie.nilsson@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 CD73D1200E9 for <ntp@ietfa.amsl.com>; Tue, 9 Jul 2019 04:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.108
X-Spam-Level:
X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 GGYSDXIJVGsZ for <ntp@ietfa.amsl.com>; Tue, 9 Jul 2019 04:17:23 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 3F936120088 for <ntp@ietf.org>; Tue, 9 Jul 2019 04:17:23 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id h28so8797107lfj.5 for <ntp@ietf.org>; Tue, 09 Jul 2019 04:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:references:to:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=EAM80N6Pep991elw65ws9nrc5nhnRPzkDh1+E0m9ZBs=; b=s3oBt/UmRmevFls1x8DADUDagps9hHwx5zr/wOAlN7lHRR1vXyVtR9vj3Q+s3XalMU qNYd5LSHS8QaaXl2P8iHs4erFQGnNBsCgV9zyKUR/3RGRCqz/neksBUQCsxPwFANjGts mAeoGVIl/Lxa4Aqsqia37lB/+ZFDXYD6zv61L7KZZRIrMLFMH3LwVT+vF61ee6LJwU9S /aNtBShmx6com4YQ3isWzSOGrmQC1jOh3WyCuG1U0Mu7pbCXCDyN6hhkQk+kXFUwpPmX tfIJJy2GKacIGwRzq8jW/meF3ox4YcUM2XMAu35kB6hjz+Wdca2JvlcYxWy/kGldwYC6 6Aug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:references:to:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to; bh=EAM80N6Pep991elw65ws9nrc5nhnRPzkDh1+E0m9ZBs=; b=iFrNFTKFzFXzq+6PA70MDC1YzUSvWrfB5jKPzvPuAEPaoxop0YeAOMY+P17Kls6N/6 YqxQK+tYM72UNcUP52+MCB4OGxEzthJto328YoEzEmO87PJ4qzXW6oQGZnGyhyBvq8YT FHtYM0jQoBqJso5MTK499JMtej9bibWmVhfb8/ShSzhWkHeH+0Z2MCYpi/l8eY1GpHEz CbXiibKzZyBDCBcBoS97qFYi5WimV3ARgGFoabXwLDMl/Q6sgaRKvMjYinUW5ROuKSB5 bDsmhZ8/V6B1Iii3qiw0BHThNP6tOaPB/2T+gp1ZvH9gtYuOA92ggYzgeaQArdLGPn2U YE2w==
X-Gm-Message-State: APjAAAXN2DBAtRHLskXZW+on6FM0ALP/1X5xbfi67+QD1sW3IXNBRCvF 3WaJ+1T9NzhLjo9hr7ND2Tg=
X-Google-Smtp-Source: APXvYqyHq6BirH/5M8RTBgN5CdXqjL8/sBVJVHcu/yoNMJ/JD61ZjIwYvVaAOMwzakgsNm85ej0XUg==
X-Received: by 2002:ac2:4c82:: with SMTP id d2mr11602055lfl.89.1562671041440; Tue, 09 Jul 2019 04:17:21 -0700 (PDT)
Received: from [10.0.0.126] ([185.40.184.26]) by smtp.gmail.com with ESMTPSA id b27sm2349845ljb.11.2019.07.09.04.17.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 04:17:20 -0700 (PDT)
Sender: Marcus Dansarie <marcus.dansarie.nilsson@gmail.com>
References: <CMM.0.96.0.1562430160.roll@Stupi.SE>
To: "ntp@ietf.org" <ntp@ietf.org>
From: Marcus Dansarie <marcus@dansarie.se>
Openpgp: preference=signencrypt
Autocrypt: addr=marcus@dansarie.se; prefer-encrypt=mutual; keydata= mQINBFawEn4BEAC8YukDy8f3eczlE8WAcuctrjsNltPCLZDzcj3vBmiayXlXuPULOopqeuw4 +oaZqj4KqvdFBA1mzvwPll7IHePuwAoJYJr48IbIXc9MRjtLoFtd0KnhiVPUS8F2cmfzSJ8E FEv92sz6UT8/tlLEu6sNqr6/caYUivspuW5wf4f6nkSE+6rao9Nx9X03r289IPNBSZv+Y/Ym jWHDPpbT8WLUJZ+A8RsW/1oza609oAzqTkclmnRzip8wZZWNg3Q55P7onBmTIOrEz13My9r5 DWCMHyxXgFL1RJ9YW0t4yRkRm+HvOn3Vesk3m8CCGA6esHV0IPZmBOxJr3l+UQYuDiTgFufr WMpu5MvlyKGHS4fNd505DyyJY2G6eQLLrOq3nZy4qoZSL42TMxzYglexg+H6P/YsIIShk5Ch h/hNphXjrElDWhbGT5JiRWIivgSj/gq5QVBbDLR3b25n9PA0byGemfcEHLkii6EKyH7GW6v9 sgmvCmPfEfppYcOP2g9Jdt8RPitx0UBjoCzWAn0Py0NvlFDyz0FQhWDPig3yo1CG5ljb686v VBwcHJthczUV0rIyVzfmnikIb9ZjydHSX3fFwLz1IcIIX+INS58qA0SDqOoyP2WTYGZCDPVw GMMh+wMtAL2MICTr6vybFWB58m4PsI1j8Ri+AQiEkxyJauI2WQARAQABtCRNYXJjdXMgRGFu c2FyaWUgPG1hcmN1c0BkYW5zYXJpZS5zZT6JAlwEEwEIAEYCGwMCHgECF4ACGQEJCwkNCAwH CwoEBhUKCQgLAgUWAwIBABYhBBfkVFb0H62SH33Csy9j5/6tpPBjBQJcLN6RBQkHXf+TAAoJ EC9j5/6tpPBjZNoQAI87t6fNeEDUe3mVxvhHbh0IQ3NTv5555HstmNA6ZKYeUhFIRFGGxo1D a93viLr59dL58NR43O4MA6IJTsOdCxnZfGMLRs7yHGylnilJEh9OwFHEJp0GprJ2RqfBGJsQ 0qQu90ptGhNWHeN1nEVPYg6tyTz6jFG+YuvHzIZjpCFY0xG+J92gncTDG8082kkp/fxSvKGr 6nxiH9lOxItJsUjRF3fUsmr8QERKfaYkrHaqEM05q0zlQu+ofwmq8oHk2Mlx+Earb0KgGWqM 85l8+uVnM/DKeD6qH8zAaOQImcyEn7KNQuHR+FELPRFFJ5BkSrJXat8P4ViC4Md0lF3X3sm9 nxztGbVD4v9M50ci7hosVsiqslU/nMv59f3NPATR+sOZrq3K5rSUGeVbF3+3ZT3fF4FfE7Gl ldtS8D4Lq8MYbfuFD4JnhqLQf9nuOeBH2qcJf6M6R5yi+NwEF7w1xGWYfI+ifNRlPl5FCJDj ft3JFxswKMpobyp2Amo1oman7kORTZ+dnQ9JNLZSbqSZRZ7CQt30exO1jgW0H0oYKVlZ3p3Q VqVC4BA5Ap7Pc6Da7LlgJnF6yfy1ODFllYBIT4kLOL/99W9CsKinaa6pJAjfs+x1QzzrR0ji ucHinLTeZ4JYDtFxXAEkQ2tuxaouoz+cLwrOwTepiBOiUtYnAg8tuQINBFawEqwBEAClJOj1 zOQTMRGzLK/08tEdwR4EwBDiWNci0JtjT59xtJdlGujuf/9wkt9hRIiALqt8U0vHwCzmxVTP Eueewv40WOraJzzDv6OBXJZMeF+IN1/CGrZcn8rLG9J1CyyVf+gCxUUXmpQDlE91iYMB4ifj dTTTizRnVYOQh54TV0yyiL2bn+ZdL8NYNpUbpoG2vppltt0NXv9ib9WPug9Q8Sx33CkkCj3F HJLHeHqo6AkFTpBdSn6/Ezs+ZHpuhNCHtrZyiJOi2YZ8EzpuxDwVjHLh8iXu0amlXSGP5wA7 MpNEtomhGw3bUr3aBcenfS4u/RE3V/y+vXae33LtVmaH7sli0SmrP8iUxkks2qjtS6W2a/qF xlHK/FXBChNIG0uRROvDlIudg6UHzQlK4mBdraGz4etfDpsNAX0x5ssxBTaFrJlZz935GPLR sg4o5f+FYcQrIZGisfCmiH8rdF1bkz450/OyfzS7lTCoxeizOnlamVwUCTfrWah/l8BXgP/i Y6KlbGpfr7aVYvA5e7fPe7uRqzPsxq7pL72r3p/TkNuPtJ7cbShN99p7v/v38STSJ4jbzy2W LMBFw5dJI73XtSGU2g/viZgVfl4Tro4XeYMF/FmRDiYcd+GpuDoB+g+NJYpGRGnr4+GgWl9U YCnN1TE9LSpvehvvKMvGqi0U1ENOUwARAQABiQRbBBgBCAAmAhsCFiEEF+RUVvQfrZIffcKz L2Pn/q2k8GMFAlws3qsFCQdd/38CKcFdIAQZAQgABgUCVrASrAAKCRDBCAAOw+Eh5rtYD/wN eZOov+0rwhszfD+IY9fI4qFUjuiKWR06fJ60HV7cStkDW6WtrF+NkUAwH5G0yrA+izyI9wtR 4r5OW5ruPWTRbHxOmsLfRnqh4dKU6uCvtoL+LNzAMyPORiZkzomOaKAPdtiVgECVupLsApDl 4tI2hpMYKmeTVuessXa83oGOi8uQGK/M57Koz20KPfLltJBsCcOwofCUdbmaPOlN/DspOaIe LWzN7qb3pzAuUltBCvVI3VRgqvfh6JSiGyaSUfjghfbtz0uAlZ4wSfHX2+Iw+1/9mlElZjkC y6QgxCb1vMqGSw5u596aGVm7m2zVGLn4/xhpFNbxHUwWre/AAMtJR5ASK3cq2au1U2rOja3f rRfzMuBqTrQGb+OcCaesaOssd7t+RmDKfv0u40z6ls9Mzav+BCXzfOnb3HNAgJE5C/xApTsd xhn5BZoxHy8N2Pc0emWe6JI5UDPlKpuwH6JDKrLaoHhE7Gy2U6iinQcgI5IEEa8wmwoWfkjU 5phTbZVHJ+yTOeZWcbJtyFIX18fbzyrZWguo1EWHubv33KqbiJ6klpfg5chwKXWZIlLmbivp Dv0KRybk5GB+X83OpeAH9dKT3kvcu6midppjFzakSIiaoSJDS9jcqQYEiRG71lnD7QdCoqjb fHZh8HXGYSbenDzisWIRouGsimOyeSaX6QkQL2Pn/q2k8GOq8g/+PAcag2kmEQeJIVEtVCA3 e+/v+9XTi/7X7fZ247gAHbbaZKavRMFmgVsJNq6riC4HoetUWwMWJ2A/buSVMVJwAd5pWXAq WkOPWgv60FN92yfdUPjXXhLMXhntCLaRbNmKw0gETFLlUGXbRHyiO02EbJziI+vOr3R3AYa/ JEvsCHKX6TUm/HerBmzTUOi/igtd/H7B4EYcO5bZLKSJ8RZT5hKwOpVIYOdvBWZx2+MTG++A w6mDCgpIRseWgsyrkfsKkf+xQw0JewsFMyW5z+swV5/SCrhzexRIh1Jr5KBQ7FI7WgO5l46o EKtCmBjDSckdlBg5wfpPHK4s3k3FreX/tPqrzwTaBY9NIyzLGE2KFgr5lTWOr4P5xb37CNg4 hCzSJStvrlR/MscUmjaYR+dHCwzNr5tkBDSIqBKw6THWV+i0g3Vo41FF06Eg8dnW0yMX5Vfp zw9YYFsTV+WbKBTRwNA6OsAkkD7zMU0KzL3+i33uzgo+CffBYJs12yABIWXtNWlXiJpqePyh /6PTEfYMUE7dDr8qlEt23AoGs3Eme+OgY/Y5Yv03jcINp98/qnXnnqf9ghpVavajVwOIQui5 CMxWUkDweNyEYJA4jaKkov5/iwssNosBSF007b4loCXLv45iz8jkQwYHUwzH86W6Gk13/bdt v0ksRjKe291ygQm5Ag0EVrASywEQAMscigyDy6txQ/cUE8P+S9zMPNbsTSqa3iyj0SREswxm JsrUou+yOt/Y4UxGX+JLc/zjI1+frWE33CNmucYMtrZSrxgQDp+Wp8Ak7UNQlBtRIjdcPqmA EFzgG9OP7If7MJZMeWVd47ybIYUKohuTdFgwJSF80f+DGLLjIchyVZbvyZWSQKIAxfavmZr1 CNEVYXyrL752rLVB+KnQgJaFqHFPp6cO/Y20ViF9QsLRtlref1VrxtdPuILhEKMmmc+ZRsDh J0V8Mi5q8pWcYWrz+JiVRyA1ULAhg6C2ypj1cFNnQyN22XptXbz687bqZQxar5xyAAV4D6i/ 8q1kNgSsbDq+XkWuGjS9kmvLGM9kGARNhMFNguJSgSfqZExPAJhCZ4hVboTKFoRR10482rlO yj0Va0GbmpGqftjNodA4mjpBi52pNymUF+s6eTk13L9DOOJ8d0+2Qd6e4uTeNXJhNW6g2l7b 5dt/bbHMla7hgqRKUtTqQRR2JCpP3vF4sHWnXYdEcJSACarBcxbfdwZBnF9Nwv7GiNTEEg7O +8qwlj16LTB8oNWjOwAHiqg0xQlL8JTz2rkX0gUIW1Hy9A6b6UikViRbmpHXg0s7364Xtxji mkKD8DVnC5NJDiwZztqG2iW7kxJnfA+eAClKEh+niZo5NpjWNUfhjUXM5DNVHtchABEBAAGJ AjwEGAEIACYCGwwWIQQX5FRW9B+tkh99wrMvY+f+raTwYwUCXCzeqwUJB13/YAAKCRAvY+f+ raTwY6oaD/9Q1RhI/RNI0TmS60ih7gTZ1wvWbU24qGHZ1Q5kgriS5C59IWDkVlOCx2qQVwJO eGBrUHDhEuL2AuAF46Rmh+tIFMqij8Orz8zebSydM8aBtSPua2QpAta/IJS/5jvGN0aKbim8 MpD9oCHFp7N+37p7e5jrpLHz3qh5cDau+fFDUzS04gtcgkJb3wXg0MhgoZF/KU3JSq0Xs0Ni ioljOHDgOddGzO7Dd2KbCW2vtzo7m50yrLHI77hsocnkqrIcIn6TeYtH7K1aksEI0KC2Sg0b ome7eO8jCziXZO73iwq9hflXAiZp9CM2HWlb7e2zXe8vChJorEf+9w3t/jyvQzCtOf12jUM1 xr99DODBAEtJ0/tUfSsGvfETmAhYD2tjRmVwzB7jRq6U4bc5jtcYEL5YKEWBIvJDVvzE3iu/ HHjc83bIIyqxeYyT3uClTWPVP5OEWBxGUas7u3hlxxmSzGjpXUDBZyoeC+Q6Q3WUp6zOSg+/ yVwD/KBQQ/Sy6vOfvgh6PmsP1D5xCZSl6UWnxSi8lTtAcjUjHyG1qCudR/pmDv0OL5Ul8PeF 87DBMz4Y0our+MslzlvhrmI90XcKAyHrukdnanS+gle61a44uFwtUGPTvCtSW4AQLR1uixc8 qaHsQNmXpQQOIt6nudcOCisXa1c6P/WU8I94u9BmCjTWRQ==
X-Forwarded-Message-Id: <CMM.0.96.0.1562430160.roll@Stupi.SE>
Message-ID: <3751fd04-36b6-0e1a-46cf-c2896cc20554@dansarie.se>
Date: Tue, 9 Jul 2019 13:17:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <CMM.0.96.0.1562430160.roll@Stupi.SE>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cABzydoK1lFemzuOgoFku2rt9wP09LhGx"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/joQKimSUeQQF4qJQlwtgyhCWAh8>
Subject: [Ntp] Fwd: Roughtime protocol suggestion....
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: Tue, 09 Jul 2019 11:17:26 -0000

I contributed text to Roughtime draft-03 and had some discussions around
that with Peter Löthberg the other week. He sent me an email this
weekend with some comments he wanted me to share with the list. I'm
copying it verbatim below.

Regards,
Marcus


-------- Forwarded Message --------
Subject: Roughtime protocol suggestion....
Date: Sat, 6 Jul 2019 16:22:40 GMT
From: Peter Lothberg

20190706

Marcus, please forward this to the mailing list.

Marcus (& others),

I think it's a BIG mistake of not taking proper handling of
leap-seconds in to account on protocol designed in 2019....

Here is a proposal, I knew, it's some more lines of code, but
even if someone fucks up completely they are within the magic
second you wanted.

Today you have 5 bytes for microsecond past midnight, so
protocol resolution is;

0.000001, second

First question/proposal is to encode the "time word" MJD day
and fraction of day in a way where we can change the
resolution format, this way we can keep the format for the
future ("the Internet/IANA way of representing time in...")

Eight bytes of MJD and 32 bytes of fraction since beginning
of day (don't make it milliseconds, nanoseconds, picoseconds..)
can be encoded in a byte; (Let the server chose the format
for the resolution.)

01234567
DDDFFFFF

So the 4+5 format I recommend would start with 10000101

Time can never go backwards, by doing the division and changing
the number of seconds in a day a client that do not understand
anything about leap seconds will be approximating the time to
the best possible without any code on the client.

A client that supports leap seconds can do the correct thing,
and it's possible to have the client tracking the time of the
server.

Also a note, we should point out that any "local time" is a
operating system problem to deal with the 500+ rules out there.

Let's keep the 5 bytes for my examples. Instead of using
microseconds since midnight, let;s use fractions of day
since midnight with the available resolution. I put the comma
at microseconds.

5 bytes = 40 bits = 1,099,511,627,776

A regular day has 86400 seconds; 86400/1099511627776
gives us a resolution of;

0.000000,07858034223318 second

Better than 10 times better than the microsecond model.

Still this does not solve the leap-second problem, as it
require us to knew BEFORE the 24 hour period with the
leap second is started.

We need to knew three things to do this right;

   - Is the leap-second positive or negative,
     (as we don't want to bet our names on that it will
     always be positive)

   - A warning telling us that a leap-second day is coming.

   - Are we in the leap second day?
     (I'm not sure we need to send this in the protocol, as
      leap-seconds can only happen the last day of the month
      a calendar function could calculate that from the MJD
      day part, include the C-code in the RFC that converts
      the fractions in to daytime and the calendar.)

On a leap-day, we change the 86400 number to 86401 or 86399,

86401 86401/1099511627776 0.000000,07858125172788 err
0.006789,42014928883200
86399 86399/1099511627776 0.000000,07857943273847 err
0.006789,26298860380800

(I'm making the assumption that someone want to save on bytes in the
 network message here, if not, just add another byte, put 5 bits
 of fraction after midnight and all three flags in there.)

If we take the two least significant bits out of the 5byte/40bit
field we get 38 bits. 2^38 = 274877906944, 86400/274877906944

0.000000,31432136893272 second/bit

Still better than the one microsecond and now we can encode
the leap second sign and the warning flag. If someone don't
care and use all the 40 bits as a time stamp they will have a
error of max 0.000000,31432136893272 second.

With 38 bits we get;

-1 sec 86399/274877906944 0.000000,31431773095391
 0 sec 86400/274877906944 0.000000,31432136893272
+1 sec 86401/274877906944 0.000000,31432500691153



My suggestion is to do 6 bytes, 3 leap second control bits
we get 45 bits to describe time since midnight, resolution;

0.000000,00245563569478 second

And use the "number of digits" encoding.


--Peter (as there might people with red line yards in my camera view...)