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

[Ulrich Windl <[e-mail]>]

>>> Miroslav Lichvar <[e-mail]> schrieb am 23.08.2022 um 10:02 in
Nachricht <YwSJrSQllwlpgfpu@localhost>:
> On Tue, Aug 23, 2022 at 08:48:07AM +0200, Ulrich Windl wrote:
>> >>> Miroslav Lichvar <[e-mail]> schrieb am 23.08.2022 um 08:20
in
>> Nachricht <YwRxmL8faFhwwCNn@localhost>:
>> > As an analogy, maybe two pendulums coupled with a spring could
>> > represent a synchronization loop. Energy can transfer in both
>> > directions. We don't want that. Energy should transfer only in one
>> > direction.
>> 
>> But isn't it the original idea of peering that information flows in both
>> directions?
> 
> It can flow in both directions, but it should not do that at the same
> time. At least that's how I understand it.
> 
> There is a hint at https://www.eecis.udel.edu/~mills/ntp/html/assoc.html: 
> 
>   In some contexts this would be described as a "push‑pull"
>   operation, in that the peer either pulls or pushes the time
>   and related values depending on the particular configuration.
> 
>> For your sprint‑coupled pendulums: Peering (the spring) would try to (at
>> least) make them swing synchronously.
> 
> I think it would cause oscillations, maybe even become chaotic, but it
> has been a long time since we played with these things in the physics
> class.
> 
>> Probably works best of both pendulums have the same length. But wouldn't
NTP
>> adjust the length of the pendulum (frequency) on each side? You might 
> consider
>> that to be a loop as the lengths of the pendulums on each side influence
the
>> length on the other side. Convergence may not be guaranteed.
>> 
>> So you would simply put it as "peering is always a loop".
> 
> Maybe it is with the current implementations and the typical
> configurations using symmetric mode for backup. I don't think that is
> correct. The synchronization should be suppressed (at least in one
> direction) when the peers are at the same stratum, i.e. when the
> backup is not needed.

I did a quick search on "symmetric mode", and I found:
"The service can operate in a symmetric mode, in which servers and clients
are
indistinguishable yet maintain a small amount of state information(...)"
(RFC958, page 2)
Interestingly page 6 describes that ports different from 123 would be used,
and that both sides may use a different polling interval:

(long quote)
"In the symmetric mode the client/server distinction disappears.
Each peer maintains a table with as many entries as active peers,
each entry including a code uniquely identifying the peer (e.g.
Internet address), together with status information and a copy of
the Originate Timestamp and Receive Timestamp values last received
from that peer. The peer periodically sends an NTP message to each
of these peers including the latest copy of these timestamps. The
interval between sending NTP messages is managed solely by the
sending peer and is unaffected by the arrival of NTP messages from
other peers.
The mode assumed by a peer can be determined by inspection of the
UDP Source Port and Destination Port fields (see Appendix A). If
both of these fields contain the NTP service-port number 123, the
peer is operating in symmetric mode. If they are different and
the Destination Port field contains 123, this is a client request
and the receiver is expected to reply in the manner described
above. If they are different and the Source Port field contains
123, this is a server reply to a previously sent client request."
(that is the protocol version without a mode field)

RFC 1129 defines two modes of symmetric: symmetric active, symmetric passive
"The symmetric modes are intended for distributed scenarios where either peer
can potentially
become the reference source for the other." (page 8)

RFC1305 repeats the initial statement: "The service can operate
in a symmetric mode, in which servers and clients are indistinguishable, yet
maintain a small amount
of state information" (page 5).

"Normally, one peer operates in an active mode (symmetric active, client or
broadcast modes) as
configured by a startup file, while the other operates in a passive mode
(symmetric passive or server
modes), often without prior configuration. However, both peers can be
configured to operate in the
symmetric active mode." (page 18)

After all I learned that the symmetric modes are the oldest modes of NTP, and
I was surprised that very little about the algorithm of symmetric peers is
said.
So my conclusion still is that the "ping pong" style of time exchange between
peers is in accordance with the protocol specification.
(However if those peer have no other time source, the quality should become
worse over time, eventually declaring them unsynchronized)

> 
> It causes oscillations, which has a negative impact on stability of
> the clocks. If you remove the symmetric associations, it performs
> better. You can easily verify that.

It may be, but would it be in the spirit of the protocol specification?

Regards,
Ulrich

> 
> ‑‑ 
> Miroslav Lichvar