Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

[Magnus Danielson <[e-mail]>]

Hal,

On 2021-01-05 13:45, Hal Murray wrote:
> [e-mail] said:
>> NTP is used for synchronization of various clocks. Most of them are based on
>> UTC. NTPv5 cannot support only TAI. 
> This is a tangled area.
>
> I think that a TAI only NTPv5 protocol would be much cleaner and easier to 
> document.  Yes, I agree that we need a story for UTC, but the answer doesn't 
> have to clutter up an RFC for NTPv5.

Look at the SMPTE 2059-1 and SMPTE 2059-2 solution for instance. 2059-1
provides the detailed mapping mechanisms for all various formats. 2059-2
augments the IEEE1588-2008 with fields to carry the necessary
information. so that the set of gears in 2059-1 will work.

So, you can keep one RFC with a TAI-based (but not actual TAI) NTPv5
protocol. Then another RFC providing the mapping mechanisms and
extension fields for them. If then the extension is carried in the NTP
core protocol, an extension data variant of NTP that also gets
transported through is then another separate issue. There is no secret
that I lean towards one that follows the overall distribution of time
itself, at least for most part (I know it sounds confusing, but it's a
separate point).

>
> All the kernel and/or libc need to convert TAI to/from UTC is the TAI-UTC 
> offset (a small integer) and the date of the next leap second, a flag for 
> insert/delete/none, and the valid-until date of the info.
Yes. Actually, you do not need a flag to indicate insert/delete/none.
You can do with something to indicate upcoming leap-second event, and
then the encoding of that event will include information of when the
event occurs and the resulting difference. The flag should not
necessarily indicate direction, that's a specific encoding from history
that we may choose to ignore.
>
> We could provide that data in an extension.  The same extension would allow a 
> NTPv4 server to provide clients with enough info to let current UTC based 
> kernels provide TAI and/or leap when appropriate.
They are not really UTC based kernels. Some of them is however also able
to do UTC, but most have the POSIX or Linux time_t, which isn't UTC. We
can let libc provide the historic time_t in implementations.
> We could provide that data in a new protocol.  Or a new packet type on the NTP 
> port.  Or via DNS.

If one looks at PTP for instance, it has an "event interface" and a
"general interface". The event interface is the only packets that
experience time stamping, where as the general interface does not. The
type of data we describe here would fit what goes on the general
interface rather than the event interface. I think it's a good model.
See Figure 2 in IEEE 1588-2008.

I have also already made the point that management related data, which
have been discussed as potential DDOS tool, do not even have to be
carried on what looks like NTP. Thus, it may not need to be limited to
UDP but could use the TCP stack of solutions. That would for sure not be
event interface, but general interface.

> An extension would piggyback on whatever we use to authenticate NTPv5.  DNSSEC 
> would authenticate the DNS approach.
>
> If we implement this on the network, we should be sure to emphasize that the 
> data only changes every 6 months and that we expect clients to remember the 
> answer rather than ask every time.

No. It still can change every month. It's just a preference to change on
the end of each half year, and that preference have been honored so far.
However, I've seen bugs show up because of interpreting things
incorrectly. Whatever mechanism is being used, it needs to respect the
underlying capability of inserting leap seconds at the end of every UTC
month, and it also needs the ability to indicate that when an upcoming
leap second shift is to occur, it needs to be able to indicate when that
shift occurs and what the new value will be. The exact encoding of that
can then differ naturally, but it needs to unambigously convey the same
information as I stated.

> We could provide code that lets systems process leap-seconds.list
> ntpd already does.
> A copy of the leap seconds file is included by the Time Zone project and 
> distributed by IANA.  Most distros are already setup to keep the time zone 
> info up to date.  It should be simple for the leap file to go along for the 
> ride.  Debian already does it.
>
A curious note there thought. It uses the older NTPv4 time of timestamp
format. It will be less well adapted to a new TAI-based NTPv5 timestamp
format. It may actually be wise to revise that and eventually to
unentangle it, as it has historical limits to it. The way that NTPv4
time-stamps work, you kind of need the table, but if you use a TAI-base,
you only need the current TAI-UTC offset and potentially the future. You
do not need the history. The leap-seconds.list is another form of
artifact that is not without it's issues. Even the comments in them can
be somewhat confusing if read outside of the NTPv4 context.

Cheers,
Magnus