Re: [Ntp] Antw: Re: Re: [EXT] Re: I‑D Action: draft‑ietf‑ntp‑ntpv5‑requirements‑00.txt

[Miroslav Lichvar <[e-mail]>]

On Fri, Aug 19, 2022 at 11:16:18AM +0200, Ulrich Windl wrote:
> >>> David Venhoek <[e-mail]> schrieb am 18.08.2022 um 18:05 in Nachricht
> <CAPz_-SWtw9jx2veKeg-C+pMHUkfnqDE=[e-mail]>:
> ...
> > For me, such a server (assuming those stratum 2 and 3 servers
> > contribute in the algorithm of section 11.2.3 or something similar,
> > and not just in selection algorithms) would indeed be stratum 4. In
> > other words, I would very much prefer stratum to provide an upper
> > bound on the path length from the server to a "ground truth" source of
> > time.
> 
> It's highly hypothetical, but if your server ever includes a stastum-15 source, nobody can use your server then.

We could increase the maximum possible stratum if that is an issue.
With the new frequency transfer we can expect better performance with
longer chains of servers, e.g. switches in large local networks.

We can also provide both the minimum+1 and maximum+1 stratum from the
upstream sources.

> Also AFAIR startum affects the estimated error. With favouring higher strati, wouldn't the estimated error increase?
> 
> s.v[n].metric = MAXDIST * p->stratum + root_dist(p);

That doesn't necessarily have to be used by NTPv5 implementations.

> I said before, I would not consider that to be a loop (MHO, "peers don't loop").

And I still don't agree with that.

> So if the crowd starts to ignore R, it may start like:
> A(2) == B(3)
> B(3) == C(3)
> C(3) == A(2)
> 
> Once A falls down to stratum 3, the rest will also fall down one stratum level, and so on. At A(15) B and C would have to consider R again (maybe even earlier), and B would be fed with some better time via A and C, and the possible cycle begins again.

We would like to prevent that from happening in NTPv5.

-- 
Miroslav Lichvar