Re: [Ntp] NTS Pools

David Venhoek <david@venhoek.nl> Fri, 01 March 2024 09:25 UTC

Return-Path: <david@venhoek.nl>
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 3B2F5C151545 for <ntp@ietfa.amsl.com>; Fri, 1 Mar 2024 01:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venhoek-nl.20230601.gappssmtp.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 OGHLbRgySQo8 for <ntp@ietfa.amsl.com>; Fri, 1 Mar 2024 01:25:38 -0800 (PST)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 0BC8AC18DB94 for <ntp@ietf.org>; Fri, 1 Mar 2024 01:25:36 -0800 (PST)
Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a44628725e3so180195166b.0 for <ntp@ietf.org>; Fri, 01 Mar 2024 01:25:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venhoek-nl.20230601.gappssmtp.com; s=20230601; t=1709285134; x=1709889934; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KEJK57fMp5OYBbH2dW3AUCH4EXO4GSH2JVWU+EcLYAw=; b=2uAkbgdvC8a0ePgk27H22QNsFr4UhlUY6Tve4L9yBzo8TYlpEMtGWsGcKgOzpRrNEG sRi7pq47ylZ9W/a55ZGl79srXjn+PRlKBAvdSJVA0EdGIx5E1x+cCa+1/dYfhYwSSMIW otCuqCyMoW2M/JXDoCcLoNbMh5A3qksuOatKK41UtyZlKnu8TdaH8A4jDu4T7v5BMA5d zDMUx71dPeU1ruNyivXRB6uSoS7qX8qjPEdcvgICOmhk8HXpSi65FSW67iI2CSDFcI7M ygdf6Z5HT6HqLn+P/2eE4bx7zo8bnfAVhskUXu8kIeeMtguR78g2EogXyO+0Puf5+3Xy DToQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709285134; x=1709889934; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KEJK57fMp5OYBbH2dW3AUCH4EXO4GSH2JVWU+EcLYAw=; b=jaPT53LTKVZLJZeCZpvwdatxM/XEwUa/Buqyr16UpJ65VpI77fKj1WSa8AlqDryMn7 ETMcq+EHYr7JKwGTxVZVvQQgI4L3qJLkLhQCxY6DMgQIoFt+hwCzhKkZM4a0ybOXx0/g 1aI/qoHi2fNVReglPMTsxjCg2toEK74u1uMIDut5h/zZA0GcaFiJsG31z92yJxmxALaI fV+msQKkgknHVSArIrEJ3LDnMOpKzo+k5W0bjCkhuYLNfLcb5ZZrOO3vUULcpZCxLcMl pN5c+oE+P/UO+BZrG6E1uG5wTrZCn3oTFSS8fMSU0N1ktUizyTkYg83/OuYNYu5Gto9M 7kcQ==
X-Forwarded-Encrypted: i=1; AJvYcCUVX74pjG2u1sLoBSPR17EP3ljlcLNQcCwts4ab6vx2HEZ+NlRIxbapFukGz8gub6j+FnVOfeSchrmmHyo=
X-Gm-Message-State: AOJu0YyPwV4ido5WQ5jzEeMyao3KGs4Fh+xHlxFwEpmDoDoJnHB6UXXc RoMkMfZSPvCA2aVKyCH6rjoD1NYYCMPoJTzYMZ/j7weZJ0EaIz/cXF2H/9X/UUQYDwl16jbd78l W11Sd1xl2ZhSaP13pAnUrnBJ3v2BnnvlURWwBaQ==
X-Google-Smtp-Source: AGHT+IGv2c294SOe/+kb9WAKmZdr9SLzgYV1CKi3yZC7aT9bNC+LD4vFKGlhZivd+wPxxjgiP3QBRb/vxbenSsKasy8=
X-Received: by 2002:a17:906:3e0d:b0:a43:a4a1:1945 with SMTP id k13-20020a1709063e0d00b00a43a4a11945mr822306eji.75.1709285134415; Fri, 01 Mar 2024 01:25:34 -0800 (PST)
MIME-Version: 1.0
References: <OF2E6B0FFD.229AD710-ONC1258ACB.004EFEAA-C1258ACB.0050896E@ptb.de> <Zdx0Nst2_w1mEMKG@localhost> <CAPz_-SUSEDaFgfwvnm_FQ5M9jjAAp2Df3A7RTuYY2KPmSq5FkQ@mail.gmail.com> <CAPz_-SWTbMmkXc5SnJjehFBKqO4UugSh5SOLWnQX2BEhSZAqkg@mail.gmail.com> <ZeBPl6e3WagHW1z4@localhost>
In-Reply-To: <ZeBPl6e3WagHW1z4@localhost>
From: David Venhoek <david@venhoek.nl>
Date: Fri, 01 Mar 2024 10:25:23 +0100
Message-ID: <CAPz_-SW7oDFAvzMyOWj8PPyRJooj68WAEu63pjLJue_kbFLTWA@mail.gmail.com>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: martin.langer=40ptb.de@dmarc.ietf.org, NTP WG <ntp@ietf.org>, Dieter.Sibold@ptb.de, Kristof.Teichel@ptb.de, Rainer Bermbach <r.bermbach@ostfalia.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/fguSaq-I1mq1cwZMstGepCW3b70>
Subject: Re: [Ntp] NTS Pools
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: Fri, 01 Mar 2024 09:25:41 -0000

Dear Miroslav,

For now, I think we just have to agree to disagree on that point. Yes,
the approach I intend to experiment with is computationally a lot more
expensive than the current pool, and it may very well be that
eventually this turns out to be a sufficiently large issue to kill the
idea. However, I think it should be doable and believe there are
sufficient advantages as setting up time servers around the world with
good quality time is also a significant challenge.

Kind regards,
David Venhoek

On Thu, Feb 29, 2024 at 10:34 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
>
> On Thu, Feb 29, 2024 at 09:35:05AM +0100, David Venhoek wrote:
> > Rationale for the NTS-KE load balancer approach:
> > Given these goals, I myself find the NTS-KE load balancer approach the
> > most attractive. Requirement 1 limits the options to either Shared
> > domain name, NTS-KE generating cookies or NTS-KE load balancer.
>
> The trouble with the load balancing approach is that it's not
> practical, at least I still don't see a good use case for it.
>
> As your table shows, the computational cost of load balancing is
> higher than the cost of the load-balanced service itself. It's better
> to use all resources to serve NTS-KE and NTP directly. It's simpler,
> and provides better performance. With or without load balancing, the
> servers to which clients are making TLS connections need to share the
> hostname.
>
> --
> Miroslav Lichvar
>