Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

[Magnus Danielson <[e-mail]>]

Dear Harlan,

On 2019-09-02 12:47, Harlan Stenn wrote:
> On 8/28/2019 4:30 AM, Magnus Danielson wrote:
>> I agree. If someone knocks on the door with v5 packets, reply in v5
>> form, if someone knocks on the door with v4 packets, reply in v4 form.
>> As people migrate to v5, they can start using all the benefits from it.
> So what's the value and purpose of the version field in the packet if we
> decide it no longer identifies the structure/content of the fields in
> the packet?
I have never said that. Rather the opposite.
> An implementation that speaks "version N" MUST understand version N
> packet formats, and SHOULD understand versions <N.
>
> If there is a blanket requirement that if we understand version N and we
> get a packet that is version >N, then if we respond with that same
> version instead of responding with a version N packet, then we are
> effectively saying we MUST NOT ever change the layout and meaning of the
> content of the base packet.
>
> What I'm seeing in this thread is that folks disagree with the above,
> and in that case I'm wondering if folks understand what they think
> they're advocating for.
>
> Please see Heiko's last comment below, and understand it in this context.

Your comments are void since you misunderstood me, you should know
better. Re-read and I think again and you will realize what I was trying
to say is already in line with what you said. I do not feel motivated to
contributing further if you keep this up.

>
>> For loop-protection, keeping a list of nodes from the source is a very
>> easy base condition to avoid routing loops, since as an announcement
>> comes in, if none of the nodes in the list is oneself, you may use it,
>> where as if any of the nodes is oneself, a loop is for sure detected.
> The recipient has NO KNOWLEDGE of what the incoming refid means.
>
> It's SOLE PURPOSE in this is degree-one loop detection, and that happens
> at the "top" of the local tree.
Which indicates it's not a good method. You refer to another technical
context than I was referring to.
>
>> While the trace loop detection mechanism is sufficient in theory, it
>> does not completely solve all loop problems, as transient loops may
>> occur, but it at least avoids problems in the long term.
> I don't believe there is any current way to communicate this knowledge,
> so larger trace loop detection seems impossible without a way to
> communicate this information.  It also begs the question of *where* this
> detection should happen.

I've designed these things before. I know what works.

You need to communicate a trace list, which requires dataformat to
support it.

There is other methods, too.

> I think Heiko mentioned a loop they saw and I would be very interested
> in seeing the details there, as such a loop should break as soon as any of:
>
> - the stratum in the loop devolves to 16
> - the root distance grows
> - possibly something else
These are too slow. You shoot the phase of the systems too far. It's a
weak method. It will break a loop, but way too late and the collateral
damage is too great.
> The point being that the important thing is that if a loop happens there
> is an automatic recovery path.  If we never get a loop that's better,
> but it won't be fatal to a properly configured setup if a loop happens
> and the loop is then broken.

The trouble with the loop is that the system is tricked to belief this
IS the better path. You need to kill old topology information or have a
full trace to break any risk of loop, and to very quickly kill the loop
and allow for other paths to be discovered.

>
>> If I only had time to describe all the things I would do to enhance NTP,
>> it has a number of built-in assumptions which is not useful or correct.
> How about a list of at least some of the built-in assumptions that you
> think are not useful or correct?

From the top of my head a few:

The Allan interception point is based on incorrect theory of the noise.

Rather than drive things to highest stratum, going to closes
intermediate node and then let that do aggregated questioning to
increase the width of single stream rather than separate allows better
noise surpression of asymmetric delays.

The frequency/phase lock-in methods is dated and has failures in
error-handling, especially with how calibration works and can become
incorrect. There is simpler methods with much better error-handling.

Cheers,
Magnus

>
> H
> --
>> Cheers,
>> Magnus
>>
>> On 2019-08-28 13:23, Heiko Gerstung wrote:
>>> Why not define a method in v5 that not only protects against degree 1 loops but maybe also against degree 2,3 or n? 
>>>
>>> This is what I meant when trying to explain that we should not stick to the existing packet format with its shortcomings.
>>>
>>> Regards,
>>>    Heiko
>>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
>>