Re: [Ntp] Warren Kumari's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

Miroslav Lichvar <mlichvar@redhat.com> Tue, 29 June 2021 08:36 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 BF3E33A2B41 for <ntp@ietfa.amsl.com>; Tue, 29 Jun 2021 01:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level:
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wclelwqnkzxm for <ntp@ietfa.amsl.com>; Tue, 29 Jun 2021 01:36:37 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BC93A2B3E for <ntp@ietf.org>; Tue, 29 Jun 2021 01:36:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624955796; 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=1+obn6Yjt+3R51Kx7ghDXHSWQCy350nyQJJ+rsRHFdw=; b=gP+9CRsnQQuXBcoapC0ZgCHc3IFZkor2OJkUgeKpypBYJxlV96h1afanrNrwR48yuv+T8d N+wjvoEPKpgrlQBu5ZKd4NWLWN8hqeDfqKWP1nc6j4sNc3uDh6UXCgB99dpL2ggO/1Lj5a qP6Jxm4S6xGXV9V9+SCZfXHWm19bXhg=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-318-7upqD-ZCNsu6Rvv73uxjrw-1; Tue, 29 Jun 2021 04:36:32 -0400
X-MC-Unique: 7upqD-ZCNsu6Rvv73uxjrw-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3830B801F97; Tue, 29 Jun 2021 08:36:31 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E9A7F60843; Tue, 29 Jun 2021 08:36:29 +0000 (UTC)
Date: Tue, 29 Jun 2021 10:36:28 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Warren Kumari <warren@kumari.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ntp-interleaved-modes@ietf.org, ntp-chairs@ietf.org, ntp@ietf.org, odonoghue@isoc.org
Message-ID: <YNrbjCDF4/609dg/@localhost>
References: <162489367509.31114.17922898118876978467@ietfa.amsl.com>
MIME-Version: 1.0
In-Reply-To: <162489367509.31114.17922898118876978467@ietfa.amsl.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
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/dzZ6W5oPaFS1lMCtNdFgWj8FAPw>
Subject: Re: [Ntp] Warren Kumari's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 29 Jun 2021 08:36:40 -0000

Thanks for the review.

On Mon, Jun 28, 2021 at 08:21:15AM -0700, Warren Kumari via Datatracker wrote:
> So, are there in fact "multiple implementations of the document."?

There are two widely-used implementations that support some of the
interleaved modes: ntp (from ntp.org) and chrony. There are few other
implementations I saw, but those were rather experimental. FWIW, a
minimalistic one is included as a proof-of-concept in the repository
of the draft [1].

The first ntp version marked as stable with this feature was 4.2.6p1
released in 2010. It implements the symmetric mode and broadcast mode.
The draft has some requirements that this implementation doesn't
follow yet. This causes problems when the polling intervals of the
peers don't match, even when it is interoperating with itself. Other
than that it interoperates with chrony, even as a client, although
that doesn't seem to be officially supported.

The first chrony version was 3.0 released in 2016. It added the
client/server mode and symmetric interleaved modes. The server support
is enabled by default.

> Has there
> been interoperability testing to confirm that there are no backwards
> compatibility issues?

Yes, it has, quite extensively.

There is a large number of public NTP servers that have the server
support enabled. I have also captured and analyzed terabytes of NTP
traffic on several public servers in different regions to confirm that
it doesn't break any existing implementations.

There was only one implementation that had an issue and that was a
fork of ntp that had partially removed support for the interleaved
mode. It basically had the xleave option permanently set, but it was
no longer able to process an interleaved response, which caused the
protocol to switch between the two modes. IIRC it still synchronized,
but used only every second or third response. Obviously, this wouldn't
happen if the implementation didn't already support the interleaved
mode at some point in its history and it could still happen even if
the protocol used a different mechanism to switch between the modes.

> Much of the document feels somewhat hand-wavy regarding
> the compatibility with existing implementations, as well as in things like:
> "The client SHOULD limit the number of requests in the interleaved mode between
> server responses to prevent processing of very old timestamps in case a large
> number of consecutive requests is lost." -- SHOULD limit to what number? 1? 3?
> 17?

That is an implementation detail with no impact on interoperability.
For different implementations different values might work better
depending on how they control the clock and filter measurements etc,
so I'd rather not suggest any specific values.

> When the document says things like:
> "A peer A SHOULD send a peer B a packet in the interleaved mode only when the
> following conditions are met:" I'm assuming that this means "only when the
> **all** following conditions are met:"? If so, it needs to be explicit.

Ok, I'll fix that.

> To be clear, when the document says:
> "1.  The peer A has an active association with the peer B which was
>        specified with the option enabling the interleaved mode, OR the
>        peer A received at least one valid packet in the interleaved mode
>        from the peer B."
> 
> If "peer A has an active association with the peer B which was **not**
> specified with the option enabling the interleaved mode" and "peer A receive[s]
> at least one valid packet in the interleaved mode from the peer B." should it
> enable interleaved mode?

Yes, it should.

> How is an operator supposed to know if they should
> enable this mode when talking to a peer?

They are expected to know whether the peer supports it. Or they can
try it and see if it works. Symmetric mode is typically used in local
networks.

> As far as I can tell, this adds a significant amount of state keeping to server
> implementations. The document does somewhat mention this ("A server which
> supports the interleaved mode needs to save pairs of local receive and transmit
> timestamps.  The server SHOULD discard old timestamps to limit the amount of
> memory needed to support clients using the interleaved mode."), but it seems
> like this is a fairly large change, and this bit of text doesn't really cover
> the state requirements.

I think that is an implementation detail. The only requirement from
the protocol point of view is that server is able to keep at least one
pair of timestamps across requests. It can keep as many of them as it
likes and it can drop them at any time for any reason. A minimal
implementation would be a fixed-size hashtable, overwriting old
timestamps with new ones as they come. No additional state is
required.

[1] https://github.com/mlichvar/draft-ntp-interleaved-modes

-- 
Miroslav Lichvar