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

[Harlan Stenn <[e-mail]>]

On 9/2/2019 4:32 AM, Magnus Danielson wrote:
> 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.
What did I miss?  "If someone knocks on the door with v5 packtes, reply
in v5 form, ..."

How would a v4 implementation do this *properly*?  How would a v3
implementation do this?  There are still MILLIONS of v3 implementations
out there, and a noticeable number of "cheap" implementations, mostly in
embedded devices.

I continue to maintain that a response should be with a packet at the
highest version level we speak that does not exceed the version of the
incoming packet.

>> 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.

Please tell me how I misunderstood you.

Perhaps you misunderstood me?

Either way, I'd prefer we both understood each other, and hopefully came
to an agreement.

>>> 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.

It's not a good method *for what*?  It's demonstrably a good method for
detecting and avoiding degree-one loops.

>>> 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.

Please offer at least a draft proposal.  I look forward to the security
analysis.

>> 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.

Then perhaps effort is better spent in detecting this case, as it would
*seem* to be an issue of an insufficient number of time sources.

If one has insufficient time sources,  exactly what are the alternatives
to providing time sync amongst the members of the "time island" and what
are the costs/ and benefits of each alternative?

With insufficient connectivity to what extent does it matter which weeds
one sails off into?

With insufficient connectivity (ie, knowledge of accurate time) how can
any demonstrably better choice be made?  This is precisely why we
shifted from local refclocks to orphan mode.  And the bottom line is one
must still make decisions based on the best available information.

>> 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.

I'm not certain this is the only viable approach, especially in today's
security environment.

We might be able to avoid this based on additional weighting and
analysis of stratum and root distance, or perhaps some new meterics.

>>> 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.

I honestly don't know if this is true or not.  I don't disbelieve you.

I do wonder if perhaps the elements that make up the noise now have
changed from what they used to be.

Is that what you are saying?

> 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 suppression of asymmetric delays.

I'd have to re-check, and I thought we stopped following the best
stratum and focused on the best "numbers".

As for increasing the width, how is that different from making sure one
has enough sources of time?

At what level of the tree does this matter?

There is mechanism and policy here.

One can have leaf nodes that listen to a lot of different upstreams.

One can have leaf nodes that listen to one or more different upstreams,
where each upstream listens to a "wide" number of sources.

How is this different from the age-old discussion of "have enough
sources of time"?  And folks who pick one, which is great until it dies,
so they pick 2, until that fails because of lack of a majority, then 3
which fails when one dies and it devolves into 2, or 4 which works until
2 follow correct time and 2 follow leap-smeared time, or ...

I submit we have all the mechanism we likely need, and the problem is
with the implemented policy choices.

> 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.

I'd like to discuss this with you privately, if you're interested.

H
--
> 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
>>>
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!