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

Magnus Danielson <magnus@rubidium.se> Mon, 02 September 2019 11:32 UTC

Return-Path: <magnus@rubidium.se>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7772812011C for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 04:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rubidium.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmKtGITxti-S for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 04:32:18 -0700 (PDT)
Received: from ste-pvt-msa1.bahnhof.se (ste-pvt-msa1.bahnhof.se [213.80.101.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EC5120052 for <ntp@ietf.org>; Mon, 2 Sep 2019 04:32:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id 20D4D3F6D0 for <ntp@ietf.org>; Mon, 2 Sep 2019 13:32:16 +0200 (CEST)
Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (2048-bit key; unprotected) header.d=rubidium.se header.i=@rubidium.se header.b=QEmAbrwL; dkim-atps=neutral
X-Virus-Scanned: Debian amavisd-new at bahnhof.se
Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzLCR3yynEuM for <ntp@ietf.org>; Mon, 2 Sep 2019 13:32:14 +0200 (CEST)
Received: from magda-gw (h-207-183.A498.priv.bahnhof.se [176.10.207.183]) (Authenticated sender: mc643307) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 4570F3F6C6 for <ntp@ietf.org>; Mon, 2 Sep 2019 13:32:13 +0200 (CEST)
Received: from machine.local (sslvpn.netinsight.net [213.254.205.2]) by magda-gw (Postfix) with ESMTPSA id 056D79A0067 for <ntp@ietf.org>; Mon, 2 Sep 2019 13:32:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rubidium.se; s=rubidium; t=1567423933; bh=BnJZkWGZtA1oPdWeCIg0GgENeFL/bSFzgfNTxyIGHX8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QEmAbrwL4+5N0SGqj9yzrgtqmdwBsTxH25camP3+IUgPPAVjIxv1VvyIkteuvihXM PaYZgj3EwUKdpKpXmPfq8SlkxcwK1e4KuvrKoEdarEpb7H8wAh7f2oE8PkL4PP9e9H qCb3W33LohwojKNF7NPQtOygd2Q8VJ8lhIn6sCF4Rz3mCOeoRWeZWtZFKf9kWXDQCo 1Pq/Jt5+A3Dbn5AXHOPt95h+v9N8qnFyMP0cC7LCkpz3bbc0BLjmpEtGSGKA4OuXB+ WTUV581K5oXwD+HjsklOYrRf0dMIdYWn92jRTHfpJrHUnCt3bl7qAyfbY3v8b73MSq RwSJ7RNHUxFXA==
To: ntp@ietf.org
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de> <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de> <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org> <20190828111458.GJ24761@localhost> <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org> <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de> <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se> <252618a3-d2fb-d5b1-baa4-72b16ef0f845@nwtime.org>
From: Magnus Danielson <magnus@rubidium.se>
Openpgp: preference=signencrypt
Autocrypt: addr=magnus@rubidium.se; keydata= mQINBFy+b+kBEADW0YJkwpNVP9kDD2qWmTi2Qlbkk+5FbKVnMd6IsbPNl85jLmFbhk4Uu867 5285Pd38bM6R9DQMXW8yt+xiB9NuTnAx8ZPO6L1HfIYaO2SCKVQqiA8iHUWAN4UrSSsAHOCp xBwS5GJKfUBtnDLTFK7NsGs0xOC64qyqv3ddKgvElAUDvXhSi6qs8Qh638cxN5XNyTMw0ILM fcq519SZXPS9pj+oxatuOurE431cQ3VFqBF3ieH7GkwkndX/2raKonSBsM+3uYdlWu1h0GVh cWjAgFAf2nBVZPQq6NLwe25Hgf5pa7Tqg6+Vli/EOa/E6f6TkvF+RD524ir3x2v2G+Owlbz6 8qCcFZD4p8Py14h1+/VzY5zzaq/qlWZRrYYICI9yNQ1ZExxXDS0lGRQgZHvqxZEOXBgkQT6l QZc4ZRvrUiuDsb7PLRIip9nd0oZDiUlvHUFENNO1WJdhXPExoa/Tjelw5ffvahb5t9wXgpif qJn27isoiWehA1wc4Fh4JUFg1fa65yKEki/Ps78mPJubineK4AT71m497KLEtaDBt/+s0Hyq 5AVetlNWFGDisOtOvLAe5LI92337Ny9g7TI5y9FgMYMbN3cmY5ZUevnHqxNmbshWQbW/CR3G ZH0Ml67OxjOvz/J25ECgIL+6UDDvoSLi5g2JJlAM7un+8MI11QARAQABtCVNYWdudXMgRGFu aWVsc29uIDxtYWdudXNAcnViaWRpdW0uc2U+iQJUBBMBCAA+FiEEMCgsXhMipMyv30PWEBB6 j67QDxAFAly+b+kCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQEBB6j67Q DxDg3BAAr6TbmoGW5DVZGyHNolfXwR9AutmqMcNiVVN97F56ftWBjRnELH/r052QqtDOLw3v BrR75bnFVZZdCsoIE2S0mOOCYrL4EPKQ/XO+ZoMwvml6QdDpVxrHebWNmesdtcDTGSTjlvIx k9wSXEH6mrqk+Mst2BuL0eXl+ihL+Ew6tRX9vBTsB8jkkKMooAO+xRAhvcoKgyFpb/57m9Db cE1cIC1qEDBfA1EY4ABQJTZ9LGBJxNYWwVh6i0AOiRvVKqlc9zdpfczWFkAUIvAX+sT9pPa5 pWb8iKL+1VErKlp2vP1FsrzKnnic2v084dSCG28C8BR/A5ncqmg/GWKYS4vzMEYfZY8R2b/Y t8d7ZGdjb5cDV4nFsN6yaIYbbwyTj5yTtY16a6SsK0TX9Jx8sLzwOd32MUVb6jph3ol+Zthp Z1V5rVm86Oix4RvS49afTWH1ZODnplNbKjHEjgp4ml4+iLpvVRUlMSCRKfvKuq9otqqJ/Rts Hb4Hq79fVZYTomVE/FqwAnL3VA94ssHnbGA0wRwCka+R75ZwEE0FQ6ee8NEisB+BxAZufYXj +DUA3upPpss3LuQ3VRebQ2JlGZuenxWoIrA22CFlAlSL6miyi1zcSe9VHQyavEvL3aPE0pBc 118QQGL+8ItgwXWdsmY1uYksCVSmZt+bdTpVb6oDrpe5Ag0EXL5v6QEQAK/LKexG/aDVeFfE JE3evLlcAA9TTZ7pyasBup4Kl8LUHGUHspkI6Tb3UAASpEfv3L/6ykfYOJiwdX+BVEVXDAH/ 0JSFovYL3Kthpmus70FjdW8K8fFoK3zIoA31d8QsItE8TaFiwczV0Y1/A8f+H30afL5SwVWl Uwt7KqqPkwuDIUlI7BHiLyFMhKMEddPEO+vFWX7MrHkqTSqBS8GOzeJWdd1r7IVrYwB/PNYZ bHZO2F3yf8y1MJw6reWkfgGE4E3X0ocyfCdBVTokMZLcxJIwpfuSMbr6EVLeHhfR4/q1CXZ4 SiH+MccQF/Srryt84dt+BS3I/RcmB9+5d9pA0Z8wcHoSmYCgn+q83J2KHoK8+jy9Bu6SoUMz jo5YL3rO8lVqOqPhR6RPM7+BD4wZlpZNLfEsCxvNRBsVD1zxE0vibhkmfqIIenzoWcpmzgDt jqZxR/dD2SqShPPAl+cPL85tS4gNeKz1Ose0xJa31G0KKkpGbepPie57V0swlNk0Q/UGOr0w sIqRPIzyeJMi10jje230U0kEO2mttq39wum+dyPa1i0DlQbF+YcMVXo+/RdDuO43YwzSkoAG cn1f8EHQeIY/OXqRJe+mc1qZKfzpZPBzPeK5H44jrJ74iCfD5SvHtGcUpSxUYQxmQ9cIueNy W4yUBM1kj4TU8ruJS8AJABEBAAGJAjwEGAEIACYWIQQwKCxeEyKkzK/fQ9YQEHqPrtAPEAUC XL5v6QIbDAUJCWYBgAAKCRAQEHqPrtAPEDOeD/9FqRjE7a8iqujWlUGH/FMC5x4IgU0H7pqL kTsJOkPNBEeNIntktts8Veynm1Q+z+2pJKgQT5esKNyB2xKZkqAKmxGkx84TRzs+R7ulhJmX Ii5C1FQ8B/iaIndaQVyunURZaOfNJOiu3uekyIIf/IYCMvVD/uY3+AuVGOGQ9hJqc+YUEc9V V+e7Atz9a40nWoXTDpu1JVQecnudbxncOEFNvjixYIg13XUHC77+hCjaqwbfCc4eeqi6i7cW C7bIrz5AqfYMEeyjY/kVQRGGb3Z5M8WObLTWQgt9OJtKL2y+6GaVQ61eM5vMJ17Z0PQdPrw+ Fjl4QPRiOtkDNiiwwkYZ6Ir34OdSL52KovCgZ9DdxFJF4E+M7PhoLXW2uBFbBMNxlhJiGdJt lpZ9QI6D4y1V/KqOcO42BbDCNx+8SJ9iqvzF1BcSrnblYbKvmb9szesQlFlKI6xm9g7lAHg8 7hjCTHbNEq6KgXp4vgifwxM4PeHwx6FJiexGxn4LyxWa9613bRlIK78GTcS7qTEFS6/dSM07 46Di48tQOOYOox17iFrDb6BKU67W+2g2pN1PWXkwI3DcJ0ioR3KUGUdofYJ/0OrOmDoCXnUY VYNl3h+eiP9CdbI+EjIHVCEJ2h11X69UXsihw6NGkTseCm9plUnsVxHazi9Iq4wDmhv6Yx6G 4w==
Message-ID: <e5b16adb-eddb-fadd-4940-9d97685a36e4@rubidium.se>
Date: Mon, 2 Sep 2019 13:32:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <252618a3-d2fb-d5b1-baa4-72b16ef0f845@nwtime.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/So507Iswu70poNgsyVuGWYLHxhY>
Subject: Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 11:32:22 -0000

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
>> ntp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ntp
>>