Subject: [Roll] Review of rpl-03

From: "Anders Jagd" <[email-masked]>
Date: Wed, 14 Oct 2009 16:29:41 -0400

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)

---

From: Tim Winter <[email-masked]>
Date: Wed, 14 Oct 2009 21:14:28 -0400

Thanks Anders,

We will work to incorporate your feedback into the upcoming -04.  Some more
comments inline below:

Regards,

-Tim

>   List not complete - what about D, A, Sequence number, DIOIntDouble,
Indeed- A, SeqNum, DIO... should be unchanged.  Nodes should be free to
tweak `D', e.g. from modifying their parent set
>   - Do we need 8 bit for DAGPreference ?
I would agree probably not.  256 levels of DAG preference does seem a bit
excessive in practice   ;)

> CRC. Also, do we need PathDigest at all, given that we have the "D" bit to
Hmm... I think you may be onto something.  One thing to consider is that
`PathDigest' could be much longer lived as compared to the D bit, e.g. in
case of loss a modified PathDigest can be observed over several sequence
numbers, while a `D bit' would typically only remain set during one NA-DAO
cycle.  But there is definitely something here to consider...

>   "4n+1" is a bit unclear to me.
This is obsolete, wrong, and will be updated (we had added a control octet
for preference anyway that padded the option header out to a multiple of 4
bytes and removed the need for `+1')
>   Is this DAGPreference from RA-DIO ? (unclear to me)
Yes- we will make it more clear

> to requesting a DA but not receiving it (if I understand correctly). 
In -04 we will go for some FSM embodiment that should hopefully make this
much more clear.

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Anders Jagd" <[email-masked]>
Date: Thu, 15 Oct 2009 00:04:07 -0400

Tim,

True, so I guess 'D' bit is not the solution. It still seems to me that 32
bit + CRC calculation is a pretty steep price to pay to reliably signal
downstream that something has changed upstream. Something should be doable
with a byte or less. For example:

Each node could maintain a local "sequence number" (a few bits), which it
inserts into RA-DIO messages. If a change is detected, this is signaled to
the child nodes by incrementing the sequence number.

A child node, upon seeing a change in parent sequence number, may now take
appropriate action, including incrementing its own sequence number for
further outward/downstream signaling.

A few bit should suffice. If say 4 bits are in use, a child would have to
miss 15 consecutive sequence number changes (and receive the 16th) for it to
miss out on the message of change.

/Anders

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 15 Oct 2009 11:17:50 +0200

Hi Anders,

I very much agree with your comments on Section 5.1.1.  My general
feeling is that we are including way to much information in the base
RA-DIO option. The RA header is already 16bytes + 32bytes by RA Prefix
advertised. Right now the RA-DIO option is 36 bytes (without
sub-options). 

> - Do we need 8 bit for DAGPreference ?
[Mathilde] The DAGPreference seems not to be mentioned much in the
current draft. Do we really need a DAGPreference at all? Can't a node
base it's decision to join a DAG on the OCP only?

> - 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 ?)
[Mathilde] I agree. Having 32 bits in every RA just to avoid unlikely
collisions is in my opinion not needed. I would remove the
BootTimeRandom and the NodePreference. I like your approach of
discarding everything within the risk window.

> 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 ?
[Mathilde] My impression is that we can remove the PathDigest. The only
place where the PathDigest is mentioned (outside of the RA-DIO format)
is Section 5.9.2.1.  
"Destination advertisements may also be scheduled for sending when the
PathDigest of the RA-DIO message has changed". 
This seems a weak reason to had an overhead of 32bit in every RA-DIO

Concerning the DIOIntervalDoubling and the DIOIntervalMin, I would
propose to use default values. Here too, in my opinion, there is no need
to include these values in every RA. If an implementation wants to do
so, I would propose a sub-option.

Best,
Mathilde