Subject: [Ntp] [NTP] Draft "On Implementing Time"

From: [email-masked]
Date: Mon, 13 Nov 2017 10:21:52 +0100

Hello all,

I have just given a read to the "On Implementing Time" draft (
https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes
). 
There are a few issues that I'd like to raise.

(1) Vocabulary (technical): use of the term "time"
- Description: I take issue with not explaining what the document means 
when in uses the term "time", specifically "a <property> time", when 
properties like continuous, monotonic (separate issue, see below) are 
assigned. In these cases, it is heavily implied the "a time" is supposed 
to be a function (because the cited properties are usually applied to 
functions), but this is never stated, which I find problematic. For 
example, I still need to figure out what the domain and co-domain of the 
function are supposed to be. Naively I would assume that the co-domain is 
a subset (probably implementation specific) of "int" or "float". I would 
then assume that the domain is... well, "actual" time. Which brings me to 
my next issue with the used terminology: "time" becomes an overloaded 
term, it represents the abstract heuristic concept and then also some kind 
of function from this concept to a machine-appropriate value set.
- Suggested remedy: edit the terminology to be consistent,
- Specific suggestions for the remedy (even if this is deemed 
insufficient, I still strongly advocate trying to implement the remedy in 
some other way):
  -- "Time" remains as the abstract heuristic concept (and is not 
explained in the document).
  -- The kind of value that a machine can read and communicate (for 
example a timestamp) could be called a "clocktime". The document should 
state this somewhere. How exactly "clocktime" is realized (int, float, 
...) is implementation specific. The document might or might not go into 
that detail.
  -- The function that maps the current "time" to a "clocktime" is called 
a "clock". The document should state this somewhere.

(2) Vocabulary (more editorial, with some technical implications): use of 
the term "continuous"
- Description: since the co-domain of a "clock" (current term in the 
document is "time", see above) is necessarily a discrete set, the notion 
of "continuity" causes some problems, since the usual definitions don't 
easily apply (basically, the function always has "jumps" in it, due to the 
discrete nature of the co-domain).
- Suggestion: clean up the terminology and make it consistent, OR just 
dumb it down.
- Specific suggestion (clean-up): have "continuous" mean that the function 
does not exhibit jumps greater than the "resolution" of the co-domain. Use 
epsilon-delta definition, but loosen it to epsilon greater than or equal 
to <resolution>. Note that this might require quite a lot of thougfht to 
get right.
- Specific suggestion (dumb-down): simply state that "continuous" shall 
mean that the function "has no substantial jumps", or something along 
those lines.

(3) Vocabulary (technical and editorial): use of the term "monotonic" 
- Description: Although I acknowledge that in 2.1, the draft gives a(n 
implicit) definition of what it refers to when it uses the term 
"monotonic" (i.e. "continuous and strictly monotonically increasing"), I 
still do not like it. The term monotonic has a specific meaning in 
mathematics (to be either monotonically increasing or monotonically 
decreasing), and I simply find it confusing to overload the term with a 
meaning that, on the one hand, adds a property (also means "continuous" 
now) and, on the other hand, removes one of the original options (cannot 
mean "monotonically decreasing" anymore). Stating that this terminology is 
"sometimes" used really doesn't help the issue, since I find it to be an 
obvious crutch notation.
- Suggested remedy: come up with another term X instead of monotonic and 
replace the sentence <Such a time is sometimes called a "monotonic time."> 
by <We call such a time a [X] time.">, modulo any potential changes in 
vocabulary for the term "time".

If there is interest (if the current editors think it would make things 
easier and not harder), I guess I would offer to work on the draft as an 
additional editor.
In any case, I think it is great that this kind of foundational work is 
being done, and I think it is worth investing quite a lot of time and 
thought, since there seems to be a severe lack of foundational content on 
issues.like these

Best regards,
Kristof

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 15 Nov 2017 13:44:42 +0800

Hi,

A few more comments to the authors of "On Implementing Time".

Thanks for taking the time to write this draft. It is quite an interesting
topic, and very challenging to cover.

