Re: [Ntp] [EXT] Re: NTPv5 draft suggestion to move timescale offset into extension fields.

[David Venhoek <[e-mail]>]

Dear All,

This took me a bit longer to think through than I originally intended,
but since it came up during the last virtual interrim: I think
miroslav's suggestion for changing to providing a second receive
timestamp in the extension field is a very good idea. After thinking
about it a bit more, I think it would be best to also include an
explicit era number in that extension field. This would give us
maximum flexibility in the future with regards to the zero point of
new timescales, instead of having that be forced to within a window of
about 70 years (wraparound is every ~140 years, so if two zero points
are more than ~70 years apart the "closest" era heuristic no longer
works).

As for using the extension field id to also encode the timescale, if
we include the era that is not needed, but even if we don't I am a bit
uncomfortable reserving a whole block of 256 ids for essentially one
message (we only have about 240 of those). Especially as we might want
to in the future provide other extension fields for information on
timescales (such as frequency relations), and in that case this would
become multiple blocks if we want to keep the structure similar. I
think the 3 bytes (or 2 bytes if era number is included) that this
wastes is not worth the increased pressure this puts on the extension
field ids space.

Kind regards,
David Venhoek

On Mon, Nov 7, 2022 at 3:59 PM Ulrich Windl
<[e-mail]> wrote:
>
> >>> David Venhoek <[e-mail]> schrieb am 07.11.2022 um 15:28 in Nachricht
> <CAPz_-SVkFZaycpimBGy-pZRgwxo9pdnrmh7QDd-=[e-mail]>:
> > In response to ulrich, NTPv4 has a similar restriction where normal
> > clients should not synchronize to strata higher than 15. However, that
> > was not yet part of the NTPv5 draft, the comment here was merely to
> > suggest that clients should not synchronize to servers with strata
> > higher than that, even though we can now represent (just like in
> > NTPv4). I am not really sure what you mean with the mapping part of
> > your comment, if I missed something important there could you please
> > elaborate?
>
> I meant (if I understood the NTPv4 correctly):
> If any stratum > 15 is mapped to zero before transmission, what sense will it make to have higher values, unless adjusting that value of ">15" (MAXSTRAT) at the same time.
>
> [...]
>
> Regards,
> Ulrich
>
>