Re: [Ntp] Symmetric mode

Miroslav Lichvar <mlichvar@redhat.com> Wed, 21 September 2022 08:31 UTC

Return-Path: <mlichvar@redhat.com>
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 137B4C14F73A for <ntp@ietfa.amsl.com>; Wed, 21 Sep 2022 01:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.675
X-Spam-Level:
X-Spam-Status: No, score=-7.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 1_xzBoaPImej for <ntp@ietfa.amsl.com>; Wed, 21 Sep 2022 01:31:26 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 EDF2BC14F74C for <ntp@ietf.org>; Wed, 21 Sep 2022 01:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663749084; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PvZZQKPRZgXxkCw2v+OTYu/7tKbVpKgRNnjdeD4Qaxw=; b=CVp1QF/+Oa2Bv88TGp9tgQ2O9sYQkiYaiAgoro1hmi9c6L5ETDj0f9wMt3Zo9Q5r6wv33O ashyLDze90OojgJhctR2RTXTNQ7fG+7HrKzM4Cw/n+qa262/Lp8RRpu8a1B/KrcsTQalgR zk88yMR2iJ2ctkx9otf8d4artyasqrQ=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-398-1pO6bDlOMVGeGQPTMpYe3A-1; Wed, 21 Sep 2022 04:31:21 -0400
X-MC-Unique: 1pO6bDlOMVGeGQPTMpYe3A-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D2DAA185A7A3; Wed, 21 Sep 2022 08:31:20 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6ABE1C15BAB; Wed, 21 Sep 2022 08:31:19 +0000 (UTC)
Date: Wed, 21 Sep 2022 10:31:18 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Danny Mayer <mayer@pdmconsulting.net>
Cc: Hal Murray <halmurray@sonic.net>, "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YyrL1izKeIZWhkIA@localhost>
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>
MIME-Version: 1.0
In-Reply-To: <880b8ec4-e112-e2e2-f48c-c940064bc749@pdmconsulting.net>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-GGPHstm6WZygTkeFsOQv5Y0zcU>
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: Wed, 21 Sep 2022 08:31:30 -0000

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.

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 claim that there is no such thing, that there is no difference
between selection of sources using the client/server mode and
symmetric mode. 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.

-- 
Miroslav Lichvar