I believe the draft needs quite a bit of work. The first step should be to
clearly define the scope of the document – this should be done very
carefully, and preferably in the abstract.

 More detailed comments:

·         In some cases the text describes a certain implementation method
and implies  that this is “the way” to do it. We will have to be very
careful to distinguish between “the way it works” / “the way it sometimes
works” / “the way we suggest it should work”.

·         Please clearly describe the target audience and the scope of the
draft. The text should be very careful and clear, preferably in the
Abstract. After reading the drat, it feels like it applies to timekeeping
in PCs using NTP (not sure which OSs).
Specifically:

o   Is the draft applicable to software or to hardware implementations?

o   Is the draft applicable only to NTP or also to PTP and other protocols?

o   Does the draft describe functionality that is specific to the
architecture of a PC, or is it relevant for other devices as well (phones,
IoT devices, switches, routers, base stations, synchrophasors)?

o   Is the draft applicable to a specific operating system, or does the
described functionality work exactly the same in all operating systems?

o   Is the draft applicable only to physical machines, or also to virtual
machines?

·         The intended status should be Informational.

·         It seems necessary to discuss the following terms, and explain
how they relate to the current content of the draft:

o   System time.

o   Real time clock (RTC).

o   Tick.

·         Does the term ‘real time’ in the document refer to the value of
the Real Time Clock (RTC)? If it is, please explain it in the document.

·         Does the term ‘raw time’ refer to a specific hardware timer in
the CPU? Perhaps the Time Stamp Counter (TSC)? If that is the case, please
explain in the draft. This notion of raw time is not necessarily
implemented in other network devices such as switches/routers.

·         “the rate of advance of time is slowed down or sped up slightly
until it approaches the reference time again” – that may be true in some
implementations, but certainly not in all of them. Please phrase the text
more carefully.

·         More generally, the distinction between raw time, adjusted raw
time and real time – please explain in detail where this is implemented –
in which CPU architectures, and in which OSs. It is certainly not
applicable to all devices that use clocks, right?

·         Throughout the document - the term ‘drift’ should be well defined
and used correctly. I would recommend to use Mill’s definition [Mills] of
drift (the first derivative of the frequency). This is often confused with
‘skew’, which is the frequency difference between two clocks (i.e., the
first derivative of the offset).
[Mills] Mills, David L. "Improved algorithms for synchronizing computer
network clocks." IEEE/ACM Transactions on networking 3.3 (1995): 245-254.

·         Please note that the definition of ‘real time’ in the literature
(e.g., [Lamport]) is different than the way you used this term. I would
recommend to adopt Lamport’s terminology, or at least to cite it.

o   “Real Time. An assumed Newtonian time frame that is not directly
observable.

o   Clock Time. The time that is observed on some clock.”

[Lamport] Lamport, Leslie, and P. Michael Melliar-Smith. "Synchronizing
clocks in the presence of faults." Journal of the ACM (JACM) 32.1 (1985):
52-78.

·         The term ‘timestamp’ is most commonly used as a single word in
the RFC series (rather than time stamp).

·         “In order to reference the same point across multiple systems, it
needs to be stated in wall time.” -
The word ‘needs’ is too strong here. Indeed a timestamp often represents
the wall time, but not always (see TCP for example).

·         “However, in a network environment, the uncertainty introduced by
differing transmission times is likely larger than that introduced by clock
drift.”
- it is hard to understand this sentence without a context. It looks like
you have a specific application in mind, but the application is not clear
to the reader. I would suggest to present this sentence as an example, not
as a general rule.

·         Sections 4 and Section 5 – I strongly recommend to explicitly
specify which implementations these sections refer to. That would make
these sections well-scoped.

·         Security considerations – should be extended. Specifically, I
would suggest to add something like: “A system that uses a time
distribution protocols may be affected by the security aspects of the time
protocol. The security considerations of time protocols in general are
discussed in  [RFC7384].”

·         Typos:

o   s/componsated/compensated/

o   s/adjested/adjusted/

Cheers,

Tal.

On Mon, Nov 13, 2017 at 5:21 PM, <[email-masked]> wrote:

