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

[[e-mail]]

Hey all,

I'm sorry to take several steps backwards here, but I was discussing this 
with Dieter and the Ostfalia folks yesterday, and I have questions:

1) What is the motivation to want to do loop detection, specifically 
without stratum?
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.
Why would anyone want to not use strata in that way, but then still be 
careful about loops?

2) What is this black magic that I've heard a few times (from at least 
Dieter and Danny now) that one RefID is supposed to be enough for loop 
detection?
Miroslav said it: it's a classic graph theory problem, and I don't see how 
looking just two hops further would ever give me a consistent reliable 
answer to "am I connected to X on some path, or not?".
Someone gave an example of a synchronization path A->B->C->D->A, and I 
don't see how the current RefID scheme is even supposed to ever detect 
that.
Perhaps it "works in practice", but that might just mean that 99.9...% of 
users aren't doing crazy enough things to really approach the limits of 
the current scheme's robustness, which is NOT the same as it being very 
robust!

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 would therefore assume that anyone who does not sync to a stratum 1 
server and instead uses stratum 2 has prohibitive reasons for that 
decision (and accordingly for higher strata decisions).
Why then can't stratum be something that is treated as a constant for each 
entity, with an accomanying requirement that a stratum n server ONLY EVER 
uses stratum n-1 servers to sync their clock?
(Add an encouragement that everyone keep their stratum as low as possible 
given their infrastructure)
Shouldn't loops go away completely (and strata 4+ become a really rare 
sight on the public internet, basically an indicator of user error)?


I'm guessing this comes down to some practical aspect (such as the NTP 
pool) that I'm ignorant of, but it really seems to be causing a lot of 
headache for something that looks like it could be avoided with some 
low-complexity guidelines.



Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        [phone]
E-Mail:   [e-mail]
__________________________________________

"ntp" <[e-mail]> schrieb am 23.08.2022 12:21:19:

> Von: "Heiko Gerstung" <heiko.gerstung=[e-mail]>
> An: "Miroslav Lichvar" <[e-mail]>, "Ulrich Windl" 
> <[e-mail]>
> Kopie: "[e-mail]" <[e-mail]>
> Datum: 23.08.2022 12:21
> Betreff: [Ntp] NTPv5 Loop Detection without Stratum
> Gesendet von: "ntp" <[e-mail]>
> 
> One way of avoiding/detecting loops:
> - upon startup, an NTPv5 instance creates a random 64bit ID
> - we add a loop detection EF that can include n IDs (or we use n EFs)
> - a stratum one server, when ask for his "sync trace", responds with
> only his ID
> - a stratum two server would add its own ID to the ID of its 
> upstream server, responding with a sync trace of two IDs
> - a stratum 1+n server would respond with the sync trace of its 
> upstream source(s) plus its own ID 
> - if you use more than one upstream source, you can respond with a 
> list of all IDs from the sync trace of all your upstream sources 
> (removing duplicates)
> - by checking if your own ID is in the sync trace of your upstream 
> source(s), you can find out if there is a loop
> 
> Maybe smaller IDs (32 bit, 16 bit) would be OK as well. 10 IDs would
> be 80 octets on the wire. No question that we would have to find a 
> way to avoid amplification attacks (hello monlist!). Maybe by making
> it mandatory to send a request (with padding bytes) that is as big 
> as the worst case response. 
> 
> Regards,
>   Heiko
> 
> --
> Heiko Gerstung | Managing Director
> T: [phone] | LinkedIn Profile <https://
> www.linkedin.com/in/heikogerstung/> | Twitter <
https://twitter.com/hgerstung>
> [e-mail]
> 
> MEINBERG® The Synchronization Experts
> 
> Meinberg Funkuhren GmbH & Co. KG
> Lange Wand 9 | 31812 Bad Pyrmont | Germany
> Web: http://www.meinberg.de | http://www.meinbergglobal.com | LinkedIn  
<
> https://www.linkedin.com/company/meinberg-funkuhren-gmbh-&-co--kg>
> 
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
> Hartmann, Heiko Gerstung
> 
> Do not miss our Time Synchronization Blog:
> http://blog.meinbergglobal.com
> 
> 
> 
> Am 23.08.22, 12:07 schrieb "ntp im Auftrag von Miroslav Lichvar" 
> <[e-mail] im Auftrag von [e-mail]>:
> 
>     On Tue, Aug 23, 2022 at 11:30:44AM +0200, Ulrich Windl wrote:
>     > So my conclusion still is that the "ping pong" style of time 
> exchange between
>     > peers is in accordance with the protocol specification.
> 
>     If the protocol cannot prevent the loop, there is no other option 
:).
> 
>     If NTPv5 can detect all loops, the client can decide to ignore the
>     measurements of the source to avoid the loop.
> 
>     > (However if those peer have no other time source, the quality 
> should become
>     > worse over time, eventually declaring them unsynchronized)
> 
>     If they have no other time source, the protocol will block the
>     synchronization by ignoring sources with larger stratum (NTPv3) or
>     ignoring sources with matching refid (NTPv4).
> 
>     > > 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?
> 
>     I'm not sure what you mean by this.
> 
>     -- 
>     Miroslav Lichvar
> 
>     _______________________________________________
>     ntp mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/ntp
> 
> [Anhang "smime.p7s" gelöscht von Kristof Teichel/PTB] 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp