Subject: Re: [Ntp] [EXT] Re: The bump, or why NTP v5 must specify impulse response

From: "David L. Mills" <[email-masked]>
Date: Tue, 12 May 2020 13:52:10 -0400

Ulrich Windl wrote:

>Hi!
>
>But maybe let's try to structure v5 better than the versions before.
>I could imagine like specifying packet formats and packet flows for one major
>part, while other parts treat specific algorithms. Maybe even there could be
>more than one for each category.
>And I think the algorithms should not just be given as code (specification by
>implementation), but also as some high-level description. That alone could help
>to find flaws in the code. I think in the past there was a lot of "magic math"
>in the algorithms, claiming "don't ever change this, or the world will fall
>apart" ;-)
>I had several cases where the specs did not help me, so I had to read the code
>of the implementation. Having to do that is a clear sign that the specification
>is incomplete.
>In a perfect world the specification says what is allowed, and everything that
>is not allowed is forbidden. Mayb specification use both worlds: Some things
>are allowed, some things are forbidden, and there is a gray zone that is to be
>avoided ("neither allowed or forbidden").
>
>Regards,
>Ulrich
>
>  
>
>>>>Harlan Stenn 22.04.2020, 01:24 >>>
>>>>        
>>>>
>I still disagree here, for whatever that's worth.
>Splitting the documents is great *when it's appropriate*. In this case,
>it will be a *lot* more work to create correct RFCs, there will be way
>more opportunities to confuse things or get them wrong, and the people
>who specify conformance stuff will have a lot more work to do, too.
>A case in point is 5905 and 5906 and the keyIDs: Miroslav saw that 5906
>was optional and since he wasn't planning on implementing Autokey he
>ignored it. But 5906 had critical, required information in it that
>*should* have been in 5905, and since the reference implementation did
>both of them and that's what folks were looking at when the RFCs were
>drafted folks didn't notice the fencepost problems.
>When people pay attention to something, they often do not pay attention
>to stuff they consider "out of scope".
>NTP has been a carefully designed system, that includes the protocol,
>its operating environments (conditions and constraints), and some
>behavioral requirements.
>Splitting the document up into different parts is an invitation for
>things to be "missed".
>H
>On 4/21/2020 11:59 AM, Doug Arnold wrote:
>  
>
>>I agree with Philip. And I also like the terms protocol and policy. In
>>my mind the protocol is what has to be the same for implementations to
>>communicate and the policy is what allows a specific node to make use of
>>information received via the protocol. It is possible to have nodes in
>>the same network using the same protocol, but with different policies.
>>
>>There could be a generic NTPv5 which works for 90% or more of the users,
>>but a modular architecture which allows for some alternative policies
>>for niche uses. People are already doing this for NTPv4, its just that
>>its proprietary.
>>
>>A little reminder of history: an early draft of NTPv4 was based on a
>>modular approach, but was later revised to be a monolithic complete
>>solution. The monolithic solution works very well for setting clocks in
>>servers and routers for general IT purposes. However, the collapse of
>>the modular approach drove the telecom timing community out of the NTP
>>working group and into the IEEE 1588, where we ended up defining unicast
>>PTP. Unicast PTP is incompatible with traditional multicast PTP and in
>>some ways is more like NTP than it is like multicast PTP. So we created
>>a new find or PTP to fit an application which could have been served by
>>a more flexible NTPv4.
>>
>>Now the same thing is happening in data centers. People are installing
>>PTP. Many of these people tell me they would prefer to install a high
>>precision variant of NTP. They keep asking me to change PTP to be more
>>like NTP. It might be better to make NTP a little more flexible than to
>>create more incompatible flavors of PTP.
>>
>>Doug
>>
>>------------------------------------------------------------------------
>>*From:* ntp <[email-masked]> on behalf of Philip Prindeville
>>    
>>
>>>*To:* Harlan Stenn <[email-masked]>
>>>      
>>>
>>*Cc:* [email-masked] <[email-masked]>
>>*Subject:* Re: [Ntp] The bump, or why NTP v5 must specify impulse response
>>
>>
>>
>>    
>>
>>>On Apr 17, 2020, at 4:48 AM, Harlan Stenn <[email-masked]> wrote:
>>>
>>>[snip]
>>>
>>>More to the point, NTPv4 and all of its predecessors specified:
>>>
>>>- the packet format
>>>- the algorithms
>>>- a set of behavioral limits and specifications
>>>
>>>This means others were allowed to write specifications (regulations)
>>>assuming and/or relying on "NTP" - the packet format, algorithms, and
>>>behavior.
>>>
>>>Removing or separating the algorithmic and behavioral specifications
>>>from the NTP specification at best cost-shifts that discussion
>>>elsewhere, and I submit it does this to groups that are likely
>>>completely unaware that they can no longer rely on behavior that they
>>>had no idea they previously relied on.
>>>
>>>Are you planning to just do a protocol spec and "do the algorithms and
>>>behavior spec later", or worse yet, let others do that if they think
>>>it's important?
>>>      
>>>
>>Not to throw gasoline on the fire, but Postel told me decades ago,
>>“don’t confuse protocol and policy” (he was [ahem] encouraging me to
>>drop 3 paragraphs from the draft of RFC 1048). It was good advice then
>>and it holds.
>>
>>Algorithms are, in essence, a “policy” for disciplining a clock.
>>
>>A compromise might be to define requirements for the protocol
>>parametrically, in terms of drift, jitter, etc. while not defining the
>>algorithms to do that.
>>
>>This opens the field up to more active research in ways to improve the
>>protocol and the use of clocks without tying anyone’s hands.
>>
>>The protocol could provide a “reference algorithm” that’s used as a
>>baseline and as an example of a certain performance “envelope” under
>>well-defined circumstances.
>>
>>Given how long NTPv4 has been around (for both right and wrong reasons),
>>it’s reasonable to expect NTPv5 to live at least half as long. A lot of
>>technology can potentially emerge during that time and we should have
>>the flexibility to incorporate it as it develops.
>>
>>Look how far we’ve come since Cesium ovens as reference clocks.
>>
>>-Philip
>>
>>_______________________________________________
>>ntp mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ntp
>>
>>_______________________________________________
>>ntp mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ntp
>>
>>    
>>
>--
>Harlan Stenn <[email-masked]>
>http://networktimefoundation.org - be a member!
>_______________________________________________
>ntp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ntp
>
>_______________________________________________
>ntp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ntp
>  
>
Ulrich,

