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

[David Venhoek <[e-mail]>]

On Mon, Aug 15, 2022 at 12:52 PM Miroslav Lichvar <[e-mail]> wrote:
>
> On Fri, Aug 12, 2022 at 04:26:37PM +0200, David Venhoek wrote:
> > 2. Loop detection
> > Thinking about it, I think refids are unnecessary for loop detection,
> > and although they do accelerate rejection of some connections faster,
> > I think we can do with just the stratum mechanism for loop rejection.
>
> If clients are allowed to synchronize to servers with equal or higher
> stratum (like in NTPv4), stratum alone cannot prevent a loop from
> forming. It can only stop one that already formed.

That is true, but refids only stops loops in very specific cases,
namely when two servers point to each other directly. Any other
configuration with a loop still needs to rely on stratum to eliminate
the loop. Furthermore, something like a refid for indicating source of
time only really works when there is a clear single source, which even
in ntpv4 seems unlikely when following guidance in the spec.
(everything seems aimed at averaging from multiple remotes) That
combined with the potential trouble around getting a good value for
this field seems to me a reason to at least look critically at if we
really need it (and not paint ourselves into a corner by explicitly
requiring it in the requirements document).

> > In general though, I think it would be worthwhile to reconsider the
> > way we require stratum to be calculated, especially in light of
> > clients potentially using an average of more than 1 server as their
> > reference. In such cases, I think rather than the current mechanism
> > (appoint 1 as "the" upstream and add 1 to its stratum) we should at
> > least consider specifying that the nodes stratum should be at least 1
> > higher than the largest stratum of a server which it "used" (in the
> > sense that it directly influenced steering, rather than just
> > truth-finding) in synchronization.
>
> That would help with detection of loops that formed through the other
> selected sources, but would the network be able to reach a stable
> stable? I suspect without refids it would be switching back and forth.

There seem to be two things implied here, so I'll respond to both
those concerns separately:

First, let us consider more aggressive incrementing of the stratum on
its own. I intuitively don't think this will cause stability problems
that wouldn't be present with just choosing 1 primary upstream and
presenting its stratum+1 as our stratum, but I have to admit I don't
have a proof for this. Furthermore, even if I would be wrong on this,
you might then end up with servers that for a significant fraction of
their input depend on loops, which may not be better.

Second, you are right that in very specific circumstances two servers
pointing at each other can start oscillating without refids. As an
example, consider two servers A and B where A always wants to use B as
a remote based purely on the time quality, but B only wants to use A
when it is using B as its input. In that case, if the stratum cutoff
is just right, their stratum values will climb until A rejects B on
stratum, after which B drops A as input and reduces his stratum, A
picks up B again and the process starts all over. However, this is not
unique to cycles of just two servers (a similar situation can exist in
a cycle of length 3), and it requires some strange decision making on
the part of server B in that server A is improved by server B to the
point that it makes server B think it is now good as a source of
synchronization, even though that improvement was derived from a less
precise version of B's current idea of time, but I may be wrong in
writing that off as unrealistic.

Kind regards,
David Venhoek