Re: [Ntp] NTPv5 Loop Detection without Stratum - Why do we want this?

[[e-mail]]

> Von: "Miroslav Lichvar" <[e-mail]>
> An: [e-mail]
> Kopie: "[e-mail]" <[e-mail]>, "Heiko Gerstung" 
> <[e-mail]>
> Datum: 06.09.2022 12:43
> Betreff: Re: [Ntp] NTPv5 Loop Detection without Stratum - Why do we want 
this?
> 
> On Tue, Sep 06, 2022 at 12:15:46PM +0200, 
> kristof.teichel=[e-mail] wrote:
> > If everyone does use stratum consistently (and in particular sees to 
it 
> > that their own stratum is higher than the max of those of its own 
> > sources), then there will never be a loop.
> 
> There will be a loop, but it will terminate after several rounds due
> to some server reaching the maximum stratum (currently 16), which will
> not be acceptable by the client.
> 
> When the client unselects that server, its stratum will go back to
> some small value, which will cause the server to decrease its stratum
> and it will become selectable for the client again. The loop is back.
> 
> Stratum cannot prevent loops unless we don't allow clients to select a
> server with a higher stratum (as it was in NTPv3).

Excuse me, I was naively assuming we were doing that (because otherwise, 
why even use strata?).
At first glance, your description actually seems to reinforce how not 
doing it creates problems/takes meaning out of even using strata.

> It can only
> terminate them and it doesn't prevent them from happening again.
> 
> The Bloom filter proposed for NTPv5 should allow the network to reach
> a stable state where the loops are broken in a single point.
> 
> > 1b) Wouldn't tighter requirements on stratum use make things even 
easier?
> > I assume that everyone agrees that using higher stratum servers is 
never 
> > beneficial for accuracy - and often detrimental.
> 
> I'd not agree with that. Stratum doesn't indicate accuracy. It depends
> on the reference clocks used by primary servers and network paths 
between
> the servers.

I mean, if we allow that servers use higher-stratum servers as sources, 
then obviously stratum doesn't indicate accuracy (or, really, much of 
anything?)...
But if we don't, then it becomes useful, and in particular, we also get an 
upper bound for accuracy at least inside a given sync chain (i.e., I'm not 
reliably MORE accurate than the best lower-stratum server I'm using, and 
usually less accurate as per the inaccuracies my connection introduces).

But noted that not everyone would agree, thanks :)
 
> -- 
> Miroslav Lichvar
>