Re: Predictable Internet Time

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 03 January 2017 17:27 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E641296B1 for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 09:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Y-5SHDpxfpZo for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 09:27:53 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 02F2E1296C4 for <ietf@ietf.org>; Tue, 3 Jan 2017 09:27:53 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id c85so204637985wmi.1 for <ietf@ietf.org>; Tue, 03 Jan 2017 09:27:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bo08y0el/8n/xVEz/QKMhhfO4Gfs7N6MefdBUhTkoOg=; b=toX6aLv3jtNzu+EVN+xlVGpDu+lIR7GkdiNzYW2ISivvtcEEmi2WsaEzM0n7xCVXrN +SSKhBmBAfCeQxjn9nRTBUoe4UJXw6x5n86n1GeDVONU/1rE0bRVJuQbuzwAUFZeOQFY wkD1ctf4rvPgUHBTyBTTVjODmaCZmON7Qwb39AEoWjdEN0vjtxravtanphILsf6yY+Bc hwKf7IZn2JGW3N4Oc2XwjCQsv+IARkVSa4qUJAvIMeY+/qCUFZThIGzjMuvKkTnrKqMS 1HLpMPOiDnok/yjJ+gYu7gpaHKp9mkYj5G5qVXa7laBMPtLLqdCr9/edYgS0t0nrERMd l46g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bo08y0el/8n/xVEz/QKMhhfO4Gfs7N6MefdBUhTkoOg=; b=FebsZCpfKL5cYaToArl7oqg03Wu7IUx0N6Cl3vT45Nfpeefnu4aE+xHJRMXaL7Vl4a mLae5OL74vJBTKWpSnaU6Fwk+Txl7U9GYosAEtxKDaFiH+on6B21voO8kY1NGc0HSJvH iya8i78U0gbGnDZRMs4W+ntRc8d8QvrXBiASJqCEi0kindZRXbj63bcyBty4KG8kDOah +JpA/s73zJ5ega/8SMFMfI27R9VlD/0Py7nYv7z4fIcX3/WA0hu26m7C/xJAAgUVZgt0 EVbsfXo1BzY349IDtbTUkGmngFxEZtp0/Cze4bB0AKKhA1cKqNU4b55tEhg1Tb+D1iaV IoHA==
X-Gm-Message-State: AIkVDXJWrtU3sxwQ4lG4aB9CsdMBKcWFFq3fXaQ29Yl5mPL1lKUPQhPeKJFpP5OtGGs1xBFCsGmMd2i76tQ5KQ==
X-Received: by 10.28.198.67 with SMTP id w64mr59034709wmf.13.1483464471424; Tue, 03 Jan 2017 09:27:51 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.83.101 with HTTP; Tue, 3 Jan 2017 09:27:50 -0800 (PST)
In-Reply-To: <9F0F8841-BC1D-4C27-83EF-8F93F33FB021@puck.nether.net>
References: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com> <9F0F8841-BC1D-4C27-83EF-8F93F33FB021@puck.nether.net>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 03 Jan 2017 12:27:50 -0500
X-Google-Sender-Auth: 6u9rro6gRw59ikTQcvhPArs7138
Message-ID: <CAMm+Lwh5JMn+JxPB3Q3RKpeibckVSB2Fqm_RajcnU28OAx=jOw@mail.gmail.com>
Subject: Re: Predictable Internet Time
To: Jared Mauch <jared@puck.nether.net>
Content-Type: multipart/alternative; boundary="94eb2c193638db3b1f054533fc4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Yo2rrZISkZj98ePfbdFvyEHcJso>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 17:27:56 -0000

I will write up a draft.

However, I'm not the inventor of time smearing, perhaps someone doing that
would want to work with me.


Looking at the problem of time smear, I think Google's 20 hour as opposed
to 24 hours approach is probably best. Most platforms use ticks (100
nanosecs on Windows). Using 20 hours means that each increment is exactly
even. Using 24 means that they are going to be slightly irregular and can
lead to variation.

