Dear Thomas,

thanks so much for your quick action. See inline our responses. We need
further discussion at the WG meeting.

---

issue: confused about time source
severity: low

The "Global Time Source" section starts with a paragraph which suggests a
particular node in the network has a global time knownledge.
Yet, the paragraph after, is seems as if only the JRC can play that role.

XV: the JRC is the initial source of time. and from it another URI can be
announced for future resynch.

That is entirely OK, but I would just merge those paragraphs and say that
the JRC has some global time knowledge.
XV: the intro states that the JRC has the notion of global time and how it
achieves it is out of the scope of the spec.
Anyways we will review the text so it is absolutely clear.

---

issue: synchronization between JRC and network
severity: high

When the JRC is co-located with the DAGroot, it's "easy" for it to konw
both the network and global time with nanosecond accuracy.
But the JRC can be a logical entity locate far from the 6TiSCH network.
Something in the text needs to state that, and probably say that how the
JRC sync to the 6TiSCHnetwork is out of scope.

XV: Section 2 states:
The Join Registrar/Coordinator (JRC) acts as the
   global time information source for a node when it joins.  How the JRC
   obtains such global time information is out of scope of this
   specification.

But I see your point, you want as well to mention that the JRC needs to
know the ASN and hence it needs to synch to it. We add this sentence as
well.



---

issue: PTP?
severity: low

Fig. 1 contains "PTP", which isn't reference anywhere in the text AFAICT.

PTP is IEEE1588 for example as mentioned before the figure 1.

---

issue: byte ordering
severity: low

Section "Global Time Extension to the Join Response" defines the fact that
"The 5-byte ASN is carried in network byte order".
But isn't byte ordering something that is already specified by CBOR?

XV: Yes it is. Should we remove that then?

---

issue: reference of time mapping
severity: medium

The specification basically defines a format to say "at ASN X, global time
is Y".
In theory, what ASN is used is irrelevant, so I wuoldn't mandate for that
to be "at which the CoAP Response (e.g, Join Response) is processed".
You could also simply specify what time it was at ASN 0.

XV: Yes. We consider that idea. This saves 5B. Could the timeslot length be
changed during network lifetime? if so we need then to keep track of it.

---

issue: confusion about 3 timestamps
severity: medium

The format defined in "Global Time Extension to the Join Response" contains
3 timestamps: ASN, timestamp in seconds, timestamp in ps.
I don't understand the description of the latter two. Why not simply "at
the beginning of that ASN, this is the epoch (possibly split in s and ps)"

XV: this is the NTP format. The seconds timestamp expresses seconds since
1st of Jan 1900. The fraction timestamp expresses hundreds of pico-seconds
for the last second.
ASN is the reference. It can be elided if we relate it to a well known
point in time (e.g, ASN 0)
We need an era counter as well. As per NTP. Since the seconds field wraps
every 136 years.

---

issue: freshness of time?
severity: medium

I don't understand the logic of adding a "the number of days of freshness
of the assigned global time information".
Time is the one thing that advanced at 60min per hour, no matter what :-)
What's the idea behind this?
The term "freshness" for sure doesn't seem the right one.

XV: this is the lease time. A global time source node can specify for how
long the time it has leased to the node is considered to be fresh.
this is to enforce a resynh if needed. For example to make the node resynch
and discover if a leap_second is coming.

---

issue: default freshness value
severity: low

after the following sentence:
Optionally, an unsigned word lease value indicating the number of days of
freshness of the assigned global time information.
you should specify that no value means infinite freshness


XV: thanks. we do that.
---

issue: what about drift?
severity: high

the specification is pretty obsessed about leap seconds, a cool thing for
sure, but not the most important problem.
IMO, the most important problem is that the root of the TSCH network drifts
relative to UTC.
You have 2 options:
    - you say the root is always sync'ed, i.e. 0 drift. That's hard.
    - you provide a mechanism which accounts for drift in your format
    - you leave everything as-is, but force your nodes to refresh their
time periodically

To be discussed.
XV: We agree. That is the role of the lease. A node can poll periodically
the time service to keep clock updated. We would like to discuss further
before adding content to the spec.
---

issue: unit and width confusion for leap second handling
severity: low

A 16-bit unsigned integer containing an offset in **days** to the beginning
of the day (0 h UTC) when the next leap second must be applied.
I assume **days** should be seconds?

If that is the case, there are 86400 seconds in a day, a 16-bit number will
not be enough.

Are leap seconds always applied at exact second boundaries?

XV: A leap second is announced at most 6 month in advance to when it will
happen. The correction to be applied is usually to add or remove 1 second at
the end of the day when the leap second needs to be applied. This is the
same idea as NTP uses. When a node synchronizes to the
global time source it gets the leap_second option if known (none
otherwise). When the day the leap second needs to be applied is reached,
the nodea
applies the specified correction at the end of the day. having 23:59:58 or
23:59:60 as the last second of the day.

---

issue: why era?
severity: med

Why have an era counter that confuses everything? Why not simply a 64-bit
epoch value?

XV: The era counter in NTP is a 32bit. We use 8bit instead as we think this
spec can be updated after 136*256 years.
The seconds field wraps every 136 years. It will wrap in Feb 2036 moving
from era 0 to era 1.
makes sense?

---

