Subject: Re: [Ntp] Modular NTP

From: Doug Arnold <[email-masked]>
Date: Fri, 24 Apr 2020 17:17:40 +0000

Here is a PDF version.

Doug

________________________________
From: Salz, Rich <[email-masked]>
Sent: Friday, April 24, 2020 10:08 AM
To: Doug Arnold <[email-masked]>
Subject: Re: [Ntp] Modular NTP

Maybe post a PDF/export?

From: "[email-masked]" <[email-masked]>
Date: Friday, April 24, 2020 at 12:55 PM
To: NTP WG <[email-masked]>
Subject: [Ntp] Modular NTP

Perhaps the idea of a modular NTP will be more clear with a diagram of how it might work.

Doug

---

From: Tal Mizrahi <[email-masked]>
Date: Sat, 25 Apr 2020 08:50:53 +0300

+1 on the modular approach.

The way I see it, this work could progress in three documents:
1. A protocol document.
2. A default clock control algorithm document.
    + optionally other algorithm documents, e.g., SNTPv5.
3. A configuration document (possibly defined as a YANG module).

Cheers,
Tal.

On Fri, Apr 24, 2020 at 8:18 PM Doug Arnold
<[email-masked]> wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Doug Arnold <[email-masked]>
Date: Sat, 25 Apr 2020 13:22:49 +0000

One of the documents, perhaps the protocol document, would have to define the interface between the protocol and the clock control subsystems.

Doug

________________________________
From: Tal Mizrahi <[email-masked]>
Sent: Friday, April 24, 2020 10:50 PM
To: Doug Arnold <[email-masked]>
Cc: NTP WG <[email-masked]>
Subject: Re: [Ntp] Modular NTP

Cheers,
Tal.

---

From: Daniel Franke <[email-masked]>
Date: Sat, 25 Apr 2020 09:34:09 -0400

On Sat, Apr 25, 2020 at 9:23 AM Doug Arnold <[email-masked]>
wrote:

> One of the documents, perhaps the protocol document, would have to define
> the interface between the protocol and the clock control subsystems.
>

This interface is very straightforward and I think its description belongs
in the algorithm document. On the client side, the protocol engine feeds
the clock control algorithm a stream of decrypted responses annotated with
their origin and destination timestamps. On the server side, the clock
control algorithm feeds the protocol engine the clock values that it should
be responding with.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 25 Apr 2020 13:16:33 -0400

What's missing is the data analysis engine between the protocol engine
and the clock control. Nothing gets to the clock control that does not
get through the analysis engine. This is the core of NTP. Everything
else is just detail.

Danny

On 4/24/20 1:17 PM, Doug Arnold wrote:
> Here is a PDF version.
>
> Doug
>
> ------------------------------------------------------------------------
> *From:* Salz, Rich <[email-masked]>
> *Sent:* Friday, April 24, 2020 10:08 AM
> *To:* Doug Arnold <[email-masked]>
> *Subject:* Re: [Ntp] Modular NTP
>  
>
> Maybe post a PDF/export?
>
>  
>
> *From: *"[email-masked]" <[email-masked]>
> *Date: *Friday, April 24, 2020 at 12:55 PM
> *To: *NTP WG <[email-masked]>
> *Subject: *[Ntp] Modular NTP
>
>  
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 27 Apr 2020 09:53:44 +0200

> control algorithm feeds the protocol engine the clock values that it should

I presume an RFC 5905 implementation should be easily split in this
scheme. Where is the clock filter and source selection? Are they all
in the "clock control"? The clock filter needs to be compatible with
the control loop. Source selection is between them.

-- 
Miroslav Lichvar

---

From: Doug Arnold <[email-masked]>
Date: Mon, 27 Apr 2020 15:24:23 +0000

Good question. I was thinking that any decision from received data intended to increase time accuracy at the client, would be part of clock contol, and the protocol engine just handles the mechanics of sending and receiving messages.  So source selection and filtering would be part of clock control.

However, it would also be possible to make another subsystem in between clock control and the protocol engine, which would be focused on source selection.  What do you think?

Doug

________________________________
From: Miroslav Lichvar <[email-masked]>
Sent: Monday, April 27, 2020 12:53 AM
To: Daniel Franke <[email-masked]>
Cc: Doug Arnold <[email-masked]>; NTP WG <[email-masked]>; Tal Mizrahi <[email-masked]>
Subject: Re: [Ntp] Modular NTP

--
Miroslav Lichvar

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 27 Apr 2020 14:08:36 -0600

I like this idea.

One of the issues I was thinking about at IETF 102 was some sort of attestation system (possibly based on peer-generated reputations) for a loose confederation of a pool with dynamic admission.

This would allow for the “trustworthiness” of the source to be a factor in the selection.

> On Apr 27, 2020, at 9:24 AM, Doug Arnold <[email-masked]> wrote:
>