[Ntp] Fwd: Roughtime protocol suggestion....

[Marcus Dansarie <[e-mail]>]

I contributed text to Roughtime draft-03 and had some discussions around
that with Peter Löthberg the other week. He sent me an email this
weekend with some comments he wanted me to share with the list. I'm
copying it verbatim below.

Regards,
Marcus


-------- Forwarded Message --------
Subject: Roughtime protocol suggestion....
Date: Sat, 6 Jul 2019 16:22:40 GMT
From: Peter Lothberg

20190706

Marcus, please forward this to the mailing list.

Marcus (& others),

I think it's a BIG mistake of not taking proper handling of
leap-seconds in to account on protocol designed in 2019....

Here is a proposal, I knew, it's some more lines of code, but
even if someone fucks up completely they are within the magic
second you wanted.

Today you have 5 bytes for microsecond past midnight, so
protocol resolution is;

0.000001, second

First question/proposal is to encode the "time word" MJD day
and fraction of day in a way where we can change the
resolution format, this way we can keep the format for the
future ("the Internet/IANA way of representing time in...")

Eight bytes of MJD and 32 bytes of fraction since beginning
of day (don't make it milliseconds, nanoseconds, picoseconds..)
can be encoded in a byte; (Let the server chose the format
for the resolution.)

01234567
DDDFFFFF

So the 4+5 format I recommend would start with 10000101

Time can never go backwards, by doing the division and changing
the number of seconds in a day a client that do not understand
anything about leap seconds will be approximating the time to
the best possible without any code on the client.

A client that supports leap seconds can do the correct thing,
and it's possible to have the client tracking the time of the
server.

Also a note, we should point out that any "local time" is a
operating system problem to deal with the 500+ rules out there.

Let's keep the 5 bytes for my examples. Instead of using
microseconds since midnight, let;s use fractions of day
since midnight with the available resolution. I put the comma
at microseconds.

5 bytes = 40 bits = 1,099,511,627,776

A regular day has 86400 seconds; 86400/1099511627776
gives us a resolution of;

0.000000,07858034223318 second

Better than 10 times better than the microsecond model.

Still this does not solve the leap-second problem, as it
require us to knew BEFORE the 24 hour period with the
leap second is started.

We need to knew three things to do this right;

   - Is the leap-second positive or negative,
     (as we don't want to bet our names on that it will
     always be positive)

   - A warning telling us that a leap-second day is coming.

   - Are we in the leap second day?
     (I'm not sure we need to send this in the protocol, as
      leap-seconds can only happen the last day of the month
      a calendar function could calculate that from the MJD
      day part, include the C-code in the RFC that converts
      the fractions in to daytime and the calendar.)

On a leap-day, we change the 86400 number to 86401 or 86399,

86401 86401/1099511627776 0.000000,07858125172788 err
0.006789,42014928883200
86399 86399/1099511627776 0.000000,07857943273847 err
0.006789,26298860380800

(I'm making the assumption that someone want to save on bytes in the
 network message here, if not, just add another byte, put 5 bits
 of fraction after midnight and all three flags in there.)

If we take the two least significant bits out of the 5byte/40bit
field we get 38 bits. 2^38 = 274877906944, 86400/274877906944

0.000000,31432136893272 second/bit

Still better than the one microsecond and now we can encode
the leap second sign and the warning flag. If someone don't
care and use all the 40 bits as a time stamp they will have a
error of max 0.000000,31432136893272 second.

With 38 bits we get;

-1 sec 86399/274877906944 0.000000,31431773095391
 0 sec 86400/274877906944 0.000000,31432136893272
+1 sec 86401/274877906944 0.000000,31432500691153



My suggestion is to do 6 bytes, 3 leap second control bits
we get 45 bits to describe time since midnight, resolution;

0.000000,00245563569478 second

And use the "number of digits" encoding.


--Peter (as there might people with red line yards in my camera view...)