[Roll] Review of rpl-03

["Anders Jagd" <anders.jagd at ekasystems.com>]

Roll mailing list,

I recently started monitoring this mailing list as well as catching up on
RPL, specifically draft-ietf-roll-rpl-03. Through this mail, I would like to
offer my "first time reader" feedback.

I am aware of various mail threads addressing some of the below topics. I
have tried not to repeat comments/questions made by others, and it is
generally not my intention to reopen old debates. However, being new to this
list, I am less than 100% in sync with all previous discussions, and thus
run the risk of repeating old comments. In these cases, please feel free to
refer me to the "FAQ" :)

BTW, my name is Anders Jagd, and I work for Eka Systems.

Here goes:

Section 1.1

319  each instantiation of the protocol to be optimized in terms of
320  required code space.  It must be noted that RPL is not restricted

  Suggest change to "required code space and other limited computation
resources"

Section 2

407  each DAG that a node is a member of, the node will maintain a
408  set of DAG siblings.  If a node is a member of multiple DAGs

  Suggest change to "may maintain a set of DAG siblings"

Section 3.3.1

  Should RPL discourage "soft greediness", where a node initially joining a
DAG chooses to enter at a higher rank than it could have done ?

Section 3.3.4

1263  has subsequently cleaned up the state.  This loop happens when a no-
1264  DAO was missed till a heartbeat cleans up all states.  The DAO loop

  General comment: Document includes some "forward references".
  In this example "no-DAO" has not been defined previously.

Section 5.1.1

