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

["David L. Mills" <[e-mail]>]

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 <[e-mail]> on behalf of Philip Prindeville
>>    
>>
>>>*To:* Harlan Stenn <[e-mail]>
>>>      
>>>
>>*Cc:* [e-mail] <[e-mail]>
>>*Subject:* Re: [Ntp] The bump, or why NTP v5 must specify impulse response
>>
>>
>>
>>    
>>
>>>On Apr 17, 2020, at 4:48 AM, Harlan Stenn <[e-mail]> 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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ntp
>>
>>_______________________________________________
>>ntp mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ntp
>>
>>    
>>
>--
>Harlan Stenn <[e-mail]>
>http://networktimefoundation.org - be a member!
>_______________________________________________
>ntp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ntp
>
>_______________________________________________
>ntp mailing list
>[e-mail]
>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