The problem here is not so much the adjustments themselves but knowing
whether an adjustment has been applied or not. If there are two parties can
apply an adjustment, it is very common to see 0, 1 and 2 parties make it.


For any scientific data, times should use TAI and be done. Leap seconds
have no place in the physical sciences, astronomy included. Using UTC in
science is as barbarous as using imperial over metric.


Another related 'best practice' issue is that we should stop scheduling
flag days for midnight on 1st jan. The Internet protocol layer does not
have flag days but the WebPKI does and we need them because we regularly
phase out algorithms. SHA-1 stopped working when 2017 began in Edinburgh.
There is actually a very good reason for that first Thursday after the
first Monday business.



On Tue, Jan 3, 2017 at 12:07 PM, Jared Mauch <jared@puck.nether.net> wrote:

> I'd be interested to see your proposal in the NTP WG, at Chicago or
> earlier.
>
> I agree this is an area where there is need for improvement and assistance
> is welcome.
>
> Jared Mauch
>
> On Dec 31, 2016, at 4:32 PM, Phillip Hallam-Baker <phill@hallambaker.com>
> wrote:
>
> Well the astronomers are at it again. They are messing about with time
> which is a terrible idea. Specifically they are adding another leap second.
>
> There are many arguments against leap seconds and the arguments in favor
> really amount to the astronomers declaring that they are going to rub our
> noses in it for as long as we let them. So here is an alternative proposal.
>
> The single biggest problem with UTC is that the decisions to add seconds
> are made by a committee a few months in advance of the change. And this
> results in time becoming unpredictable because it is never possible to know
> if we are dealing with a corrected or uncorrected time. For this reason, I
> have been using TAI as the basis for time representation in my recent
> protocol proposals. This reduces but does not eliminate the confusion.
>
> Leap seconds occur at a rate of roughly ten per 25 years. So not
> correcting means a drift of 40 seconds over a century
>
>
> So to remove the confusion entirely, while preventing the need for a
> discontinuous adjustment of the drift between UTC and TAI, I propose the
> Predictable Internet Time (PIT) as follows.
>
> PIT = TAI + delta (y) where
>
> Where Delta (y) = int (37 + 0.4 * (y -2016) ) for y < 2116
> = 77 + (UTC-Delta (y-100))
>
> For values above 2116, PIT would make use of the table of UTC corrections
> with a delay of one century. This would enable manufacturers to build
> devices with built in correction tables for a design life of one century
> which should meet everyone's needs except Danny Hillis who is building a
> clock anyway.
>
>
> A conversion to PIT would be feasible for most governments as it is highly
> unlikely that the variance between UTC and PIT would ever be greater than a
> few seconds.
>
> The big problem with planning such a transition in the past is that the
> alternatives on the table have been stopping further leap seconds
> completely and continuing the UTC scheme. That would be a recipe for
> disaster unless the EU and US both adopted TAI+36 seconds or whatever. We
> could end up with a situation in which one side digs in its heels, refuses
> to change and we end up with a 'give us back our eleven days' type
> correction.
>
> Nor is changing the definition of UTC to effect simultaneous change a
> feasible solution because to do so would be to demand the astronomers
> accept a diminution in their own prestige.
>
> With a suitable definition, PIT could create a condition in which it would
> only take a decision by one major government to force a change on the
> astronomers. The commercial advantages of PIT over UTC are obvious - fewer
> things are going to break for no good reason. That is an argument that
> every politician is willing to listen to.
>
> While a variance of a second or three between New York and London might be
> inconvenient, the inconvenience is going to be a lot worse for the side not
> using PIT who have all the inconvenience of unpredictable leap seconds plus
> the inconvenience of the difference. The pressure on other governments to
> adopt PIT over is going to be significant. It is hard to see that there
> would be any real constituency for the UTC approach, the astronomers are
> much more interested in buying telescopes than time in any case.
>
>
> We could tweak the definition so that the corrections kick in sooner but
> it should be possible to build for a minimum of a fifty year service life.
>
>