> https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes).
>
> assigned. In these cases, it is heavily implied the "a time" is supposed to
> be a function (because the cited properties are usually applied to
> function are supposed to be. Naively I would assume that the co-domain is a
> subset (probably implementation specific) of "int" or "float". I would then
> assume that the domain is... well, "actual" time. Which brings me to my
> next issue with the used terminology: "time" becomes an overloaded term, it
> represents the abstract heuristic concept and then also some kind of
> function from this concept to a machine-appropriate value set.
> state this somewhere. How exactly "clocktime" is realized (int, float, ...)
> is implementation specific. The document might or might not go into that
> detail.
> document is "time", see above) is necessarily a discrete set, the notion of
> "continuity" causes some problems, since the usual definitions don't easily
> apply (basically, the function always has "jumps" in it, due to the
> epsilon-delta definition, but loosen it to epsilon greater than or equal to
> <resolution>. Note that this might require quite a lot of thougfht to get
> right.
> mean that the function "has no substantial jumps", or something along those
> lines.
>
> implicit) definition of what it refers to when it uses the term "monotonic"
> (i.e. "continuous and strictly monotonically increasing"), I still do not
> like it. The term monotonic has a specific meaning in mathematics (to be
> either monotonically increasing or monotonically decreasing), and I simply
> find it confusing to overload the term with a meaning that, on the one
> hand, adds a property (also means "continuous" now) and, on the other hand,
> removes one of the original options (cannot mean "monotonically decreasing"
> anymore). Stating that this terminology is "sometimes" used really doesn't
> help the issue, since I find it to be an obvious crutch notation.
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>
>

---

From: Willem Toorop <[email-masked]>
Date: Thu, 16 Nov 2017 16:57:56 +0800

Op 15-11-17 om 13:44 schreef Tal Mizrahi:
> Thanks for taking the time to write this draft. It is quite an
> interesting topic, and very challenging to cover.
> 
>  
> 
> I believe the draft needs quite a bit of work. The first step should be
> to clearly define the scope of the document – this should be done very

Thank you Tal,

Yes, during the working-group discussion it became already very clear
that our current wording is way too generic.  Maybe we should already be
more clear about scope in the title.  We'll try to come up with a better
one.

This draft came from our study on the impact of security weaknesses of
NTP on DNS and DNSSEC.  We observed that DNS resolver caches (bind,
unbound, knot, powerdns) were vulnerable to the attacks, and we also
noticed that this could be mitigated if cache implementation would have
been done differently.

Other improvement were also apparent (such as scheduling of I/O events).
We assume that the patterns used in writing this software are not unique
and that other software might have the same flaws.

During our study it became also clear that we needed clear definitions
to describe these matters adequately.

So our intention with the document was to
1. provide advise to implementors of software that has to practice
caching and scheduling and other timing related matters.
2. provide clear definitions to be able to convey this advice.
   (it is ironic these were confusing to the experts ;)

We will work with the workgroup to come up with better definitions and
also to reference the canonical literature when making statements;
starting with your and Kristof's comments.

Thanks for that.  We will start incorporating them and come up with an
adapted draft.

Cheers,
-- Willem

