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

[Erik Kline <[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.

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