A formal analysis of the feedback loop is contained in my book.  It 
developed the costant for the clock dicipline algorithm, which is often 
implemented in the operating system. 

Dave

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 26 May 2020 11:51:01 +0200

I second that. There are a gazillion use cases out there and a multitude of time sync requirements. A client that needs to time stamp legal documents would want to adjust its own clock very quickly (i.e. maybe stepping it) to be as close as possible to "true" time. Other devices and applications require that steps are avoided at any cost, even it that means the clock is wrong by x and the client nows it. For those clients, there are a lot of different limits in regards to the accepted adjustment rate for the clock, depending on what the clock is actually used for. Most do not want to jump backwards at all, a few may be fine with that as long as it is documented somewhere etc. etc. 

Making it modular would be very useful. It would be great if the protocol could allow to advertise the selected algorithms, which could be standardized on their own (as suggested, a standard/default algorithm that may resemble what NTPv4 does would be required) or at least documented by whoever introduces it. Maybe a registry could be set up or companies would be able to use their IANA OUI's plus a self-assigned ID. 

   Heiko

-- 
Heiko Gerstung 
Managing Director 
 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: +49 (0)5281 9309-404 
Fax: +49 (0)5281 9309-9404 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
[email-masked]
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com
 
Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

Am 16.04.20, 19:29 schrieb "ntp im Auftrag von Dieter Sibold" <[email-masked] im Auftrag von [email-masked]>:

    The problem with this combination is that we currently have no 
    implementation that conforms to RFC5905 completely.
    There are different use cases for potential clients. Some of them are 
    not well served with the current algorithm other are. A modular approach 
    would allow both: to apply an algorithm most suitable to the application 
    and to be compliant with the protocol spec.

    Dieter

    On 16 Apr 2020, at 11:58, Harlan Stenn wrote:

    > On 4/15/2020 6:38 AM, Salz, Rich wrote:
    >>>    We had the same discussion at the transition from ntpv3 to ntpv4.
    >>>    If you do this, please do not call it NTP.
    >>
    >> Can you explain why 3->4 could still be called NTP but 4->5 should 
    >> not?
    >
    > You didn't quote enough context.
    >
    > NTP is a combination of two parts:
    >
    > - the protocol/packet structure
    > - algorithmic and response behavior
    >
    > If you are only specifying the protocol in this new thing then it is
    > dangerous/misleading/irresponsible to call this v5 document "NTP".
    >
    > It is only slightly less dangerous/misleading/irresponsible to call it
    > "NTPv5 Protocol", regardless of whether or not there is also an "NTPv5
    > Algorithms and Response Behavior".
    >
    > --

---

From: Watson Ladd <[email-masked]>
Date: Tue, 26 May 2020 11:45:12 -0400

> I second that. There are a gazillion use cases out there and a multitude of time sync requirements. A client that needs to time stamp legal documents would want to adjust its own clock very quickly…

The challenge with a hierarchy is that the clients are also servers,
so we need to ensure stability is maintained down the chain. Even
without that rapid adjustment is counterproductive: In ntpd's
algorithm the clock adjustment rate serves to dampen the jitter as
well as adjust the clock to true time: increasing the loop gain can
lead to overresponding to jitter and worse tracking. I don't think the
slew rate limit is in practice the limiting factor as much as the
jitter on the network. With a more accurate clock there will be even
slower adjustments due to the Allen intercept moving further right. In
chrony these two are tracked separately, but the fundamental problem
of tuning remains.

That doesn't mean we can't modularize. It does mean that we may to
restrict particular parameter choices and advise implementors to
carefully test in multimachine configurations, akin to what one has to
do before unleashing a new congestion control upon the unsuspecting
TCP implementations of the world. Imagine if BBR v1 had gone live in a
new Windows version...

> Making it modular would be very useful. It would be great if the protocol could allow to advertise the selected algorithms, which could be standardized on their own (as suggested, a standard/defaul…

I'm not sure what the advertisement is for: what is the client or
server supposed to do with this knowledge?

Sincerely,
Watson Ladd