Subject: [Ntp] ETP (Extended Time Protocol)

From: Hal Murray <[email-masked]>
Date: Wed, 06 Jan 2021 03:46:21 -0800

[email-masked] said:
> In this case, wouldn't it be better to start defining a completely new
> protocol and e.g. call it "Extended Time Protocol", which can be chosen
> instead of NTP? This would be similar to PTP, which you can use instead of
> NTP. ;-) 

Do you have any suggestions?

Given a clean sheet, what would you do?

["clean sheet" may be a US/English idiom.  It means no constraints, no 
backward compatibility issues.]

-- 
These are my opinions.  I hate spam.

---

From: James <[email-masked]>
Date: Wed, 6 Jan 2021 12:42:17 +0000

I am all in favour of having a discussion around backwards/forwards
compatibility, but as for naming things perhaps it's a little early to
bikeshed.

- J

On Wed, Jan 06, 2021 at 03:46:21AM -0800, Hal Murray wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 15:46:55 +0100

> Do you have any suggestions?

In fact it was just a spontaneous joke to propose something like "ETP".

But seriously, IMO a v5 version of NTP should be as compatible as
possible to v4, and I've tried to explain the reasoning for this.

I really think that if you want a protocol with completely different
behavior, a different name should be used instead of just bumping the
protocol version.
> Given a clean sheet, what would you do?

I tried to explain this in earlier messages.

If you design a new protocol you can do whatever you want:

- 64 bit timestamps to get rid of limited epochs (48 bits as in PTP are
sub-optimal, IMO, because every single timestamp has to be extended on
64 bit systems before you can use it)

- Timestamps based on TAI, plus sufficient information in the base
packet to derive UTC from it, which is still the base for legal time

- Additional, extended status information etc.

So you can develop clean client/server implementations from scratch, and
there is no confusion as it's expected when your distro updates ntpd or
chrony from v4 to v5, and time synchronization stops working, or even
worse, the time steps due to incomplete TAI/UTC offset information.

If you want to roll out a new version of NTP, the basic behavior should
be left unchanged, IMO.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 6 Jan 2021 16:16:16 +0100

James,

For sure, put I think it would be wise to keep the NTP part as common
denominator, NTP-EP for NTP Extension Protocol would make much more
sense and follow a mechanism used by many other protocols. It's not any
generic extended time protocols, it's NTP's extendtion protocol. So that
change at the very least. Then we can bike shed all we want if it's an
extention protocol, options protocol, management protocol etc. I'm sure
I can find my bike out in the shed there somewhere in the mess.

Cheers,
Magnus

---

From: Hal Murray <[email-masked]>
Date: Wed, 06 Jan 2021 16:31:24 -0800

[email-masked] said:
> But seriously, IMO a v5 version of NTP should be as compatible as possible to
> v4, and I've tried to explain the reasoning for this.

> behavior, a different name should be used instead of just bumping the 

I don't see any tweaks to v4 that are important enough for a new version.

To me, the key idea in NTP is that you get 4 time stamps from an exchange of 2 
packets.  If consensus is that we should reserve "NTPv5" for something that is 
as close to v4 as you envision, or has the time stamps in UTC or ... I'm happy 
to switch to a different name.

Switching to TAI on the wire is the only idea I've seen that is important 
enough to focus our new protocol work on.

I think putting the UTC info into an extension will provide good/clean support 
for systems using leap seconds as well as provide a clean split between 
exchanging time via packets and the info needed to leap.

I think making the new packet format convenient for current v4 users is a 
secondary consideration.  It's much more important to get the basic packet 
exchange clean.  Moving leap info out of the basic packet format will help 
with that.

I envision that next generation of NTP servers will support both v5 (or 
whatever we call it) and v4 for a long time.  (They probably have to support 
v3 too, and maybe even leap smearing.)  Anybody who really wants v4 can keep 
using it for a long time.

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 7 Jan 2021 16:10:51 +0100

> enough to focus our new protocol work on.

Support for the new, clean extension fields comes to my mind as an
update for NTPv5.

As I mentioned before, I'm sure changing the scale of the time stamps in
the packets will

a) cause a lot of confusion
b) prevent simple systems from being able to use it

> exchanging time via packets and the info needed to leap.

Of course, but as I pointed out, that works also the other way round, if
you can consistently derive TAI from the packet timestamps, if you
need/want it.

> exchange clean.  Moving leap info out of the basic packet format will help 

Sorry, I disagree. Most systems run on UTC (or the POSIX approximation
of it), and I don't think this will change in the near future.

The problems with POSIX time as well as the problems you get when you
let your system fully run on TAI have been discussed for many years, and
nothing has changed.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 7 Jan 2021 16:49:33 +0100

> b) prevent simple systems from being able to use it

Yes. NTPv5 needs to be more versatile than NTPv4 if anything, not
less. It needs to better support current and future use cases.

Currently, NTPv4 is (ab)used to transfer UTC, a leap-smeared UTC, UT1,
and sometimes even TAI (between hardware clocks). That is an issue for
compatibility. NTPv5 needs to explicitly say in which timescale are
timestamps in the packet. A small field in the header is enough to fix
this, as I proposed in my draft.

> let your system fully run on TAI have been discussed for many years, and

Exactly. Even if we added full support for TAI to all systems (I can
help with Linux), it would take many years before it's widely
available and can be considered as a requirement for a protocol.

I invite anyone proposing this idea of supporting only a non-leaping
timescale to show a proof of concept, e.g. as a patch for one of the
existing open-source implementations. I'll tell you where it will
break.

-- 
Miroslav Lichvar

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 7 Jan 2021 17:29:23 +0100

> this, as I proposed in my draft.

Agreed.

Right now, we at Meinberg have some requests from customers who want
local time to be transmitted for NTP requests coming from specific IP
ranges.

Just because there are dumb wallclocks (or similar equipment) that
receive "some" time from the server and display whatever they get.

I'm all for new ways to improve this situation, but I'd really prefer if
it could be done at a high level of compatibility with existing systems.

> existing open-source implementations. I'll tell you where it will

Exactly.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 7 Jan 2021 11:17:39 -0700

> On Jan 7, 2021, at 8:49 AM, Miroslav Lichvar <[email-masked]> wrote:
> 

Well, at the rate we’re going…

-Philip