Subject: [Ntp] I-D Action: draft-ietf-ntp-packet-timestamps-01.txt

From: [email-masked]
Date: Mon, 05 Mar 2018 10:49:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Guidelines for Defining Packet Timestamps
        Authors         : Tal Mizrahi
                          Joachim Fabini
                          Al Morton
	Filename        : draft-ietf-ntp-packet-timestamps-01.txt
	Pages           : 22
	Date            : 2018-03-05

Abstract:
   This document specifies guidelines for defining binary packet
   timestamp formats in networking protocols at various layers.  It also
   presents three recommended timestamp formats.  The target audience of
   this memo includes network protocol designers.  It is expected that a
   new network protocol that requires a packet timestamp will, in most
   cases, use one of the recommended timestamp formats.  If none of the
   recommended formats fits the protocol requirements, the new protocol
   specification should specify the format of the packet timestamp
   according to the guidelines in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-01
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-packet-timestamps-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-packet-timestamps-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked]
Date: Wed, 21 Mar 2018 00:37:35 +0100

Hi Tal, Joachim  and Al,

thanks for the draft. I think it covers a very interesting topic and its 
language is very clear.

I have two questions:

1. Regarding Sec. 2.2: I appreciate the definition of timestamp accuracy 
and precision. However I am wondering why in case of timestamp accuracy 
your language uses the "mean" as a very specific location metric whereas 
in case of the timestamp precision you are not using a specific dispersion 
metric. Is this done by purpose?

2. I'm wondering if you may include a control field that quantifies - if 
the data is available or calculable - the uncertainty with which a device 
is able to synchronize to its source clock to.

Dieter

-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Zeitverteilung mittels IP
QM-Verantwortlicher der Stelle IT
Bundesallee 100 
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: [email-masked]

Von:    [email-masked]
An:     <[email-masked]>
Kopie:  [email-masked]
Datum:  05.03.2018 19:49
Betreff:        [Ntp] I-D Action: draft-ietf-ntp-packet-timestamps-01.txt
Gesendet von:   "ntp" <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Joachim Fabini <[email-masked]>
Date: Wed, 21 Mar 2018 08:57:12 +0100

Hi Dieter,

many thanks for your comments and proposals. I'll focus on your second
comment below:

On 2018-03-21 00:37, [email-masked] wrote:
> in case of the timestamp precision you are not using a specific
> dispersion metric. Is this done by purpose?
> 
> the data is available or calculable - the uncertainty with which a
> device is able to synchronize to its source clock to.

Thanks for pointing this out. Just to get your comment right: does it
concern the (perhaps misleading) naming of the precision field in
https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-01#section-7.3.3
that we proposed to store this kind of uncertainty information?
Precision as defined in 2.2. is definitely related to uncertainty (which
we did not define - todo).
Or do you propose to explicitly differentiate between and store a) the
uncertainty that affects any of a clock's potential synchronization
sources/paths and b) the clock's current (aggregated/estimated)
precision/uncertainty?

The precision field's proposed subfields are meant to target exactly
this topic but the wording is currently not very, hmh, precise (pun
intended). Quoting 7.3.3:
"Value: Subfields: 1.  Estimated Precision (in terms of 10^(-x)), 2.
Maximum Error, 3.  Reference (Absolute: UTC, TAI ..., Relative: to
specific clock, needs reference to clock ID

Subfield 1 is intended to store the clock's estimated uncertainty (an
example of a similar implementation is, e.g., IEEE C37.118.2-2011,
Section 6.2.2, Table 4). In addition we thought about including in (3)
the reference (synchronized to UTC or synchronized relative to another
reference clock) to support some additional degree of flexibility.

The current proposal of the control field is in an early stage - this is
why we limited the current control field to a summary of features that
we believe to be useful. We hope on substantial feedback from the group
for adding all useful features before we go into the coding of details.
Thanks again for starting this discussion.

best regards
Joachim

---

From: [email-masked]
Date: Wed, 21 Mar 2018 11:33:58 +0100

Hi Joachim,

thanks for the answers.

Regarding my first comment: I just was wondering why the definition of the 
timestamp accuracy also defines how to quantify it by explicitly using the 
term "Mean", whereas the explanation of the term timestamp precision 
"only" provides a qualitative definition. Perhaps you can also provide a 
qualitative definition of the term timestamp accuracy. For example 
according to ITU-R TF.686-3 "Closeness of the agreement between the result 
of a measurement and the true value of the measurand." Than both timestamp 
attributes are defined qualitatively which at least for me would be more 
consistent. But than you might have to add an sub-section "Timestamp 
Accuracy" in 7.3.

Regarding the second comment. Thanks for the clarification. Yes, I agree 
you can use a subfield for the  uncertainty in the timestamp precision 
metric.  Perhaps this could be a separate subfield which would require a 
uncertainty consideration in accordance to the Guide to the expression of 
uncertainty in measurement (GUM). This is a very interesting work and 
would possibly help to establish traceability to a reference time.

Dieter

"Joachim Fabini" <[email-masked]> schrieb am 21.03.2018 
09:04:05:

> Von: "Joachim Fabini" <[email-masked]>
> An: [email-masked], [email-masked]
> Datum: 21.03.2018 09:04
> Betreff: Re: [Ntp] Antwort: I-D Action: draft-ietf-ntp-packet-
> timestamps-01.txth
> 
> Hi Dieter,
>