Subject: Re: [Roll] comments on mrhof draft

From: Matteo Paris <[email-masked]>
Date: Wed, 23 Feb 2011 16:34:07 -0500

Hi Omprakash, thanks for your work on the mrhof draft.  I have a few comments:

In Parent Selection (3.2), what happens when the path cost 
corresponding to the new candidate preferred parent is greater than 
cur_min_path_cost?  My reading is that it is selected as the new 
preferred parent, and cur_min_path_cost is increased accordingly.  Is 
that correct?  When I tested that strategy I ran into a frequent 
counting to infinity problem.  I addressed the problem by adding a 
hysteresis factor in the upward direction, and always sending a DIS 
before increasing rank.  I'd be happy to elaborate if you'd like.

The draft does not discuss the parent set other than the preferred 
parent.  Does it assume any neighbor with rank less than our rank 
(cur_min_path_cost in the case of ETX) is a parent?  Perhaps it 
should mention this explicitly.

When is parent selection re-computed?  Section 3.2 says "After 
computing the path cost for all the candidate neighbors ... a node 
selects the preferred parent."  I think a statement similar to the 
one in section 3.1 for re-computing path costs would be clearer, for 
example: "Parent selection should be re-computed each time (1) the 
path cost of an existing parent changes (2) a neighbor is added to or 
removed from the parent set."

I think the draft would benefit from a discussion of ETX.  There are 
many ways of actually measuring (estimating) ETX, each with 
tradeoffs.  There are parameter settings such as window size, and 
averaging methodologies to consider.  Implementers need to be aware 
of these issues.  The roll-routing-metrics draft does not discuss 
them, so the OF draft seems like a good place.

Thanks,
Matteo

At 9:43 PM -0800 2/16/11, Omprakash Gnawali wrote:
>Dear ROLL WG,
>
>I am in the process of updating the minimum rank with hysteresis
>objective function draft. We had discussions related to needing to
>bolster of0 (null metric of) with link qualities and the suggestion
>was to just use mrhof(etx). It also turns out some people thought they
>were implementing null metric OF but they were implementing
>mrhof(etx).
>
>Here is a link to the draft:
>http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-02
>
>This OF converts the metrics into rank using hard coded constants to
>scale. If people got a chance to work on metric implementations and
>use something like mrhof, it will be good to incorporate those
>suggestions to improve the draft.
>
>I will appreciate your comments.
>
>Thanks.
>
>- om_p
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 25 Feb 2011 01:27:18 -0800

Thanks for the comments. Some notes inline.

On Wed, Feb 23, 2011 at 1:34 PM, Matteo Paris <[email-masked]> wrote:
> In Parent Selection (3.2), what happens when the path cost corresponding to
> the new candidate preferred parent is greater than cur_min_path_cost?  My
> reading is that it is selected as the new preferred parent, and
> cur_min_path_cost is increased accordingly.  Is that correct?  When I tested
> that strategy I ran into a frequent counting to infinity problem.  I
> addressed the problem by adding a hysteresis factor in the upward direction,
> and always sending a DIS before increasing rank.  I'd be happy to elaborate
> if you'd like.

I would like more information. Parent switch threshold did not help?

> The draft does not discuss the parent set other than the preferred parent.
>  Does it assume any neighbor with rank less than our rank (cur_min_path_cost
> in the case of ETX) is a parent?  Perhaps it should mention this explicitly.

Yes, potentially any node with a rank lower by at least the switching
threshold is a parent. I can be more explicit about this.

> When is parent selection re-computed?  Section 3.2 says "After computing the
> path cost for all the candidate neighbors ... a node selects the preferred
> parent."  I think a statement similar to the one in section 3.1 for
> re-computing path costs would be clearer, for example: "Parent selection
> should be re-computed each time (1) the path cost of an existing parent
> changes (2) a neighbor is added to or removed from the parent set."

Good suggestion. I will be explicit about when parent selection is
triggered. We can describe the trigger saying after any path cost
recompute, perform parent selection. I think that covers the same
condition.

> I think the draft would benefit from a discussion of ETX.  There are many
> ways of actually measuring (estimating) ETX, each with tradeoffs.  There are
> parameter settings such as window size, and averaging methodologies to
> consider.  Implementers need to be aware of these issues.  The
> roll-routing-metrics draft does not discuss them, so the OF draft seems like
> a good place.

JP had a comment a while ago asking to limit the things that are not
essential for interoperation so it does not include those discussions.
Maybe, a good place for those discussions would be rpl-recommendations
draft that I posted a few days ago?

- om_p