Re: [Roll] MRHOF draft-06 comments

[Philip Levis <[e-mail]>]

On Mar 7, 2012, at 3:38 AM, Dario Tedeschi wrote:

> Below are some comments and questions on a few areas in the latest MRHOF draft that seem a little confusing.
> 
> In section 3.3. "
>    MRHOF uses this Rank value to compute the Rank it associates with the
>    path through each member of the parent set. The Rank associated with
>    a path through a member of the parent set is the maximum of the
>    corresponding calculated Rank value from above and that node's
>    advertised Rank plus MinHopRankIncrease.
> "
> 
> Which of the following formulae match the above description?
>    PathRank = RankValue + AdvRank + MinHopRankIncrease
>    PathRank = MAX(RankValue, AdvRank) + MinHopRankIncrease
>    PathRank = MAX(RankValue, (AdvRank + MinHopRankIncrease))

The last one. I'll clarify in the next revision. I appreciate your pointing out the lack of clarity in the current text.

> Where:
>    PathRank is the Rank associated with a path through a member of the parent set
>    AdvRank is a node's advertised Rank
>    RankValue is the Rank value taken from Table 1 in the draft.
> 
> Perhaps adding something like one of the above formulae would help in describing exactly how a node arrives at its own Rank?
> 
> In section 3.3. "
>    A node sets its Rank to the maximum of three values:
>    ...
> "
> Could the above be simplified/removed by just saying that members in the parent set meet the following condition:
>    ( DAGRank(PathRank) < DAGRank(thisNode.AdvRank) )

I don't think so. Among other things, the node decides on its advertised rank based on the parent set. Or are you saying that the parent set at execution i should be affected by the node's advertised rank at execution i-1? Or that a node picks a desired DAGRank and then sets its parent set accordingly?

The reason this part of the specification becomes complicated is because it's possible for Rank and metric values to diverge due to MinHopRankIncrease. I.e., let's say that MinHopRankIncrease is 512. This corresponds to an ETX of 4 (metric value 512). If you have a 3 hop path whose links have an ETX of 1, then the metric value will be 512 but the Rank will be 2048. Reconciling ETX and MinHopRankIncrease isn't difficult, but it starts to be weird on metrics like Node Energy. Hence the recommendation at the end about the relationship of MinHopRankIncrease and metrics.


> Where:
>    thisNode.AdvRank is a joining node's current Rank (starting at infinity before having joined a DODAG).
> The above condition allows a parent's path Rank to vary up to an upper bound implicitly set by MinHopRankIncrease, before a node might exclude that parent from the set and possibly choose another preferred parent.
> 
> In section 3.4. "
>                            This value is the path cost of the member of
>   the parent set with the highest path cost.  Thus, while
>   cur_min_path_cost is the cost through the preferred parent, a node
>   advertises the highest cost path from the node to the root through a
>   member of the parent set.  The value of the highest cost path is
>   carried in the metric container corresponding to the selected metric
>   when DIO messages are sent.
> "
> It's quite strange that the advertised path cost could be one associated with a member in the parent set that isn't currently in the path to the root. In my view, this could quite easily distort a DODAG away from its optimum, because nodes may advertised costs that are more pessimistic than need be. Surely once a node has selected a preferred parent, it should advertise the cost of that path through that parent, since that is the real and optimal cost to the root.

There is a good reason for this, which is in line with the RPL specification: MaxRankIncrease. MaxRankIncrease creates a tension between advertising the Rank associated with the path through the preferred parent and requiring a new DODAG iteration. If a node advertises the Rank associated with the path through its preferred parent, but the next best member of the parent set is more than MaxRankIncrease greater in path length, then if the preferred parent fails the node can no longer route. So a node can advertise a conservative Rank which gives it flexibility in selection of a preferred parent in case of failure. 

There is also a tension between the size of the parent set and how conservative the advertised Rank is. For example, let's say MaxRankIncrease is very large, such that nodes can move down in the DODAG very freely, depending on the data path to detect possible routing loops. Then a node can maintain a parent set of size 1, its preferred parent, and advertise a very accurate Rank value.

> Reading the section further, MRHOF with ETX is exclude from the above requirement. Was that intentional?

No -- can you point me to the exact text which leads you to this conclusion, so I can fix it?

Thank you for your comments -- very helpful!

Phil