Comments on draft-ietf-6tisch-minimal-17
5.1.1. Rank Computation
The Rank computation is described at [RFC6552], Section 4.1. A
node's Rank (see Figure 4 for an example) is computed by the
following equations:
R(N) = R(P) + rank_increment
rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease
There's clearly something omitted from this computation, since there's
no specification for computing the rank of the (a?) root node. (The
above formula can't be applied since a root node has no "R(P)".)
6.1. Value of the Join Metric Field
In
case that the network uses RPL, the Join Metric of any node
(including the DAG root) MUST be set to DAGRank(rank)-1. According
to Section 5.1.1, DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is
compliant IEEE802.15.4's requirement of having the root use Join
Metric = 0.
The items "DAGRank(rank)" and "DAGRank(rank(0))" aren't clear from
this context. If I understand correctly from skimming RFC 6550,
"rank" is an attribute of each node and DAGRank() is a function that
can operate on "rank". To make this clear without requiring one to
have learned RFC 6550 first, it would help to say
In case that the network uses RPL, the Join Metric of any node
(including the DAG root) MUST be set to DAGRank(rank)-1, where rank
is the node's RPL rank.
I'm having more trouble finding a meaning for "DAGRank(rank(0))". Is
"rank(0)" suppose to mean "rank when rank = 0"? Or is it an
abbreviation for "the rank of the root node" (which requires that "0"
somehow be the name of the root node)?
6.5. Hysteresis
Per [RFC6719], the PARENT_SWITCH_THRESHOLD
SHOULD be set to 192 when ETX metric is used (in the form 128*ETX),
the recommendation for this document is to use
PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is
((3*ETX)-2)*minHopRankIncrease, or a proportional value.
This sentence is confusing. I think it contains two separate
recommendations, and if so, it would be clearer if they were
separated:
Per [RFC6719], the PARENT_SWITCH_THRESHOLD
SHOULD be set to 192 when ETX metric is used (in the form 128*ETX).
The recommendation in this document is to use
PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is
((3*ETX)-2)*minHopRankIncrease, or a proportional value.
Assuming that change is made, there are some further improvements that
could be made:
The sentences could be constructed so that the conditions under which
they were operative ("when ETX metric is used (in the form 128*ETX)"
and "the metric being used is ((3*ETX)-2)*minHopRankIncrease" are
placed in front, rather than placing in front the statements of where
the recommendations come from.
The phrase "in the form 128*ETX" is unclear. Is that a restatement of
"the ETX metric" (in which case it's redundant)? Is it a variety of
"the ETX metric" (in which case, it's critical and should be changed
to "the 128*ETC form of the ETC metric")? Is is some sort of
description of "192"?
What phrase "or a proportional value" applies to is unclear.
7.3. Recommended Settings
+-------------------------+-------------------+
| Parameter | RECOMMENDED Value |
+-------------------------+-------------------+
| MAX_EB_DELAY | 180 |
+-------------------------+-------------------+
| NUM_NEIGHBOURS_TO_WAIT | 2 |
+-------------------------+-------------------+
| PARENT_SWITCH_THRESHOLD | 640 |
+-------------------------+-------------------+
| NUM_UPPERLAYER_PACKETS | 1 |
+-------------------------+-------------------+
| MAX_JOIN_TIME | 300 |
+-------------------------+-------------------+
Of these settings, MAX_EB_DELAY and MAX_JOIN_TIME are quantities that
have units. As such, this figure cannot be interpreted in isolation
since it does not specify the units involved. For instance, the
statement that MAX_EB_DELAY is measured in seconds is only in section
6.2, and the units for MAX_JOIN_TIME are not stated anywhere.
I recommend that these two quantities be conceptualized as having
units, and so the table would be presented
+-------------------------+------------------------+
| Parameter | RECOMMENDED Value |
+-------------------------+------------------------+
| MAX_EB_DELAY | 180 secs |
+-------------------------+------------------------+
| NUM_NEIGHBOURS_TO_WAIT | 2 |
+-------------------------+------------------------+
| PARENT_SWITCH_THRESHOLD | 640 |
+-------------------------+------------------------+
| NUM_UPPERLAYER_PACKETS | 1 |
+-------------------------+------------------------+
| MAX_JOIN_TIME | 300 secs |
+-------------------------+------------------------+
and revising 6.2 to say
For example, after having received the first EB, a node MAY listen
for at most MAX_EB_DELAY until it has received EBs from
NUM_NEIGHBOURS_TO_WAIT distinct neighbors.
8. IANA Considerations
This document requests no immediate action by IANA.
Are there non-immediate actions that can be requested of IANA by a
document? I suspect that "immediate" is redundant.
Appendix A. Examples
This section contains several example packets. Each example contains
(1) a schematic header diagram, (2) the corresponding bytestream, (3)
a description of each of the IEs that form the packet.
As far as I can tell, none of the examples contains a schematic header
diagram, but only the detailed structure of the IEs.
Dale