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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
