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

[Marcus Dansarie <[e-mail]>]

On 2020-02-15 02:12, Watson Ladd wrote:

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

Thank you!

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

I view the fact that DUTC and DUT1 are tricky to get hold of as a major
argument for including them. I only expect a few servers to actually end
up including them in responses, but even that would greatly increase the
availability of the information. For DUTC, an updated leap second file
should be sufficient, but DUT1 may be hard to get right without manual
handling.

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

Agree. The absence of a future leap second from the list should probably
not be considered malfeasance. The question is what the absence of the
most recent past one should be considered, especially if the server
otherwise provides acceptable time. (And what if a server has a RADI of,
say, 10 seconds and misses multiple leap seconds?)

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

Peter's original suggestion, which was forwarded to the list by me,
should be somewhere in the archive. But yes, that is the general idea. I
am not entirely convinced myself, and would be perfectly happy to
continue with the current timestamp format. My main concern with Peter's
suggestion is that it adds lots of complication to gain a small amount
of precision (in a protocol called ROUGHtime).

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

Yes, I agree that what you describe is a real risk and a very valid
argument against using a fraction-of-day timestamp format.

Kind regards,
Marcus