> 
>  
> 
>  More detailed comments:
> 
> ·         In some cases the text describes a certain implementation
> method and implies  that this is “the way” to do it. We will have to be
> very careful to distinguish between “the way it works” / “the way it
> sometimes works” / “the way we suggest it should work”.
> 
> ·         Please clearly describe the target audience and the scope of
> the draft. The text should be very careful and clear, preferably in the
> Abstract. After reading the drat, it feels like it applies to
> timekeeping in PCs using NTP (not sure which OSs).
> Specifically:
> 
> architecture of a PC, or is it relevant for other devices as well
> (phones, IoT devices, switches, routers, base stations, synchrophasors)?
> 
> o   Is the draft applicable only to physical machines, or also to
> virtual machines?
> 
> ·         Does the term ‘real time’ in the document refer to the value
> of the Real Time Clock (RTC)? If it is, please explain it in the document.
> 
> the CPU? Perhaps the Time Stamp Counter (TSC)? If that is the case,
> please explain in the draft. This notion of raw time is not necessarily
> ·         “the rate of advance of time is slowed down or sped up
> slightly until it approaches the reference time again” – that may be
> true in some implementations, but certainly not in all of them. Please
> phrase the text more carefully.
> 
> time and real time – please explain in detail where this is implemented
> – in which CPU architectures, and in which OSs. It is certainly not
> ·         Throughout the document - the term ‘drift’ should be well
> defined and used correctly. I would recommend to use Mill’s definition
> [Mills] of drift (the first derivative of the frequency). This is often
> confused with ‘skew’, which is the frequency difference between two
> clocks (i.e., the first derivative of the offset).
> ·         Please note that the definition of ‘real time’ in the
> literature (e.g., [Lamport]) is different than the way you used this
> term. I would recommend to adopt Lamport’s terminology, or at least to
> cite it.
> 
> clocks in the presence of faults." Journal of the ACM (JACM) 32.1
> (1985): 52-78.
> 
> ·         “In order to reference the same point across multiple systems,
> it needs to be stated in wall time.” -
> ·         “However, in a network environment, the uncertainty introduced
> by differing transmission times is likely larger than that introduced by
> clock drift.”
> - it is hard to understand this sentence without a context. It looks
> like you have a specific application in mind, but the application is not
> clear to the reader. I would suggest to present this sentence as an
> example, not as a general rule.
> 
> distribution protocols may be affected by the security aspects of the
> time protocol. The security considerations of time protocols in general
> are discussed in  [RFC7384].”
> 
> ·         Typos:
> 
> On Mon, Nov 13, 2017 at 5:21 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hello all,
> 
>     I have just given a read to the "On Implementing Time" draft
>     (https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes
>     <https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes>).
> 
>     - Description: I take issue with not explaining what the document
>     means when in uses the term "time", specifically "a <property>
>     time", when properties like continuous, monotonic (separate issue,
>     see below) are assigned. In these cases, it is heavily implied the
>     "a time" is supposed to be a function (because the cited properties
>     are usually applied to functions), but this is never stated, which I
>     find problematic. For example, I still need to figure out what the
>     domain and co-domain of the function are supposed to be. Naively I
>     would assume that the co-domain is a subset (probably implementation
>     specific) of "int" or "float". I would then assume that the domain
>     is... well, "actual" time. Which brings me to my next issue with the
>     used terminology: "time" becomes an overloaded term, it represents
>     the abstract heuristic concept and then also some kind of function
>     from this concept to a machine-appropriate value set.
>     insufficient, I still strongly advocate trying to implement the
>     remedy in some other way):
>     example a timestamp) could be called a "clocktime". The document
>     should state this somewhere. How exactly "clocktime" is realized
>     (int, float, ...) is implementation specific. The document might or
>     might not go into that detail.
>       -- The function that maps the current "time" to a "clocktime" is
>     called a "clock". The document should state this somewhere.
> 
>     (2) Vocabulary (more editorial, with some technical implications):
>     use of the term "continuous"
>     document is "time", see above) is necessarily a discrete set, the
>     notion of "continuity" causes some problems, since the usual
>     definitions don't easily apply (basically, the function always has
>     "jumps" in it, due to the discrete nature of the co-domain).
>     - Suggestion: clean up the terminology and make it consistent, OR
>     just dumb it down.
>     - Specific suggestion (clean-up): have "continuous" mean that the
>     function does not exhibit jumps greater than the "resolution" of the
>     co-domain. Use epsilon-delta definition, but loosen it to epsilon
>     greater than or equal to <resolution>. Note that this might require
>     quite a lot of thougfht to get right.
>     - Specific suggestion (dumb-down): simply state that "continuous"
>     shall mean that the function "has no substantial jumps", or
>     something along those lines.
> 
>     - Description: Although I acknowledge that in 2.1, the draft gives
>     a(n implicit) definition of what it refers to when it uses the term
>     "monotonic" (i.e. "continuous and strictly monotonically
>     increasing"), I still do not like it. The term monotonic has a
>     specific meaning in mathematics (to be either monotonically
>     increasing or monotonically decreasing), and I simply find it
>     confusing to overload the term with a meaning that, on the one hand,
>     adds a property (also means "continuous" now) and, on the other
>     hand, removes one of the original options (cannot mean
>     "monotonically decreasing" anymore). Stating that this terminology
>     is "sometimes" used really doesn't help the issue, since I find it
>     to be an obvious crutch notation.
>     - Suggested remedy: come up with another term X instead of monotonic
>     and replace the sentence <Such a time is sometimes called a
>     "monotonic time."> by <We call such a time a [X] time.">, modulo any
>     potential changes in vocabulary for the term "time".
> 
>     If there is interest (if the current editors think it would make
>     things easier and not harder), I guess I would offer to work on the
>     draft as an additional editor.
>     In any case, I think it is great that this kind of foundational work
>     is being done, and I think it is worth investing quite a lot of time
>     and thought, since there seems to be a severe lack of foundational
>     content on issues.like these
> 
> 
>     Best regards,
>     Kristof
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ntp>
> 
> 
> 
>

---

From: Martin Hoffmann <[email-masked]>
Date: Thu, 16 Nov 2017 10:20:57 +0100

Hi Kristof,

> There are a few issues that I'd like to raise.

Many thanks for reading the document and sharing your thoughts!

> means when in uses the term "time", specifically "a <property> time",
> when properties like continuous, monotonic (separate issue, see
> below) are assigned. In these cases, it is heavily implied the "a
> time" is supposed to be a function (because the cited properties are
> usually applied to functions), but this is never stated, which I find
> problematic. For example, I still need to figure out what the domain
> and co-domain of the function are supposed to be. Naively I would
> assume that the co-domain is a subset (probably implementation

The draft already somewhat distinguishes between the two "classes" of
definitions--wall time on the one side and the three remaining ones on
the other, even if it doesn’t call out that distinction. I think we can
make this more obvious by simply using the word "clock" instead of
"time" for the three concrete representations of time available to a
system.

We’ve been debating to what extent we should discuss the, for lack of a
better term, philosophical background of time, keeping in mind our
target audience. On the one hand, this is all very important and
interesting, on the other hand, we don’t want to scare away people
starting out with a lengthy treatise. 

> shall mean that the function "has no substantial jumps", or something
> along those lines.

My gut-feeling is that, again, with respect to the intended audience,
we could probably keep this relatively informal. As a consequence, we
should probably avoid the term "continuous" altogether. Perhaps
the introduction of drift can move up to the introduction of the raw
clock, discussing how the time perceived by the system and expressed
via the raw clock differs from passage of wall time. It just felt
better to do this as part of the introduction of adjusted raw time
from a narrative perspective.

> increasing"), I still do not like it.

This mention comes from the "monotonic clock" defined as one of the
clock types in POSIX with a rather vague definition (leaving it
unclear whether it refers to a raw clock or adjusted raw clock in
our sense). As a result of that appearance, many people seem to use the
term. I guess this warrants a longer discussion than just a drive-by
mention.

> draft as an additional editor.

Many thanks for your kind offer. We’d be delighted to welcome you as
an additional editor!

Kind regard,
Martin

---

From: [email-masked]
Date: Thu, 16 Nov 2017 17:08:28 +0100

Hi,

I will add some additional to Tal's and Kristof's comments to the draft 
"draft-aanchal-time-implementation-guidance-00".

Clause 2:
- UTC is not a time but a time scale
- UTC is steered towards UT1 and not solar time. See e.g. Sec. 4.6 of the 
BCP (https://tools.ietf.org/html/draft-ietf-ntp-bcp-05#section-4.6).
- The explanation of UTC seems to me much too over-simplified. This should 
be dropped. Instead you could quote the definition of UTC given by the 
BIPM:
"The UTC scale is adjusted from International Atomic Time (TAI) by the 
insertion of leap seconds according to the advice of the International 
Earth Rotation and Reference Systems Service (IERS) to ensure approximate 
agreement with the time derived from the rotation of the Earth." 
[Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ]. 

Alternatively you could quote the ITU recommendation 
"Coordinated Universal Time (UTC): The time-scale maintained by the Bureau 
International des Poids et Mesures (BIPM) and the International Earth 
Rotation and Reference Systems Service (IERS), which forms the basis of a 
coordinated dissemination of standard frequencies and time signals." 
[Citation: ITU-R TF.686-3:(12/2013)].

Clause 2.2
- As Tal already mentioned, a clear definition of the used nomenclature is 
necessary. Tal mentioned Dave's definition, which of course is correct. 
But, since this documents aims to give general guidance in the field of 
the timing, I suggest to adjust your language to the ITU recommendations 
ITU-R TF.686-3:(12/2013). Hence, 
- using "frequency difference" if you speak of clocks whose frequencies 
differ,
- using "frequency drift" if you mean the change of a clock's frequency 
over time (the first derivative of the frequency).

I would recommend not to use NTP as an example in 2.2 since NTP does not 
provide a mean to synchronize the frequency of a clock. Instead it adjust 
the clock's frequency in order to synchronize the clock's time. That is a 
different goal and is therefore not comparable.

You could use the term "Syntonization" [ITU-R TF.686-3:(12/2013)], if you 
mean the adjustment of the clock's frequency.

PTP does provide a syntonization mode. Thus, you might use PTP as an 
example in this section.

Clause 2.3.
I don't like the term "Real time". It sounds like Real Time Clock (RTC) 
which you would call "Raw time" (if I understand it right).

This in short. I hope this might be useful.

Dieter

"ntp" <[email-masked]> schrieb am 16.11.2017 10:20:57:

> Von: Martin Hoffmann <[email-masked]>
> An: [email-masked]
> Kopie: [email-masked]
> Datum: 16.11.2017 10:21
> Betreff: Re: [Ntp] [NTP] Draft "On Implementing Time"
> Gesendet von: "ntp" <[email-masked]>
> 
> Hi Kristof,
> 
> the other, even if it doesn?t call out that distinction. I think we can
> We?ve been debating to what extent we should discuss the, for lack of a
> interesting, on the other hand, we don?t want to scare away people
> Many thanks for your kind offer. We?d be delighted to welcome you as
> an additional editor!
> 
> Kind regard,
> Martin
>

---

From: Steve Allen <[email-masked]>
Date: Thu, 16 Nov 2017 09:35:37 -0800

> [Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ].

BIPM is currently responsible for the underlying atomic time scale,
but the BIPM has never held the definition of UTC.  The definition of
UTC has always been managed by the ITU-R (previously known as the
CCIR).

Before the name UTC was applied this was in
CCIR Recommendation 374 (1963)
CCIR Recommendation 374-1 (1966)
The broadcast time signals were changed to use leap seconds by
CCIR Recommendation 460 (1970)
and the name UTC was first applied in
Recommendation 460-1 (1974)

The current definition of UTC is
ITU-R Recommendation TF.460-6 (2002-02)
http://www.itu.int/rec/R-REC-TF.460/en

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m

---

From: [email-masked]
Date: Fri, 17 Nov 2017 01:49:25 +0100

Hi Steve,

thanks for this information. Good point.

I didn't claim that the BIPM owns the definition of UTC. But it is the 
organisation that is in charge to coordinate and maintain UTC (as also 
stated in TF.460-6). Therefore, at least in my opinion, it is a valid 
source of reference just like ITU-R TF.460-6 (2002-02). I pointed to ITU-R 
TF.686-3:(12/2013) because it is a glossary and contains defintion of 
further terms that are used in this draft. Also ITU-R TF.686-3:(12/2013) 
itself refers to ITU-R TF.460 in its definition of UTC. So in my opinion 
both recommendations are applicable.

Dieter

"ntp" <[email-masked]> schrieb am 16.11.2017 18:35:37:

> Von: Steve Allen <[email-masked]>
> An: NTP WG <[email-masked]>
> Datum: 16.11.2017 18:35