Re: [Ntp] Suggested improvements to the Roughtime draft (draft-ietf-ntp-roughtime-00)

[Watson Ladd <[e-mail]>]

On Fri, Feb 14, 2020 at 3:13 PM Marcus Dansarie <[e-mail]> wrote:
>
> All,
>
> I finally found some time to go through the recent Roughtime draft. A
> number of issues, ideas, and suggestions follow below. I can submit any
> accepted suggestions as pull requests on Github.
> (https://github.com/aanchal4/draft-roughtime)

Thank you very much for doing this! I consider most of your suggestions
excellent ideas, but perhaps others have additional input they wish to give.

Some fields especially DUT1 and DUTC might not be available over NTP, PTP,
or NEMA. That makes it a bit tricky to get out of a GNSS unit, even if it
available from the satellite. Since these are optional fields I'm not that
concerned, but it would be a shame if no one could use it. I would make
NONC echoing a MUST: it's trivial for servers to do, has no downsides I can
see.

We may have to refine the notion of malfeasance to cover additional data
such as leap seconds, but that does seem a bit tricky as not all leap
second dissemination mechanisms function the same way or have the same view
ahead.
I have been working on providing formulas for MJD conversion, so the
textual changes you have suggested would be mostly complementary.

>
>
> Finally, I have revisited Peter Löthbergs suggestion regarding the
> timestamp format. The current timestamp format specified in Section
> 5.1.4 doesn't use the full available resolution. His suggestion was that
> we use the full 40 bits of resolution to represent fractions (2^-40) of
> a day. The value is multiplied by 86400 * 2^-40 to get the number of
> seconds since midnight. Using information from the LEAP tag suggested
> above, clients will use 86401 * 2^-40 or 86399 * 2^-40 on leap second
> days. An added advantage of this is that clients that wish to leap smear
> can do so simply by always using the standard multiplier. I'd like to
> hear your opinions on this.

I'm not sure I entirely understand the proposal: it seems that the idea is
to use the 5 fraction of day bytes to represent 2^-40 of the current day,
where the length of the current day in seconds is determined by the LEAP
field applicable to the day in question. My first concern is with the
intervals: if specified as additions to this timescale they change length
with respect to the SI second depending on what day it is. If we don't then
interval arithmetic becomes a bit tricky, as part of the interval is
converted with one number, and part with another number. Comparing packets
where there is disagreement over whether or not a leapsecond happened now
seems a bit tricky.

At a more practical level there is a problem with leap second indications
arriving later in the day. Not all leap dissemination mechanisms work ahead
of time: some only work the same day such as NTP. A server that learns that
there that there is a positive leapsecond in the middle of the day will
adjust the number of seconds it thinks are in the day, so the timestamps
here cannot be directly compared without knowing the leap state the server
is applying, and they have to be converted to some other scale to compare
numerically. That makes me hesitate to endorse this idea but perhaps when I
see formulas I'll be happier with it.

Sincerely,
Watson Ladd