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

[Dieter Sibold <[e-mail]>]

On 22 Apr 2020, at 8:33, Ulrich Windl wrote:

>>>> Philip Prindeville <[e-mail]> schrieb am 
>>>> 21.04.2020
> um
> 19:56 in Nachricht
> <31673_1587492815_5E9F37CE_31673_735_1_2A6E880D-C467-4AC5-A8C2-F3C61B323A53@redf
> sh-solutions.com>:
>
>>
>>> 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.
>
> What speaks against that IMHO is correctness assumptions: If everybody 
> can
> define his own algorithms, but subsequent clients have to use those 
> numbers for
> their own correctness calculations, how can a client have any 
> guarantee that
> the time is within the bounds the packets (I'm not using the word 
> "protocol")
> claim? Even with the current NTP implementation it's quite a challenge 
> to
> assure that the time displayed is the actual time (the NTP performance 
> numbers
> may look nice, but still the time can be wrong).

The NTPv5 protocol specification has to define a set of metrics which 
each server instance at each stratum has to pass to its clients. This by 
the way also is necessary for achieve traceability. If these metrics are 
well defined, correctness assumption is a priori independent of the 
algorithms to discipline clocks.

>
>>
>> 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