Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

Miroslav Lichvar <mlichvar@redhat.com> Wed, 02 June 2021 07:38 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 A55253A392D for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 00:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 PqxoGFShooZh for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 00:38:53 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.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 370F23A392E for <ntp@ietf.org>; Wed, 2 Jun 2021 00:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622619532; 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=iqvVj0213IsbjoIKfi3orv5hUgWLk9g9P6vg805E74o=; b=FXuvNdpVA0f1teN5hivMz4Q9q1NniGyVKXOJ2wpe2C85xDyu3idZUXUBTsukyveBucht3v YRSOpVyAKttY47O0EbMF3sI6kgACa2Iz0AzlmVirqoRgBoBzuTX+1vLtxWhgUcrjbxYAAs PPOMA5rwYqGzFyC4RYghngk8xWdKerU=
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-267-A966Fh7RNICmrC90tMeHcQ-1; Wed, 02 Jun 2021 03:38:47 -0400
X-MC-Unique: A966Fh7RNICmrC90tMeHcQ-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D1995106BB37; Wed, 2 Jun 2021 07:38:44 +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 B59BE5D769; Wed, 2 Jun 2021 07:38:42 +0000 (UTC)
Date: Wed, 02 Jun 2021 09:38:41 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Danny Mayer <mayer@pdmconsulting.net>
Cc: Daniel Franke <dfoxfranke@gmail.com>, Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>, NTP WG <ntp@ietf.org>
Message-ID: <YLc1gS3vdTlP2mOv@localhost>
References: <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost> <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de> <YLZVS4jwGOnMIk6g@localhost> <8f89741a-dd69-e688-5954-f222ab7652ac@pdmconsulting.net> <CAJm83bDf0966xLo2sXfg5jwN7yVZkVx1z8dNT-NW-dE3XdA4LQ@mail.gmail.com> <084b1615-9f01-ebc7-62d4-df1bd95820c1@pdmconsulting.net> <CAJm83bDk5=KNkB9=nkQSPHSNbMdYGEKTTi291JYr7F8+fL3rcw@mail.gmail.com> <cbc8973a-9f11-4080-f1a5-decc83e7ea45@pdmconsulting.net>
MIME-Version: 1.0
In-Reply-To: <cbc8973a-9f11-4080-f1a5-decc83e7ea45@pdmconsulting.net>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
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/rXOj73U6la2vybiuSLzCJbLyc1w>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 02 Jun 2021 07:38:57 -0000

On Tue, Jun 01, 2021 at 02:48:59PM -0400, Danny Mayer wrote:
> That ignores the fact that you are bombarding the servers with requests at a
> very high rate. There's a very good reason why we implemented KOD packets.
> You wouldn't want to put any of those responses through a filter.

We are not talking about public servers here. These are protected
networks designed for highly accurate synchronization, where each link
has hardware timestamping on its ends and the jitter is on the order
of nanoseconds. With a 1000x smaller jitter you need a 1000x shorter
polling interval to fully take advantage of it, assuming everything
else is the same.

The server doesn't care if it has 100 million clients polling once per
1000 seconds, or 1000 clients polling 100 times per second. The load
is the same.

Of course, there is always a possibility that someone misconfigures
the client and floods a public server. There are safety mechanisms
that can be implemented to make that less likely. For example, chrony
doesn't switch to a sub-second polling interval unless the measured
peer delay is smaller than 10 milliseconds.

-- 
Miroslav Lichvar