Re: Predictable Internet Time

Joe Touch <touch@isi.edu> Tue, 03 January 2017 06:12 UTC

Return-Path: <touch@isi.edu>
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 0EAE5129434 for <ietf@ietfa.amsl.com>; Mon, 2 Jan 2017 22:12:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 KCZ-bq4V9Ebh for <ietf@ietfa.amsl.com>; Mon, 2 Jan 2017 22:12:04 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 120AE12896F for <ietf@ietf.org>; Mon, 2 Jan 2017 22:12:04 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v036BPDr005160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jan 2017 22:11:27 -0800 (PST)
Subject: Re: Predictable Internet Time
To: Phillip Hallam-Baker <phill@hallambaker.com>, sandy@weijax.net
References: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com> <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <CAMm+Lwi_jU6gjdtdM6a2n_9_89tUvWBNXxnMtSjTEA++h1D4Ew@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <e0a43370-751f-808c-3719-9716f9cd57d1@isi.edu>
Date: Mon, 2 Jan 2017 22:11:26 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAMm+Lwi_jU6gjdtdM6a2n_9_89tUvWBNXxnMtSjTEA++h1D4Ew@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------52E5E1984B11F0FF35CF2EA9"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ak35C7EkhBKPeBSkaFcpKylRB-8>
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 06:12:05 -0000


On 1/1/2017 11:24 AM, Phillip Hallam-Baker wrote:
> To have a complete solution, the way forward would be to require
> systems using PIT to use the 'time smear' approach that has been
> pioneered by Akamai and is now used by Amazon, Google, etc. albeit in
> slightly different and non standard ways.
>
> Using time smearing, a program will never emit the time value 12:59:60
> as demanded by the standard. Instead the leap second is added to the
> machine gradually over the course of 20 or 24 hours. This avoids the
> need to emit a time value that could cause a system to fail at the
> cost of a modest difference between the purported and actual value.

Smearing leads to differing interpretations of elapsed time for two reasons:

1) smearing isn't unambiguously specified
2) smearing doesn't match the clock standards set by the ITU (who
defines UTC)

A "complete" solution would have several properties:

- it would always indicate the correct UTC time
- it would calculate time differences accurately

There's no clear reason why that solution can't be split into parts,
e.g., using Unix time to calculate time differences and a (complex)
converter to deal with UTC leap seconds.

Joe