issue: fraction field?
severity: low

THere is some inconsistency in naming of fields. The term "fraction" is
confusing. The field is described as:

A 32-bit unsigned integer containing the number of picoseconds elapsed
after the last entire second at the beginning of the timeslot at which the
CoAP Response (e.g. Join Response) is processed.

but also as

The fraction field provides synchronization precisions in the order of
hundreds of picoseconds.

why hundreds of picoseconds, and not picoseconds?

XV: this is the same approach as for NTP. The fraction represents 1/2^32
seconds giving a 232-ps resolution.

---

issue: reorganizing Global Time Extension to the Join Response
severity: low

The last 3 paragraphs of that section should be merged into the bullet list
of fields.

XV: thanks. We had doubts if this was more clear or was adding too much
text to the presentation of the fields. We will consider that.


2018-03-01 21:58 GMT+01:00 Thomas Watteyne <thomas.watte...@inria.fr>:

> As promised :-)
>
> draft-vilajosana-6tisch-globaltime-00 provides an important feature for a
> synchronized network.
> It is a simple solution; the draft is easy to follow.
>
> A number of issues below:
>
> ---
>
> issue: confused about time source
> severity: low
>
> The "Global Time Source" section starts with a paragraph which suggests a
> particular node in the network has a global time knownledge.
> Yet, the paragraph after, is seems as if only the JRC can play that role.
> That is entirely OK, but I would just merge those paragraphs and say that
> the JRC has some global time knowledge.
>
> ---
>
> issue: synchronization between JRC and network
> severity: high
>
> When the JRC is co-located with the DAGroot, it's "easy" for it to konw
> both the network and global time with nanosecond accuracy.
> But the JRC can be a logical entity locate far from the 6TiSCH network.
> Something in the text needs to state that, and probably say that how the
> JRC sync to the 6TiSCHnetwork is out of scope.
>
> ---
>
> issue: PTP?
> severity: low
>
> Fig. 1 contains "PTP", which isn't reference anywhere in the text AFAICT.
>
> ---
>
> issue: byte ordering
> severity: low
>
> Section "Global Time Extension to the Join Response" defines the fact that
> "The 5-byte ASN is carried in network byte order". But isn't byte ordering
> something that is already specified by CBOR?
>
> ---
>
> issue: reference of time mapping
> severity: medium
>
> The specification basically defines a format to say "at ASN X, global time
> is Y".
> In theory, what ASN is used is irrelevant, so I wuoldn't mandate for that
> to be "at which the CoAP Response (e.g, Join Response) is processed".
> You could also simply specify what time it was at ASN 0.
>
> ---
>
> issue: confusion about 3 timestamps
> severity: medium
>
> The format defined in "Global Time Extension to the Join Response"
> contains 3 timestamps: ASN, timestamp in seconds, timestamp in ps.
> I don't understand the description of the latter two. Why not simply "at
> the beginning of that ASN, this is the epoch (possibly split in s and ps)"
>
> ---
>
> issue: freshness of time?
> severity: medium
>
> I don't understand the logic of adding a "the number of days of freshness
> of the assigned global time information".
> Time is the one thing that advanced at 60min per hour, no matter what :-)
> What's the idea behind this?
> The term "freshness" for sure doesn't seem the right one.
>
> ---
>
> issue: default freshness value
> severity: low
>
> after the following sentence:
> Optionally, an unsigned word lease value indicating the number of days of
> freshness of the assigned global time information.
> you should specify that no value means infinite freshness
>
> ---
>
> issue: what about drift?
> severity: high
>
> the specification is pretty obsessed about leap seconds, a cool thing for
> sure, but not the most important problem.
> IMO, the most important problem is that the root of the TSCH network
> drifts relative to UTC.
> You have 2 options:
>     - you say the root is always sync'ed, i.e. 0 drift. That's hard.
>     - you provide a mechanism which accounts for drift in your format
>     - you leave everything as-is, but force your nodes to refresh their
> time periodically
> To be discussed.
>
> ---
>
> issue: unit and width confusion for leap second handling
> severity: low
>
> A 16-bit unsigned integer containing an offset in **days** to the
> beginning of the day (0 h UTC) when the next leap second must be applied.
> I assume **days** should be seconds?
>
> If that is the case, there are 86400 seconds in a day, a 16-bit number
> will not be enough.
>
> Are leap seconds always applied at exact second boundaries?
>
> ---
>
> issue: why era?
> severity: med
>
> Why have an era counter that confuses everything? Why not simply a 64-bit
> epoch value?
>
> ---
>
> issue: fraction field?
> severity: low
>
> THere is some inconsistency in naming of fields. The term "fraction" is
> confusing. The field is described as:
>
> A 32-bit unsigned integer containing the number of picoseconds elapsed
> after the last entire second at the beginning of the timeslot at which the
> CoAP Response (e.g. Join Response) is processed.
>
> but also as
>
> The fraction field provides synchronization precisions in the order of
> hundreds of picoseconds.
>
> why hundreds of picoseconds, and not picoseconds?
>
> ---
>
> issue: reorganizing Global Time Extension to the Join Response
> severity: low
>
> The last 3 paragraphs of that section should be merged into the bullet
> list of fields.
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajos...@uoc.edu <usu...@uoc.edu>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
­
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to