Re: [Roll] Review of rpl-03

[Tim Winter <wintert at acm.org>]

Thanks Anders,

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

Regards,

-Tim

Anders Jagd wrote:
> 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 ?
Indeed- A, SeqNum, DIO... should be unchanged.  Nodes should be free to
tweak `D', e.g. from modifying their parent set
> 
> Section 5.1.1 (general)
> 
>   - Do we need 8 bit for sequence number ?
> 
>   - Do we need 8 bit for DAGPreference ?
I would agree probably not.  256 levels of DAG preference does seem a bit
excessive in practice   ;)

> 
>   - 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 ?
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...

> 
>   - 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.
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')
>       
> 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)
Yes- we will make it more clear

> 
> 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.
> 
In -04 we will go for some FSM embodiment that should hopefully make this
much more clear.

> 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)
> 
> 
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>