Re: [Ntp] NTPv5 Loop Detection without Stratum - Why do we want this?

Danny Mayer <mayer@pdmconsulting.net> Wed, 07 September 2022 18:50 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 2C402C15338F for <ntp@ietfa.amsl.com>; Wed, 7 Sep 2022 11:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.108
X-Spam-Level:
X-Spam-Status: No, score=-6.108 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, RDNS_NONE=0.793, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=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 WEbidsixbXO9 for <ntp@ietfa.amsl.com>; Wed, 7 Sep 2022 11:50:34 -0700 (PDT)
Received: from chessie.everett.org (unknown [IPv6:2001:470:1:205::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 AFFDCC15258A for <ntp@ietf.org>; Wed, 7 Sep 2022 11:50:28 -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) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4MNBCN5LgYzMQ4X; Wed, 7 Sep 2022 18:50:24 +0000 (UTC)
Message-ID: <aba44bbc-2204-735e-daff-a29a59dac9da@pdmconsulting.net>
Date: Wed, 07 Sep 2022 14:50:23 -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: Miroslav Lichvar <mlichvar@redhat.com>
Cc: kristof.teichel=40ptb.de@dmarc.ietf.org, "ntp@ietf.org" <ntp@ietf.org>, Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
References: <DA1F1664-8A84-4197-844A-CA7E8DAA36B8@meinberg.de> <OF43150191.DABAA331-ONC12588B5.00362DC0-C12588B5.003861AF@ptb.de> <YxckOm2+TD3tTPN4@localhost> <7d7f0656-2fd2-b781-4913-526a4be8cb62@pdmconsulting.net> <Yxg4Cba58hI/aPKw@localhost>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <Yxg4Cba58hI/aPKw@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/sqhDL4_gVm2T7eP1IEWtvSLm8x0>
Subject: Re: [Ntp] NTPv5 Loop Detection without Stratum - Why do we want this?
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: Wed, 07 Sep 2022 18:50:37 -0000

On 9/7/22 2:19 AM, Miroslav Lichvar wrote:
> On Tue, Sep 06, 2022 at 07:29:18PM -0400, Danny Mayer wrote:
>> On 9/6/22 6:43 AM, Miroslav Lichvar wrote:
>>> There will be a loop, but it will terminate after several rounds due
>>> to some server reaching the maximum stratum (currently 16), which will
>>> not be acceptable by the client.
>> You won't get that far. The server tries to select the best quality source
>> of timestamps and uses that until another better quality source becomes
>> preferred.
> If stratum comes from the best sourcea and the loop is not over the
> best source, then stratum won't terminate the loop.
>
> If stratum came from the maximum from all selected sources, it would
> always terminate the loop, but I think it would lead to unstable
> selection. We can experiment with that.
Only one source is selected at a time so this makes no sense.
>
>>> Stratum cannot prevent loops unless we don't allow clients to select a
>>> server with a higher stratum (as it was in NTPv3). It can only
>>> terminate them and it doesn't prevent them from happening again.
>> That's a bad idea. Symmetric peers may be at the same stratum and that's
>> okay especially if you get to orphan state.
> In orphan mode stratum is interpreted differently. Symmetric mode or
> client/server mode makes no difference.
There is no symmetric mode for client/server. A client is by definition 
one stratum value larger than the server. Peers can have the same stratum.
>
>>> I'd not agree with that. Stratum doesn't indicate accuracy. It depends
>>> on the reference clocks used by primary servers and network paths between
>>> the servers.
>> I'm not sure what the stratum-1 servers have to do with this. The network is
>> far more important when choosing a preferred source.
> If a local stratum-1 server had a poor reference clock (e.g. a GPS
> receiver without PPS), it would be better to use a distant server with
> higher stratum, i.e. stratum doesn't say much about accuracy.

Then it wouldn't be a stratum-1 server any more.

Danny

>