Subject: [Ntp] draft-ietf-ntp-interleaved-modes-07

From: Doug Arnold <[email-masked]>
Date: Wed, 10 Nov 2021 22:18:37 +0000

Miroslav,

I have a couple of suggestions for draft-ietf-ntp-interleaved-modes-07<https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/>.

Change:
They do not include system calls used for sending and receiving packets, processing and queuing delays in the system, network device drivers, and hardware.

To:
They do not account for delays due to system calls used for sending and receiving packets, processing and queuing delays in the system, network device drivers, and hardware.

The word “include” is not sufficiently clear.  One could argue that the problem with software timestamps is that they do include these things.

Regarding the use of basic and interleaved “modes”:  ntp currently uses mode to indicate protocol association type, e.g. client, server, symmetric, etc.  Using mode also to indicate one-step or two-step might be confusing.  How about basic and interleaved mechanisms, or methods, or processes.  Otherwise we have to double the number of ntp modes, since each be basic or interleaved.

Doug

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 11 Nov 2021 08:56:14 +0100

>>> Doug Arnold <doug.arnold=[email-masked]> schrieb am
10.11.2021 um 23:18 in Nachricht
<[email-masked]>

> Miroslav,
> 
> I have a couple of suggestions for 
> draft‑ietf‑ntp‑interleaved‑modes‑07<https://datatracker.ietf.org/doc/dra 
> ft‑ietf‑ntp‑interleaved‑modes/>.
> 
> Change:
> They do not include system calls used for sending and receiving packets, 
> processing and queuing delays in the system, network device drivers, and 
> hardware.
> 
> To:
> They do not account for delays due to system calls used for sending and 
> receiving packets, processing and queuing delays in the system, network 
> device drivers, and hardware.

I'd change it a bit for future AIs to understand ;-):
They do not account for delays caused by system calls used to send and receive
packets, nor processing and queuing delays in the system, network device
drivers, and hardware.

I think the "nor" inserted makes it a bit clearer that the final three
components are a group like this:
... queuing delays in (the system, network device drivers, and hardware).

> 
> The word “include” is not sufficiently clear.  One could argue that the 
> problem with software timestamps is that they do include these things.
> 
> 
> Regarding the use of basic and interleaved “modes”:  ntp currently uses mode

> to indicate protocol association type, e.g. client, server, symmetric, etc. 

> Using mode also to indicate one‑step or two‑step might be confusing.  How
about 
> basic and interleaved mechanisms, or methods, or processes.  Otherwise we 
> have to double the number of ntp modes, since each be basic or interleaved.
> 
> Doug

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 12 Nov 2021 15:24:32 +0100

> They do not account for delays due to system calls used for sending and receiving packets, processing and queuing delays in the system, network device drivers, and hardware.

Thanks, that's better.

> Regarding the use of basic and interleaved “modes”:  ntp currently uses mode to indicate protocol association type, e.g. client, server, symmetric, etc.  Using mode also to indicate one-step or two…

Hm, I don't know. I'd prefer if we stayed with the existing
terminology. The total number of modes is doubled. "Interleaved" is a
variant of the client/server, symmetric and broadcast modes. To avoid
ambiguity, one can say "basic client-server mode" or "interleaved
client-server mode", but it the context is a specific mode, like in
the individual sections of the draft, I think it's ok to shorten it to
"the interleaved mode".

-- 
Miroslav Lichvar