Re: [Ntp] Is one refid enough

Heiko Gerstung <heiko.gerstung@meinberg.de> Thu, 05 September 2019 10:52 UTC

Return-Path: <heiko.gerstung@meinberg.de>
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 572CE120090 for <ntp@ietfa.amsl.com>; Thu, 5 Sep 2019 03:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.289
X-Spam-Level:
X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de
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 YhiiFsEHJIQk for <ntp@ietfa.amsl.com>; Thu, 5 Sep 2019 03:52:08 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F31120045 for <ntp@ietf.org>; Thu, 5 Sep 2019 03:52:07 -0700 (PDT)
Received: from srv-kerioconnect.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id A177F71C035B; Thu, 5 Sep 2019 12:52:03 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de A177F71C035B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1567680726; bh=w7eJ++PIv04jW+lxjuo1xNkXcJeC9eRiYcDp4XvNI4g=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=E22U8cx4Ct6hUOdKG6aM3gje1SC3lsZIzRIUMjkksIYJ2MWePaw7dsviiUWDAZu+C 2WDO8DzXXKpv+CXBNR2Pj7gYZdw2cVbt61UtHJ3nd3B2SZXk36eUHiXtzmVQfMidxA 6TrZJjz8070gMuc6MQkgFIiDXIHgT7/QdrLb4AgE=
X-Kerio-Anti-Spam: Build: [Engines: 2.15.9.1266, Stamp: 3], Multi: [Enabled, t: (0.000006,0.007663)], BW: [Enabled, t: (0.000007)], RTDA: [Enabled, t: (0.027860), Hit: No, Details: v2.7.55; Id: 15.1i61edk.1dk0gqt2u.14dsf], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Thu, 5 Sep 2019 12:52:00 +0200
Message-ID: <4279C9FF-DEF9-42D3-838A-E344307BFF88@meinberg.de>
Thread-Topic: [Ntp] Is one refid enough
References: <CACsn0c=0VFPtYHkQnyjaukK3-TBS60J=cZ0LM1hVkuZg3yLG_Q@mail.gmail.com>
In-Reply-To: <CACsn0c=0VFPtYHkQnyjaukK3-TBS60J=cZ0LM1hVkuZg3yLG_Q@mail.gmail.com>
Mime-version: 1.0
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+YzFjYmQ2YTFmYzhlZTJlMQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Watson Ladd <watsonbladd@gmail.com>, NTP WG <ntp@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.3 at server1a
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/PKJBL4Wkjx3XqIUMIFBUWWHgRdE>
Subject: Re: [Ntp] Is one refid enough
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: Thu, 05 Sep 2019 10:52:11 -0000

Hi Watson,


> On 05.09.19, 06:54 "ntp im Auftrag von Watson Ladd" <ntp-bounces@ietf.org
> im Auftrag von watsonbladd@gmail.com>; wrote:
> 
> Dear all,
> 
> On thinking about some of the discussion that emerged that came
> from refids I've come to the conclusion that some of the uses people
> are imagining for a complete chain aren't actually going to work,
> and we might not even need any refid. Note that my experience in this
> area is minimal: this should be more a suggestion of conversation then
> taken extremely definitively.
> 
> The first use put forward was for redundancy: one would gather
> intermediate sources until enough root sources were gathered.
> But this isn't actually a reflection of the reliability: the NTP environment
> is a graph, and the stratum 1 sources are the roots of a dynamically
> created spanning tree. In particular if we have two stratum 1
> sources A and B, and two intermediates C and D, then if both C and D
> are using both A and B then there is full redundency, even if both have
> better connectivity and thus use A to synchronize with.

The InstanceID idea would help if a client is configured to use multiple sources and wants to avoid all of them getting their time from GPS (maybe over several stratum levels), if other sources like Galileo or Glonass etc. are available as well. Think about a client resolving 4 pool servers and asking all of them where their time originally comes from. If all of them lead back to the same source (GPS), the client can decide to resolve more pool servers in order to find a set of 4 servers that offers some diversity. Or, it detects that in the original set of resolved IP addresses, two get their time from the same stratum 1 server, allowing the client to discard one of them and find another in the pool that gets its time from a different upstream source.

> The second use was for preventing loop formation: by excluding
> a source that has synchronized to you, this prevents loops. Let's
> take a simple example: A and B are two stratum 1 sources, C and D take
> from A and B respectively, and are peered. 
> Because A is so much more stable C synchronizes to it, and D synchronizes to C. Now assume that
> A goes down. What should eventually result is C synchronizing with D
> and D synchronizing to B. The question of which mechanism between using
> reference IDs and accumulating errors/stratum will work better
> is not obvious: it seems to me that not using reference IDs works just
> fine in this example and provides faster recovery: C can synchronize
> to D immediately as it is the best surviving timesource, and the error
> accumulation eventually means D prefers B (in practice quite
> quickly) vs. waiting for C to drift enough for D to switch before synchronizing
> to D.

Peering is a thing that I do not see being used very often with our customers. I did not consider peering in my thoughts about the "chain" so far, because I typically see more or less tree-like sync hierarchies. 

> As I mentioned above I'm not that experienced in this part of NTP and
> would appreciate any corrections on matters I may have misunderstood.

I would expect that a loop in NTP is typically prevented by the stratum level mechanism, if you never accept an upstream server having the same or a higher stratum level than yours, you should not be able to create a loop anyway. I therefore would accept that the refID itself is not required to prevent sync loops, no matter of which degree.

if A Is stratum 1 and A->B->C->D then B would never choose D because it is stratum 4 and B itself is stratum 2. 

Having a chain of unique InstanceIDs would still be useful because of the first use case. It would also help to find out if two servers A and B are actually the same device with two IP addresses and maybe even network connections. 

> Sincerely,
> Watson Ladd

Best Regards. 
   Heiko



> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 heiko.gerstung@meinberg.de 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung