Re: [Ntp] Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum

Danny Mayer <mayer@pdmconsulting.net> Mon, 05 September 2022 19:46 UTC

Return-Path: <mayer@pdmconsulting.net>
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 95B18C15258C for <ntp@ietfa.amsl.com>; Mon, 5 Sep 2022 12:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHMA9mibMERy for <ntp@ietfa.amsl.com>; Mon, 5 Sep 2022 12:46:51 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F984C14CF1C for <ntp@ietf.org>; Mon, 5 Sep 2022 12:46:51 -0700 (PDT)
Received: from [192.168.1.156] (pool-108-26-202-2.bstnma.fios.verizon.net [108.26.202.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4MLzYP645vzMPsQ; Mon, 5 Sep 2022 19:46:49 +0000 (UTC)
Message-ID: <e0d5c4fb-78e0-6a7c-0e7b-4b1ee6aace0c@pdmconsulting.net>
Date: Mon, 05 Sep 2022 15:46:49 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: Hal Murray <halmurray@sonic.net>, David Venhoek <david@venhoek.nl>
Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, Heiko Gerstung <heiko.gerstung@meinberg.de>, mlichvar@redhat.com, "ntp@ietf.org" <ntp@ietf.org>
References: <20220830205143.DFDC328C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <20220830205143.DFDC328C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/RMqgz-xeSCWEXXdVKmdNhtj8jgo>
Subject: Re: [Ntp] Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <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: Mon, 05 Sep 2022 19:46:53 -0000

On 8/30/22 4:51 PM, Hal Murray wrote:
> david@venhoek.nl said:
>> No, the loop avoidance algorithm only rejects a source if that source depends
>> on the node itself. So, when having 4 servers A B C and D, if server A is a
>> stratum 1 server, and servers B and C sync to server A, server D can still
>> use all of A,B and C to synchronize. However, suppose it uses all 3, then at
>> that point, it will no longer be accepted as a potential time source by node
>> B or C, because these then see they were part of the source of D, and
>> therefore reject.
> That brings up an interesting point.
>
> What does loop mean?
>
> The draft for NTPv5 is only the wire protocol.  It doesn't cover what goes on
> inside a server.  If a server latches on to the best upstream server and only
> uses any others for checking, then the topology is simple and loop would be
> easy to define.
>
> Is that a reasonable assumption?  Do we need a section in the draft to collect
> assumptions about the internals of servers?
NTP is not just about the on-wire protocol. The analysis and the 
algorithms within the server are integral parts of NTP. I have no idea 
what you think are the assumptions in the internals of servers.
> Consider the alternative where a server does some sort of weighting on the use
> of its upstream servers.  What does stratum mean?  Is loop well defined?
>
> ------
>
> Do we want 2 different client/server packet modes/formats?  One for
> leaf-clients (SNTP) and another for the client side of servers?  Or maybe the
> same packet format but different descriptions of the way fields are used.
>
> Or maybe even 2 separate RFCs.  The idea being that SNTP will be much easier
> to understand and we can target it for a longer lifetime.  In particular, it
> wouldn't have to say anything about loop detection.
>
The only real difference between NTP and SNTP is that a SNTP client is 
not a server and does not provide NTP packets to another system.

Danny