Re: [Ntp] Timescales

[Magnus Danielson <[e-mail]>]

Hal,

On 2020-12-09 11:18, Hal Murray wrote:
> Crazy idea dept...  But maybe...
>
> Can we make the basic time transfer protocol use a simple/clean time scale, 
> say TAI with nothing in the basic protocol about leap seconds?

The most robust solutions is creating a time-scale that is some
well-defined shift from TAI, and then provide the TAI-UTC difference
explicitly along with a pre-warning system. Look at for instance GPS [1]
and PTP [2]. I've chosen this path myself and it has worked very nicely.

So, this is not a crazy idea, it's robust engineering proven in battle.

What is problematic is able to support backward compatibility to the
classical NTP time-scale as this needs to be handled in all time-stamps.

>
> The idea is to push the leap second stuff to a sub-protocol or whereever.  
> Keep the main protocol clean.  Let the client handle leap seconds.
>
> ("sub-protocol" doesn't seem like a good term, but I can't think of a better 
> one right now.)
>
> If you had such a split, would you package the extras as extensions or a 
> separate mode?

>From experience, you would *NOT* do it as an optional extension. It
would need to be a required extension, field and mechanism. The
flimsiness of optionality has been a major roadblock of getting this
properly rolled out. Even treating it as an extension creates issues
with processing and when the extension field is available. The hard
lesson learned is that the related field needs to be mandatory and
processing wise there more or less from the start.

So, while you technically move leap-seconds off the core time-stamps and
the time-scale those time-stamps is processed in, you should make sure
that the leap-seconds themselves remain part of the core protocol, with
very few corner case situations that can be well understood and well
managed.

>
> Is there anything that would go in such a sub-protocol that involves "now"?  
> For example, you might want to implement leap-smearing by saying "the offset 
> from TAI is now xxxx" but you don't need that.  The client can compute the 
> offset.
You don't want to do smearing of leap-seconds, I see less and less use
for it. If you like, provide the parameters to convert hard TAI to UT1
if that suits the application better, but there can be multiple
applications on the same device that have different requirements, so all
such adaptations should be standardized and moved to the client side,
while core transport should have that know relationship to TAI, and
through that UTC, UT1 and various local times can be produced at client
side giving needed mapping information is there.
>
> Aside from leap-second stuff, what else would get packaged that way?
You can build a UT1 model parameters, consider how the corrections of
GPS time over to UTC is done in GPS [1].
>
> ------
>
> Given TAI, there are 2 pieces of information that a clients needs to handle 
> UTC and its leap seconds.  The first is the current TAI-UTC offset.  The 
> second is when the next leap second happens.  That data changes very 
> infrequently and with plenty of warning.  There is no need to clutter up 
> on-the-wire protocols with it.  A client could get it from a leap-seconds file 
> distributed by their distro.

No, that goes against the experience, and let me tell you it's bitter
experience. You need to transport it, and leapsecond file updates is
just a very big challenge to coordinate over a very diverse set of
machines while we have an increase need for proper TAI and UTC replicas
in clients. Remember that many uses of NTP is in wide range of
infrastructures with great challenges in updates, etc. Some is in very
locked down systems which may for all practical purposes be seen as
private networks having very little or no connection to Internet, or may
even be completely air-gaped. For such production environments even
getting an upgrade every 2 years can be challenging. Much of the issues
we have in other context is that machines do not get upgrades at all and
may be in excess of 5 years from last upgrade. While I try to fight to
have upgrades becoming natural for all systems, that fight will not be
over and done with in any reasonable time, so depending on it will be
moot. Some vendors tend to import code, but cripple configuration
freedom, and their upgrade rate is low to very low in the same type of
time-frame as system upgrades. Similarly will depending on detailed
configuration, we need to move away from source, intermediary node and
client configuration to be a major factor, as things is confusing and
not very helpful. The bringing the needed info over the protocol, albeit
out of the way for the core time-stamp processing, is what works and
what will survive.

Trying to rule out the transport of leap-second information from the bit
protocol is the crazy idea, it is just going to create more of the same
problems we face today, in fact, we could just put NTP into pension and
let PTP take over in that case.

So, to conclude my standing: Yes, you can move the core time mechanism
over to some variant of TAI, that is going to make core processing
easier and more robust, less corner cases in the core processing. No,
you can not move the leap-second information out of the core protocol,
in fact the opposite, you need to make it a mandatory field and
processing, but you can now let that remaining processing beyond
distribution become a client side issue as the core time over to
whatever the client need.

So, the crazy idea is in my mind thinking one can avoid the issue in the
core protocol, which will not be going well and already with the current
state of things can be a bit of a challenge. Just address the problem
proper once and for all, and learn from the good experience of other
systems.

Cheers,
Magnus

[1] IS-GPS-200L as available for free on gps.gov

[2] IEEE Std 1588-2019 as available for a cost on ieee.org