[Ntp] Antw: Re: Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Fri, 23 July 2021 07:39 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 D9C733A0907 for <ntp@ietfa.amsl.com>; Fri, 23 Jul 2021 00:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 haAjfFvJ2hoL for <ntp@ietfa.amsl.com>; Fri, 23 Jul 2021 00:39:05 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [194.94.157.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999643A0905 for <ntp@ietf.org>; Fri, 23 Jul 2021 00:39:05 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BB4686000053 for <ntp@ietf.org>; Fri, 23 Jul 2021 09:38:59 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id 925486000050 for <ntp@ietf.org>; Fri, 23 Jul 2021 09:38:57 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Fri, 23 Jul 2021 09:38:57 +0200
Message-Id: <60FA720F020000A100042A06@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Fri, 23 Jul 2021 09:38:55 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <ek.ietf@gmail.com>,<mlichvar@redhat.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <YNw9fHMijDFIW9B4@localhost> <YNrbjCDF4/609dg/@localhost> <D999D237-5A25-4E84-99D0-EE5DB2B13411@cisco.com> <YN3ZzPN5LOsAjmz6@localhost> <DM4PR11MB5438D8450E7B90D363929640B5119@DM4PR11MB5438.namprd11.prod.outlook.com> <YPaunrczI/inrtMP@localhost> <60F6B70A020000A100042803@gwsmtp.uni-regensburg.de> <YPa9H7IV2wITWKrD@localhost> <CAMGpriWzV4--_Nw9hsNC01U7f1FzjZQ8sNdJz+25dxhFtuDUvg@mail.gmail.com> <YPkxqtpgzD7g8Anz@localhost> <CAMGpriU3PKheo1uWStRid4z8mMuUvLwwkSx0j8+js=vOgnV3WQ@mail.gmail.com>
In-Reply-To: <CAMGpriU3PKheo1uWStRid4z8mMuUvLwwkSx0j8+js=vOgnV3WQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/JpL4knS2GLm-EZY2iczcbZWr8bo>
Subject: [Ntp] =?utf-8?q?Antw=3A_Re=3A__Antw=3A_=5BEXT=5D_Re=3A_Robert_Wi?= =?utf-8?b?bHRvbidzIERpc2N1c3Mgb24gZHJhZnTigJFpZXRm4oCRbnRw4oCRaW50ZXJs?= =?utf-8?b?ZWF2ZWTigJFtb2Rlc+KAkTA1OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U?= =?utf-8?q?=29?=
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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: Fri, 23 Jul 2021 07:39:11 -0000

>>> Erik Kline <ek.ietf@gmail.com> schrieb am 23.07.2021 um 01:54 in Nachricht
<CAMGpriU3PKheo1uWStRid4z8mMuUvLwwkSx0j8+js=vOgnV3WQ@mail.gmail.com>om>:
> On Thu, Jul 22, 2021 at 1:52 AM Miroslav Lichvar <mlichvar@redhat.com>
> wrote:
> 
>> On Wed, Jul 21, 2021 at 12:07:47PM -0700, Erik Kline wrote:
>> > >
>> > > Of course, this doesn't change anything about compatibility with
>> > > existing NTPv4 implementations. There is no clean way to detect the
>> > > support.
>> > >
>> >
>> > <random bad idea>
>> > For client mode, could the client make use of the LI field to indicate it
>> > speaks interleaved?
>> > </>
>>
>> No, there are clients that always set it to synchronized, other
>> clients set it always to unsynchronized, and other clients set it to
>> their actual status.
>>
> 
> Ah, fascinating.  =)
> 
> If we are considering unclean solutions abusing unrelated fields, the
>> best one would be the reference timestamp. It is 64 bits and it is
>> normally ignored by the server. The NTPv5 proposal uses this field to
>> detect whether an NTPv4 server supports NTPv5. Not a clean solution,
>> but I don't see a better one. What would IESG think about that?
>>
> 
> I'm not yet sure what would ease folks' concerns.
> 
> One thing struck me when reading your reply on another thread about using
> an extension:
> 
>     Using a 28-octet extension field to convey a single bit of information
>     is quite wasteful anyway.
> 
> While I certainly see this point, it occurred to me that if the extension
> where written to be a general "extra flags and fields" extension -- of
> which one was defined for "I speak interleaved" and rest reserved -- then
> another way to think about it is that the cost of this space would be
> amortized across the other future uses of the space.

Hi!

Another interesting point is what the minimum packet length is for today's high-speed networks:
If short packets are padded anyway, it's a kind of useless discussion.
The real problem is that NTP did not have a mechanism for extending the packets format in a clean way.
AFAIK NTPv0 (RFC 958) did not even have a version number.
The implementation of extension fields is a "dirty hack" IMHO.

> 
> Of course, that assumes that there would be other uses of the space to come
> along and make that amortization happen, and I don't know enough to
> speculate with any confidence the likelihood of that...
> 
> For the interleaved mode, clients could be required to set it to a
>> specific value, maybe XORed with their RX and TX timestamps, to push
>> the false positive rate to the 1/2**128 territory. I think this would
>> truly make it the hack that same people already consider it.
>>
> 
> Operationally speaking, there ought to be one value somewhere between 1900
> and ~now that could be blessed with meaning.  But I agree this seems like
> "mak[ing] it the hack that same people already consider it."

Another thing that is an ugly hack is the "epoch" thing (much like the GPS week number).
There should be a clean solution in NTPv5, too.

Regards,
Ulrich