Re: [Ntp] NTS Pools

David Venhoek <> Fri, 01 March 2024 09:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B2F5C151545 for <>; Fri, 1 Mar 2024 01:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OGHLbRgySQo8 for <>; Fri, 1 Mar 2024 01:25:38 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 0BC8AC18DB94 for <>; Fri, 1 Mar 2024 01:25:36 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a44628725e3so180195166b.0 for <>; Fri, 01 Mar 2024 01:25:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1709285134; x=1709889934;; 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;; 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: <> <Zdx0Nst2_w1mEMKG@localhost> <> <> <ZeBPl6e3WagHW1z4@localhost>
In-Reply-To: <ZeBPl6e3WagHW1z4@localhost>
From: David Venhoek <>
Date: Fri, 01 Mar 2024 10:25:23 +0100
Message-ID: <>
To: Miroslav Lichvar <>
Cc:, NTP WG <>,,, Rainer Bermbach <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] NTS Pools
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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