Re: [Ntp] [EXTERNAL] Re: Antw: Re: Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

[Denis Reilly <[e-mail]>]

Leap smearing was one of the main topics of the BCP. Because we understand why it’s a good idea in many cases, but also why it can be perilous if handled incorrectly.

In the BCP, we arrived at a few key guidelines, aiming to preserve the most flexibility to operators while still maintaining standard public behavior:

- Don’t mix smearing and non-smearing servers
- Don’t smear if your timestamps are required to be in sync with UTC
- Only smear on totally private installations, do not smear on public servers

In my view, these restrictions exist because there is no standardized way to detect that a server is smearing in ntpv4. So we settled on the notion that public interactions should use the standard timescale, while operators could do whatever they wanted in the privacy of their own networks.

At minimum, NTPV5 should include a standardized way for the server to tell everyone else that it is smearing the timestamps on the wire, so that clients can elect to not use the server. In my opinion, there is no use in saying that smearing on the wire is not allowed in V5 – people will do it anyway.

I think that we should also have a way for the server to broadcast the smearing algorithm in use on the network. This is, of course, valuable when servers are smearing, because then a client which knows about this can back-out the smearing behavior and obtain UTC time if it wants to. But it’s also valuable if the server is not smearing, because it can help coordinate client-side smearing in clients who are intelligent enough. (In other words, if all nodes updated to NTPv5 with support for this, the server could keep the timestamps as RFC-compliant non-smeared UTC on the wire while telling all clients how to apply the leap smear uniformly if they need to, getting the best parts of client-side and server-side smearing together, while keeping the wire timestamps in UTC.)

In my opinion, we should aim preserve the most flexibility. We should make it easier for operators to do client-side or server-side smearing, and we should allow operators using servers outside their administrative domain to reject servers who apply rules they don’t like. We’re not going to get everyone to agree on one behavior, the best we can do is make sure that behaviors are standardized and easy to implement. To me it seems like we would get a lot of benefit out of adding a few extensions. There have been attempts to standardize this in the past, maybe we can get it done in V5 (just in time for leap seconds to be abolished).


--
Denis Reilly
Principal Timing Architect, Equinix Precision Time
[e-mail]<mailto:[e-mail]>  |  [phone]



From: ntp <[e-mail]> on behalf of Doug Arnold <doug.arnold=[e-mail]>
Date: Friday, October 22, 2021 at 11:06 AM
To: Martin Burnicki <[e-mail]>, Danny Mayer <[e-mail]>, Ulrich Windl <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

My understanding is that Google builds all of its own timing infrastructure, so they can start with smearing as a part of their architecture.

Now everyone wants to copy the Google Spanner approach to distributed data bases, but with timing from vendors and open source projects.  I wish them luck.

On 10/22/21, 8:19 AM, "Martin Burnicki" <[e-mail]> wrote:
Danny Mayer wrote:
> On 10/22/21 6:00 AM, Martin Burnicki wrote:
>> As I've tried to point out earlier, in any case it's the task of an
>> administrator to ensure a proper configuration:
>>
>> - If there are smearing and not-smearing servers, he has to configure
>> which clients should query the time from which servers.
>>
>> - If the clients should do the smearing, he had to configure each
>> individual client whether to smear, or not.
>>
>> - If a smearing server would only reply to authenticated requests, he
>> had to configure on each client which server(s) to use, and which
>> keys, and it wouldn't even be possible to hide the leap second from
>> dumb clients.
>>
> You also need to worry about the cascading effects of a server accepting
> smeared time turning around a sending out smeared timestamps in response
> to requests from downstream clients. Smearing cannot be considered in
> isolation.

Correct. Cascading servers, mixing smearing and non-smearing time
sources, providing smearing clients with a leap second file, etc. are
another stage of potential problems an admin has to keep in mind in all
of the cases I mentioned.

As I said, smearing is a hack, and I just wanted to point out that it's
not easier to let the clients do the smearing, as some folks here seem
to assume.

In fact, one of the original reasons why Google introduces server-side
smearing was that the only had to configure this on a few servers, and
the configuration of a huge number of clients that were anyway sync'ing
to those servers didn't need to be touched.

Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]<mailto:[e-mail]>
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/<https://urldefense.com/v3/__https:/www.linkedin.com/in/martinburnicki/__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mOfAMNRG$>

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de<https://urldefense.com/v3/__https:/www.meinberg.de__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mMAr9L8v$>  https://www.meinbergglobal.com<https://urldefense.com/v3/__https:/www.meinbergglobal.com__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mPZeVtZc$>
Training: https://www.meinberg.academy<https://urldefense.com/v3/__https:/www.meinberg.academy__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mNntA4yb$>