Re: [Ntp] Consensus call: NTPv5 and leap second smearing (vote to support clearly defined and UNAMBIGUOUSLY implemented smearing procedure)

[Warner Losh <[e-mail]>]

On Mon, Jul 10, 2023 at 2:44 AM <kristof.teichel=[e-mail]>
wrote:

> I concur mostly with Daniel's view here.
>
> I do believe that we need to include "official" support for leap smearing,
> since prohibiting it is probably futile anyway.
> But it is not enough to set a flag to notify a client that a server is
> using smearing - not if we don't know how exactly it implements that
> smearing.
> What we need (if smearing is used) is a way to unambiguously convert and
> compare smeared time to non-smeared time.
>
> I like option 3 of Daniel's suggestions: encode UTC as TAI plus smearing
> event information and offset information - but I think a duration for the
> event might be necessary, I'm afraid not everyone might see noon-to-noon as
> the only acceptable interval.


So far, I like the notion of having the timescale, and additional data.
this additional data can include the introduced frequency error, the
current know error, the offset from other well known timescales, etc.

So for all the 'leap seconds frozen in time' time scales, like GPS, LORAN
(though I guess this is gone), etc, they would all encode to timescale=UTC,
TAI-OFFSET=<X in seconds>. A smear would encode to whatever is being
smeared along with the current frequency error and offset to UTC. These
optional tags would be ignored by dumb ntp clients, so they would get the
smear for free, but sophisticated clients could look at the ancillary data
to know what's up. This scheme would also work well for UT1 ntp server
(which would encode a UTC-OFFSET, but that will jump, so maybe that's not a
great idea). Smeared time scales would say they are UTC, and have a
UTC-OFFSET that moves around, but doesn't jump except at the leap second
insertion).  It would have a UT1 timescale, and a current offset to UTC as
additional data. Dumb clients that track it can just get UT1, if that's
their thing, and sophisticated ones could recover UTC form that, though
likely at a lower fidelity than one would from a pure source (same is true
for smears: there's a lot of moving parts to the smear, and you can only
make your best guess at what UTC really is, should you need that and it
will necessarily be lossy compared to getting UTC directly). This would
also allow monitoring of facilities that want to smear, but may need to
find out sequence data that needs UTC after the fact, or to monitor how the
org did, etc. It's fairly open ended what they do with the data, and again
the dumb clients just discard the extra data.

I'd still keep the number of time scales down. TAI will catch GPS, etc
that's just a fixed offset. UTC is TAI with the observationally driven
leaps added promulgated by IERS. No other timescales would be needed for
almost everybody since all time scales are either fixed-offsets from one of
these, or some variable offset. (but keep the standards open, so a martian
time scale that has unknown features today could be defined in the future
via an RFC, get an encoding and be available to those implementations that
understand it). This could also define other time scales should there be a
resumption of leap seconds in 2050 with radically different rules (UTC 2.0,
to steal a web jargon). Not likely, and the details need not be nailed
down, but a framework to communicate data about the timescale, and also how
it differs from some canonical time scale would be helpful.

I've not seen this all in one place, but I'm mostly repeating the best
ideas I've seen elsewhere, with my own (maybe a bit dated now) notions. I
do think that mandating UTC always in the NTP timestamps with only the leap
indicators to guide you and doing the smearing by requiring extra
sophistication by clients is a mandate that will be ignored and we'll have
an even bigger mess here.

Warner


>
> Besten Gruß / Kind regards,
> Kristof Teichel
>
> __________________________________________
>
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.:        [phone]
> E-Mail:   [e-mail]
> __________________________________________
>
>
>
> Von:        "Daniel Franke" <[e-mail]>
> An:        "Dieter Sibold" <[e-mail]>
> Kopie:        "NTP WG" <[e-mail]>
> Datum:        02.07.2023 21:22
> Betreff:        Re: [Ntp] Consensus call: NTPv5 and leap second smearing
> Gesendet von:        "ntp" <[e-mail]>
> ------------------------------
>
>
>
> There are two things I care about:
>
> 1. The timestamp on the wire must be something that can be
> unambiguously converted to UTC.
> 2. The packet must contain sufficient information for the client to be
> able to apply a noon-to-noon smear if desired.
>
> The NTPv4 behavior of repeating during a leap second insertion is
> unacceptable, because this creates ambiguity. Any of the following
> would be equally acceptable to me:
>
> 1. Timestamps are UTC, represented using two fields: a day number, and
> time since midnight. Leap indicator bits MUST be set during precisely
> noon to noon .
> 2. Timestamps MUST be smeared linearly noon-to-noon in proximity to a
> leap event. The leap indicator MUST be set when and only when smearing
> is in progress.
> 3. Timestamps are TAI, and information elsewhere in the packet provides:
>    a. The TAI time at which the last-announced leap event begins (may
> be past, present, or future)
>    b. The direction of the event (insertion or deletion)
>    c. The TAI-UTC offset at the completion of this event
>
> 1 and 2 are perfectly equivalent in what information they provide. 3
> is more informative, and therefore nicer for the client but harder for
> the server, because it has to have the extra information available.
>
> On Wed, Jun 28, 2023 at 3:56 PM Dieter Sibold <[e-mail]>
> wrote:
> >
> > Dear all,
> >
> > at IETF 116 we decided to have two consensus calls regarding the content
> of the NTPv5 requirement draft. These are consensus calls that we would
> like to conduct to help progress the NTPv5 requirements document (
> https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/).
> Both consensus calls will run until July 21st 2023 and will be discussed at
> the next NTP wg meeting at IETF 117 in San Francisco.
> >
> > The second consensus call:
> >
> > Regarding leap second smearing:
> >
> > Currently, the NTPv5 requirement draft states that NTP servers should
> not apply leap second smearing to transmitted timestamps. Shall NTPv5
> support leap second smearing? If yes, shall the NTP server apply leap
> smearing to the transmitted timestamps or otherwise shall the client
> perform leap second smearing?
> >
> >
> >
> > Greetings
> > Karen and Dieter_______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>