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

[Watson Ladd <[e-mail]>]

On Tue, May 26, 2020 at 5:51 AM Heiko Gerstung
<[e-mail]> wrote:
>
> 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.

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

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

Sincerely,
Watson Ladd