Re: [Ntp] Symmetric mode

Danny Mayer <mayer@pdmconsulting.net> Sat, 24 September 2022 22:02 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 A8029C14CE2E for <ntp@ietfa.amsl.com>; Sat, 24 Sep 2022 15:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level:
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 8-ukXbThr0uL for <ntp@ietfa.amsl.com>; Sat, 24 Sep 2022 15:02:09 -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 4C848C14F747 for <ntp@ietf.org>; Sat, 24 Sep 2022 15:02:00 -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 4MZjfb55b4zMNbj; Sat, 24 Sep 2022 22:01:59 +0000 (UTC)
Message-ID: <d873ef9f-6d91-e45a-0ad8-25e43682173a@pdmconsulting.net>
Date: Sat, 24 Sep 2022 18:01:58 -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: Hal Murray <halmurray@sonic.net>, "ntp@ietf.org" <ntp@ietf.org>
References: <mayer@pdmconsulting.net> <796c33e6-02dc-0665-c8a2-a143f9100bdd@pdmconsulting.net> <20220919024614.4AB8328C1E2@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <YygwAeTMeSHXXk6t@localhost> <880b8ec4-e112-e2e2-f48c-c940064bc749@pdmconsulting.net> <YyrL1izKeIZWhkIA@localhost>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <YyrL1izKeIZWhkIA@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/dadGz3GCrpmD_cZOBg1Yr2Hgyag>
Subject: Re: [Ntp] Symmetric mode
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: Sat, 24 Sep 2022 22:02:20 -0000

On 9/21/22 4:31 AM, Miroslav Lichvar wrote:
> On Tue, Sep 20, 2022 at 09:41:38AM -0400, Danny Mayer wrote:
>> On 9/19/22 5:01 AM, Miroslav Lichvar wrote:
>>> It's not very useful. I think the most interesting thing about it is
>>> that sources using the symmetric mode are marked differently in tools
>>> like ntpq, so it's more obvious to the admin that synchronization can
>>> work in both directions.
>> It's extremely useful, particularly when you end up in orphan mode or just
>> need to make sure that all systems in the local network are synchronized.
> You said that before. If there is doubt, you need to provide some
> evidence. This is not a debate on TV where repeating something over in
> an authoritative voice would change someone's mind.
This is not a TV show. Please stop.
>
> You claim that something exists, that there is something special about
> symmetric mode with respect to orphan mode or source selection in
> general. That's easy for you to prove that. You just need to point to
> an exact location in the source code or RFC and we can easily confirm
> if that is true.

I have pointed you to papers and documents by Dave Mills. You have 
access to the source code and you can run it in a debugger and examine 
the logs. If you say that the source code is opaque, I won't disagree 
with you, at times it takes me a while to understand what it's doing.

Symmetric Mode has it's uses and while that use is most useful on a LAN 
you can use it on the wider WAN. I know of someone using symmetric peer 
mode in exactly this way across the internet. I cannot provide a name as 
I am not authorized to do so, not that it is important here.

I have provided you with examples of why it's useful. You can agree or 
disagree with it and say why but the NTP Reference implementation code 
has been running that mode for over 20 years.

Someone made a claim that it uses more packets than client/server modes, 
but that's not true either, something that can be easily verified by 
running the code and looking at the packet traffic.

>
> I claim that there is no such thing, that there is no difference
> between selection of sources using the client/server mode and
> symmetric mode.
Right because it's just one more component of the data being analyzed by 
the algorithms. If another server provides better data than the 
symmetric mode then that's what becomes the chosen server. Symmetric 
mode doesn't replace client/server modes, it's just another mode and all 
modes are considered in the selection algorithms, including broadcast 
and multicast.
> It's much more difficult for me to prove that
> something doesn't exist. I can point to the source code where I'd
> expect it to be, like this location in the clock_select() function
>
> https://fossies.org/linux/misc/ntp-4.2.8p15.tar.gz/ntp-4.2.8p15/ntpd/ntp_proto.c#l_3531
>
> where I don't see anything checking the mode (MODE_SERVER vs
> MODE_ACTIVE/MODE_PASSIVE), but that doesn't mean this distinction
> couldn't be hidden somewhere else.
>
> It's up to you to prove that it exists.
>
No, I've already done that. See the running code. I have no idea what 
you mean by exists since it's in the reference implementation code.

Danny