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

[Ulrich Windl <[e-mail]>]

>>> Erik Kline <[e-mail]> schrieb am 23.07.2021 um 01:54 in Nachricht
<CAMGpriU3PKheo1uWStRid4z8mMuUvLwwkSx0j8+js=[e-mail]>:
> On Thu, Jul 22, 2021 at 1:52 AM Miroslav Lichvar <[e-mail]>
> 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