Re: [Ntp] NTPv5 and anycasting

Philip Prindeville <philipp@redfish-solutions.com> Thu, 03 December 2020 19:17 UTC

Return-Path: <philipp@redfish-solutions.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 136E63A07D1 for <ntp@ietfa.amsl.com>; Thu, 3 Dec 2020 11:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fDUzVuSe1KPu for <ntp@ietfa.amsl.com>; Thu, 3 Dec 2020 11:17:48 -0800 (PST)
Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [45.33.216.244]) (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 CA8FB3A07B3 for <ntp@ietf.org>; Thu, 3 Dec 2020 11:17:48 -0800 (PST)
Received: from [192.168.3.4] (174-27-182-34.bois.qwest.net [174.27.182.34] (may be forged)) (authenticated bits=0) by mail.redfish-solutions.com (8.16.1/8.16.1) with ESMTPSA id 0B3JHj5Z095057 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Dec 2020 12:17:45 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Philip Prindeville <philipp@redfish-solutions.com>
In-Reply-To: <CACsn0c=+qq55Wpsiz+VrTu3rSwmgaoK7yuw139o3tMxqOTfXNQ@mail.gmail.com>
Date: Thu, 03 Dec 2020 12:17:45 -0700
Cc: NTP WG <ntp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <766EBD74-82E3-4CF1-B4BC-45248C2AD5C7@redfish-solutions.com>
References: <F2AD65AD-3403-486E-AEF9-3EF07F88A7FF@redfish-solutions.com> <CACsn0c=+qq55Wpsiz+VrTu3rSwmgaoK7yuw139o3tMxqOTfXNQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
X-Scanned-By: MIMEDefang 2.84 on 192.168.1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ccJWjVIgC01-iS_9M6Hx7h0ZdcA>
Subject: Re: [Ntp] NTPv5 and anycasting
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: Thu, 03 Dec 2020 19:17:50 -0000

If the clients are (1) using 123 as both the source and destination ports as they should be, (2) behind a single masquerading IP address as most SoHo routers are, then (3) the first client out typically gets the source port reservation (unless the router itself is already using the port, in which case random source port assignments happen for everyone else).



> On Dec 3, 2020, at 8:23 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
> As the operator of one of the biggest anycast NTP deployments in the
> world, how about not?
> 
> At least in our case,  we use ECMP on the router, so if an association
> uses a persistent port, it will get to the same server modulo
> announcement changes due to server failure. I'd be happy to
> collaborate in measurement research to quantify the magnitude of any
> such effects when this is not the case. Route flaps are pretty rare,
> so that's not much of an issue. I know the synchronization inside the
> datacenter is quite good.
> 
> If we had to use DNS based load balancing that would be equally
> nondeterministic, but would be significantly slower to adapt to server
> faults, more susceptible to improper DNS or association caching by
> clients, and complicated for boring architectural reasons. Anycast
> scales much better without IP address consumption (for v4), while DNS
> gives more flexibility in load balancing in the working case. DNS
> would enable clients to use multiple different points of presence, and
> figure out which has the best time, vs. being subject to the whims of
> BGP. I don't know how much of an advantage that gives in realistic
> scenarios.
> 
> In practice I think many single-homed servers are in fact anycasted
> over a small number of servers behind a single Internet facing router
> to provide redundancy. Once you're in the world of uptimes greater
> than that of a single server, these sorts of setups are essential.
> 
> We also would not be able to join the pool without lots of operational issues.
> 
> I'm happy to collaborate in answering these questions: there are no
> real secrets in the time service, and the NTP community has been very
> helpful. We'd love to return the favor.
> 
> Sincerely,
> Watson Ladd