[Ntp] Is one refid enough

Watson Ladd <watsonbladd@gmail.com> Thu, 05 September 2019 04:52 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7C5BC120074 for <ntp@ietfa.amsl.com>; Wed, 4 Sep 2019 21:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LvgKEq_lP45G for <ntp@ietfa.amsl.com>; Wed, 4 Sep 2019 21:52:54 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 73010120033 for <ntp@ietf.org>; Wed, 4 Sep 2019 21:52:54 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id l11so815731lfk.6 for <ntp@ietf.org>; Wed, 04 Sep 2019 21:52:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xzFh9TRweJcUjCNPo+Z1hDiUCcM8NK6t+/hqQ4awGiM=; b=VR1ezdMuglwOXdBNkGR5gntEOKa+nzwztRLZbGzPWna8AJt0OQ486WLy5ko5HERmtO xzCs3cRl7m0Yh3kTyfBnS/NV1Ej4JQlJjAYGuyBnfzTxm1Q6COSThiX3zZu0S1GlFY/T ZV+hCgdP7TPIsA/ZUU5AdfsmQ1pFFd1oiPXf8QH+5b1Vb6iGrgRhghXY1FK+rBv5CxBL xvV3QtyMaeFI7Hp0xPCcLcDsFtZo2GNWp7KgKYsz9ALJRybNeUsQXy8AwecUwyVNp+3+ dK6mXb1Z8k3OojxcbxyNL1Qeq2JP3lKwH4AMOFRiG1t4QOy2kx1gW8DbJ1u5+N2ss4xx cqow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xzFh9TRweJcUjCNPo+Z1hDiUCcM8NK6t+/hqQ4awGiM=; b=e9hwqLjqSA9L0uw69EwCxXx5mmhfLqgH3XnEeJ8g8kHjCh2odmbOfLZrsq0tMFZ1BJ Dna+5gBv+JuCdQDX3LRrmaUPm/nOnaEtPfJ5LE8du7PZqtEipPUHzka4lkq4DupNbynL uIrR0aim/34ucYyOfF4tZ+2DV6pJN5gfNih55Xg/ac+cfIk0oyAdnBOkZfC8JaSWaepP PiBIMIA8uwFPHc65AZqIOydi0pTQD/pOPfMTmiiHN8DF/EAPJYg1aDyuQW8ks2eH1L9V bSNtXgfUsfc8+dYhyIYu3rb4XOx+zTUbBCsADTe9vTtbZrFM03IO+fzx04yQ/3PStUKT BWKA==
X-Gm-Message-State: APjAAAVOy8SpVRZClvPAzOzLy6L5Sz8L0dRfat6PiEzkJdja4FMA5QWH 62axOzYyXV7lwFuc6lotcnSPPfiPdFCNqDl+u8yf55Ms
X-Google-Smtp-Source: APXvYqyf0BioTzT6CPhAW1yOjxlNy2k3P+nMYKi6bcw1TNx5UuMg/v4ePbm60XriM+g5vXWQpzKDE5BvLAIK5W7lyEs=
X-Received: by 2002:ac2:562c:: with SMTP id b12mr959157lff.156.1567659172265; Wed, 04 Sep 2019 21:52:52 -0700 (PDT)
MIME-Version: 1.0
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 4 Sep 2019 21:52:40 -0700
Message-ID: <CACsn0c=0VFPtYHkQnyjaukK3-TBS60J=cZ0LM1hVkuZg3yLG_Q@mail.gmail.com>
To: NTP WG <ntp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/R7kr9Fxsh07eYdHnW59D5ZJXgyY>
Subject: [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 04:52:57 -0000

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 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.

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.

Watson Ladd