I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
.
Document: draft-ietf-6lo-deadline-time-04
Reviewer: Dale R. Worley
Review Date: 2019-05-05
IETF LC End Date: 2018-12-24
IESG Telechat date: 2019-05-16
Summary:
This draft is on the right track but has open issues, described
in the review.
There are a number of comments about the exposition that are listed
below. I'm sure these can be resolved by the authors. But there is a
serious problem with the last 5 paragraphs of section 8,
"Synchronization Aspects": they seem to assume that the time
representation for the Deadline Time and Origination Time values will
wrap around, that is, that the representation is the absolute value
modulo the size of the field. In addition, there is a lack of clarity
how the new epoch point will be chosen after the value wraps around.
This seems to contradict the earlier sections of the document which
speak of the values as if they are always to be considered as absolute
values on a time scale selected by the TU field, viz., either the NTP
time scale (in seconds) or the network's ASN numbering.
It's possible that four of these paragraphs are intended to only apply
to the use of TU = 00, the NTP time scale, and perhaps that usage of
the header is understood not to be completely specified yet.
However, the final paragraph discusses TU = 10 (the ASN time scale),
and claims that wrapping of the DT value is intended. This is
relevant to current implementations.
Some sort of resolution of this is needed; as the document stands it
is self-inconsistent. One possible resolution would be to omit these
paragraphs.
Nits/editorial comments:
3. 6LoRHE Generic Format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- length -->
Figure 1: 6LoRHE format
o Length: Length of the 6LoRHE expressed in bytes, excluding the
first 2 bytes. This enables a node to skip a 6LoRHE if the Type
is not recognized/supported.
o Type (variable length): Type of the 6LoRHE (see Section 7)
There is a detail of this description which I don't like, and the
problem seems to be inherited from draft-ietf-roll-routing-dispatch,
viz., there is a variable-length field in the 6LoRHE, but it's not
named or described as such in that figure. The correct way to
describe the header is:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | ... data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- length -->
Figure 1: 6LoRHE format
o Length: Length of the 6LoRHE expressed in bytes, excluding the
first 2 bytes. This enables a node to skip a 6LoRHE if the Type
is not recognized/supported.
o Type: Type of the 6LoRHE (see Section 7)
o Data (Length bytes): Additional data.
--
4. Deadline-6LoRHE
Since the OTD is a delta the
length of the OTD field (i.e., OTL) will require fewer bits than the
length of the DT field (i.e., DTL).
Strictly speaking, it will usually require fewer bits. OTOH, it will
often require far fewer bits. Also, given the placement of "(i.e.,
OTL)" there is an awkwardness regarding whether "OTL" is an
abbreviation for "the length of the OTD field" or an abbreviation for
"the OTD field". Conveniently, even a difference of 1 in the length
fields is significant, since they are in units of 4 bits. So perhaps
a better wording is:
Since the OTD is a delta, the length (i.e., OTL) of the OTD field
will often be less than the length (i.e., DTL) of the DT field.
--
5. Deadline-6LoRHE Format
o TU (2 bits) : Indicates the time units for DT and OTD fields. The
encoding for the DT and OTD fields MUST always use the same time
units and precision.
* 00 : Time represented in seconds and fractional seconds
* 01 : Reserved
* 10 : Network ASN
* 11 : Reserved
I think these could be made more explicit:
o TU (2 bits) : Indicates the time unit and zero point for DT and
OTD fields. The encoding for the DT and OTD fields MUST always
use the same time units and precision.
* 00 : Time represented in seconds and fractional seconds,
with 0 being the epoch of the NTP time scale,
00:00:00 1 January 1900 UTC [RFC5905].
* 01 : Reserved
* 10 : Network ASN
* 11 : Reserved
Although there should be a warning that the NTP time scale has a
discontinuity whenever there is a leap second, so further
specification will be needed before the NTP time scale can be used in
delay-critical networks.
--
o Binary Pt (6 bits) : If zero, the number of bits of the integer
part the DT is equal to the number of bits of the fractional part
of the DT. if nonzero, the Binary Pt is a signed integer
determining the position of the binary point within the value for
the DT.
* If BinaryPt value is positive, then the number of bits for the
integer part of the DT is increased by the value of BinaryPt,
and the number of bits for the fractional part of the DT is
correspondingly reduced. This increases the range of DT.
* If BinaryPt value is negative, then the number of bits for the
integer part of the DT is decreased by the value of BinaryPt,
and the number of bits for the fractional part of the DT is
correspondingly increased. This increases the precision of the
fractional seconds part of DT.
It seems like this could be stated much more succinctly. Also, the
signed integer format for Binary Pt needs to be specified. E.g.,
o Binary Pt (6 bits): A signed, twos-complement integer giving
the placement of the binary point in the DT field:
the number of integral bits is 2*(DTL+1) + BinaryPt
the number of fractional bits is 2*(DTL+1) - BinaryPt
--
The scaling of the OTD value should be made explicit, as I see it as
an opportunity for errors:
o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits
giving the Origination Time as a negative offset from the DT value.
The rightmost bit of OTD has the same units as the rightmost bit
of DT.
Then again, it's possible that the working group intended a different
scaling rule for OTD.
For completeness, there should be a statement that if OTL+DTL is even,
then there will be a one-hex digit pad at the end of the value.
8. Synchronization Aspects
The document supports time representation of the deadline and
origination times carried in the packets traversing through networks
of different time zones having different time synchronization
mechanisms. For instance, in a 6TiSCH network where the time is
maintained as ASN time slots, the time synchronization is achieved
through beaconing among the nodes as described in [RFC7554]. There
could be 6lo networks that employ NTP where the nodes are
synchronized with an external reference clock from an NTP server.
The specification of the time synchronization method that need to be
followed by a network is beyond the scope of the document.
The number of hex digits chosen to represent DT, and the portion of
that field allocated to represent integer number of seconds,
determines the meaning of t_0, i.e., the meaning of DT == 0 in the
chosen representation.
It's not clear to me why "the portion of that field allocated to
represent integer number of seconds" affects the meaning of the zero
DT value. Doesn't DT == 0 always represent the zero point of the time
scale selected by TU, regardless of the value of BinaryPt?
If DTL == 0, then there are only 4 bits that
can be used to count the time units, so that DT == 0 can never be
more than 16 time units in the past. This then requires that the
time synchronization between sender and receiver has to be tighter
than 16 time units. If the binary point were moved so that all the
bits were used for fractional time units (e.g., fractional seconds or
fractional ASNs), the time synchronization requirement would be
correspondingly tighter.
This paragraph is unclear to me. Presumably, the network will be
running for a long time (many time units) so the DT values will get
quite large. I suspect that the first sentence was to start "If OTL
== 1 ..." and then OT can never be more than 16 time units in the
past. In practice, this means that time synchronization has to be
tighter than 16 time units, or receivers will start randomly receiving
packets with DT in the past or OT in the future.
A 4-bit field for DT allows up to 16 hex digits, which is 64 bits.
That is enough to represent the NTP [RFC5905] 64-bit timestamp
format, which is more than enough for the purposes of establishing
deadline times. Unless the binary point is moved, this is enough to
represent time since year 1900.
If the binary point is not moved, this format can represent time from
year 1900 to year 2036, which is less than the expected lifetime of
this protocol. But BinaryPt >= 1 allows representing time until year
2172, which should be adequate.
For example, suppose that DTL = 0b0000 and the DT bits are split
evenly; then we can count up to 3 integer seconds. In that case t_0
would be the most recent second of the current minute that has
t mod 4 == 0. In other words, t_0 could be 0, 4, 8, 12, 16, ..., 52,
or 56 seconds since the start of the most recent minute. The
networks have to be synchronized well enough to ensure detection of
overrun, and therefore to know which of those values is the correct
value for t_0. This is the hardest case.
If DT = 3 and the DT bits are again split evenly, then we can count
up to 4,096 seconds. t_0 would be the start of the most recent hour.
Where does this come from? I see no specification of DT containing
(deadline_time mod 2^(number of bits)). If a certain number of hex
digits is not large enough to express the time since the zero point of
the chosen time scale, DTL needs to be increased.
Also, it's entirely unclear why, if truncating the high-order bits of
DT was defined, the beginning of each minute or hour would be chosen
as zero points.
For TU = 0b00, the time units are seconds. With DTL == 15, and
Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00
UTC. The resolution is then (2 ^ (- 32)) seconds, which is the
maximum possible.
BinaryPt can represent -32, which with DTL == 15, allows a resolution
of 2^-64 seconds (albeit for only 1 second after the zero point).
This time format wraps around every 2^32 seconds,
which is roughly 136 years.
There being no provision for time values wrapping around, the only
solution would be to move the binary point to the right.
For other choices of DTL and the Binary
Pt, the value of t_0 (i.e., the meaning of DT == 0) needs to be
established by means out of scope of this document.
For TU = 0b10, the time units are ASNs. The start time is relative,
and updated by a mechanism out of scope for this document. With 10
ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for
the ASN to wrap around. Typically, the number of hex digits
allocated for TU = 0b10 would be less than 15.
[END]