Re: [Ntp] NTPv5 Loop Detection without Stratum

[Heiko Gerstung <[e-mail]>]

>     Are timing loops an actual, real problem?
Yes. 

>     If so, what are the significant considerations?
Not sure what that means (sorry). 

>    What core variables are in play?  Root distance?  Root/peer dispersion?
I do not know. I would say that timing loops are having a negativ impact independent from what core variables are involved. 

>    What are the root causes of these loops?
In most cases I would say "configuration errors".

Regards,
  Heiko


Am 24.08.22, 10:43 schrieb "ntp im Auftrag von Harlan Stenn" <[e-mail] im Auftrag von [e-mail]>:

    Are timing loops an actual, real problem?

    If so, what are the significant considerations?

    What core variables are in play?  Root distance?  Root/peer dispersion?

    What are the root causes of these loops?

    H

    On 8/23/2022 3:21 AM, Heiko Gerstung wrote:
    > 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
    > 
    > 
    > _______________________________________________
    > ntp mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/ntp

    -- 
    Harlan Stenn <[e-mail]>
    http://networktimefoundation.org - be a member!

    _______________________________________________
    ntp mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ntp