1545  Length:  8-bit unsigned integer set to 4 when there is no suboption.
1546  The length of the option (including the type and length fields

  "4" does not match Figure 1 (Figure one has 4.5 "8 octet units")

1662  The following values MUST NOT change during the propagation of RA-DIO
1663  messages outwards along the DAG: Type, Length, G, DAGPreference,
1664  DAGDelay and DAGID.  All other fields of the RA-DIO message are
1665  updated at each hop of the propagation.
 
  List not complete - what about D, A, Sequence number, DIOIntDouble,
DIOIntMin ?

Section 5.1.1 (general)

  - Do we need 8 bit for sequence number ?

  - Do we need 8 bit for DAGPreference ?

  - Is one byte enough for DAGRank ?

  - Do we need BootTimeRandom, NodePref at all, and if so, do they need to
be so big ? 

I understand the collision scenario with associated "risk window", but do we
need this tie-breaker, as opposed to simply discarding everything within
risk window regardless of any tie-breaker ? If the answer is "yes, we need
it", then should we at least consider making it less costly (less bits ?)

  - Can we come up with less "expensive" PathDigest ? 

Meaning less than 32 bit, and something less computationally intensive than
CRC. Also, do we need PathDigest at all, given that we have the "D" bit to
trigger DA ?

  - DAGRank: Is rank of root "typically 1" or "always 1" ? 

Document not quite consistent. Since a root could "exaggerate" it's rank, I
assume "typically" is correct, but 5.3.1 seems to indicate otherwise:

2040  1.   A node that does not have any DAG parents in a DAG is the root
2041       of its own floating DAG.  It's rank is 1.  A node will end up in

Section 5.1.1.1.5

1803  The Destination Prefix suboption has an alignment requirement of
1804  4n+1.  Its format is as follows:

  "4n+1" is a bit unclear to me.
      
Section 5.2.2

1913  it is expected to produce a different and unique DAGID for each of
1914  the multiple DAGs.

  Suggest change: "expected to" to be replaced with "MUST"

Section 5.3.1

2099  rank, or whatever metrics the LLN cares to use.  A node may jump
 
  Suggest change: "whatever metric the LLN cares to use" replaced by
"metrics defined by the OCP"

Section 5.3.2.2

2227  If the other DAG is now empty of candidate parents, then
2228  directly follow SRC into the new DAG by adding it as a DAG

  Could the node have another choice (jumping to a parent in a third DAG) ?

2252  described in Section 5.3.  When a node adds another node to its set
2253  of candidate parents, the node becomes attached to the DAG through
2254  the parent node.

  Not exactly - the new node simply becomes another "candidate parent"

Section 5.3.3

2302  overhead and saving energy consumption (which is of utmost
2303  importance for battery-operated nodes).

  Suggest to delete "(which is of .....)"
  (Not to say it is not true, but may not belong in section 5)

2344  (2^DIOIntervalMin)ms.  The default value is
2345  DEFAULT_DIO_INTERVAL_MIN.

  Suggest to clarify that the default at this point is simply given a
"name". This (I assume) to facilitate later reference to this when actual
values are discussed.

Section 5.3.4.1.  Resetting the Trickle Timer

  It wasn't obvious to me at first that this is all done in order to limit
the amount of localized traffic/congestion due to broadcasts from parent
nodes (i.e. "make children be quiet if their parents are talking a lot", if
I understand it correctly). May want to clarify for sake of readability.

Section 5.7

2490  preferred DAG parent and its rank.  At that time any
2491  remaining DAG parents of greater rank than this node must

  Shouldn't it be "greater than or equal rank" ?

Section 5.7.1

2534  A new DAG is discovered upon receiving a RA message with or without a
2535  DIO.  The node joins the DAG by selecting the source of the RA

  It took me a while to realize this must be coming from a "non RPL" node.
  Suggest to clarify for readability (incl. the whole "rank 0" concept).

2553  The duration of the DAG Hop timer depends on the DAG Delay of the new
2554  DAG and on the rank of candidate parent that triggers it: (candidates
2555  rank + random) * candidate's DAG_delay (where 0 <= random < 1).  It
2556  is randomized in order to limit collisions and synchronizations.

  I understand "random" may be important in order to manage nodes that
somehow get in sync. But I suggest "random" may also be
difficult/"expensive" to implement (sure, it doesn't say how random it has
to be, but still). I believe I understand the intention behind making the
timer depend on the "candidate rank that would be achieved in DAG"; in the
sense that it allows for other/better parents to be discovered within this
time. However, could we somehow avoid "random" ?

How is this impacted by the ongoing thread regarding use of "Sequence
number" vs "Hop timer" ?

Section 5.7.3.  Collision

  As discussed above, can this "risk window" be handled less expensively ?
  (less bits in RA-DIO for "tie-breaker" or no "tie-breaker" at all)

Section 5.7.4

2623  A node is instable when it is prepared to shortly replace a set of
2624  DAG parents in order to jump to a different DAGID.  This happens

  Suggest to rephrase (node jumps to a different DAG, not a different DAGID)

Section 5.8.1

2695  o  The OF scans all the candidate neighbors on the possible
2696     interfaces to check whether they can act as an attachment router

  Suggest to replace "attachment router" with "router"

2702  o  The OF computes self's rank by adding the step of rank to that
2703     candidate to the rank of that candidate.  The step of rank is
2704     estimated as follows:

  Suggest to replace "estimated" with "based upon"

2757  *  Candidate neighbors that are of worse rank than self are
2758     ignored
2759	
2760  *  Candidate neighbors of a better rank than self (non-siblings)
2761     are preferred

  For completeness: There is no description of handling of "Candidate
neighbors of same rank" (siblings)

  Also, suggest to replace "worse rank" with "higher rank".

Section 5.8.2

2766  corresponding to OCP codepoint 0.  This is a very simple reference to
2767  help design more complex Objective Functions.  In particular, the

  This makes it sound like OCP-0 is merely a "template". It is of course
more than that, being the "default" OCP. 

2773  This document specifies a default objective metric, called OF0, and
2774  using the OCP 0.  OF0 is the default objective function of RPL, and

  Is OFO "default objective metric" or "default objective function" (acronym
matches neither)

Section 5.8.2.2

2819  4.   If none are grounded then a DAG with a more preferred
2820       administrative preference is better.

  Is this DAGPreference from RA-DIO ? (unclear to me)

Section 5.9.2.1

3183  o  A counter of retries to count how many RA-DIO messages were sent
3184     on the interface to the advertising neighbor without reachability
3185     confirmation for the prefix.

  At this point it may not be quite clear to the reader that this is related
to requesting a DA but not receiving it (if I understand correctly). 
  Suggest to clarify.

Section 5.9.2.4

3369  o  Destination advertisement operation stopped: All entries in the
3370     abstract lists are freed.  All the routes learned from NA-DAO
3371     messages are removed.

  Why would a node stop DA operation once commenced ?

Section 7.1.2

3677  A RPL implementation SHOULD allow configuring the following routing
3678  protocol parameters, which are further described in Section 5.1.1:

  I don't think PathDigest belongs in this list (nothing to configure, it is
by definition initialized to zero by root)

3715  DAG Hop Timer:  A RPL implementation MUST provide the ability to

  Wouldn't it be more precise to describe configuration of DagDelay, since
"Hop Timer" is based on DagDelay.

Section 7.1.5

3771  o  The Remove timer

  "Remove timer" or "DestroyTimer" ? (Document seems to be inconsistent)

/Anders (Jagd)