Subject: [Roll] mrhof last call comments

From: Omprakash Gnawali <[email-masked]>
Date: Wed, 27 Apr 2011 15:38:50 -0700

Here is how I addressed these comments that were provided during the last call.

1. The draft seems specific to link metrics, does not talk about node metrics.

=> The draft now mentions node metrics in the right places and
describes how to use it to compute the path cost.

2. Why constrain MRHOF to metric minimization? With minimal change, it
can be used to find paths with metric maximization.

=> There is a new subsection that describes how MRHOF can also be used
with metric maximization. But it notes that MRHOF is not required to
support this feature.

3. MinHopRankIncrease should be set to 1.

=> There is a new subsection that mentions this explicitly.

4. Single parent or a set of parents?

=> MRHOF now supports a set of parents. The draft describes how one
selects this set.

5. How to compute rank when there are multiple parents?

=> Compute rank corresponding to the worst parent in the parent set.

6. What metric is required for MRHOF?

=> ETX

7. How to handle no metric container case?

=> Requires ETX metric. Advertise ETX path cost as Rank. Interpret
Rank as ETX path cost.

- om_p

---

From: Joakim Eriksson <[email-masked]>
Date: Thu, 28 Apr 2011 09:31:37 +0200

Hello Om,

I think that the MinHopRankIncrease should not be forced to 1 to avoid
the DAG_RANK() in RPL. This feels like a "workaround" that might not be
needed.

 From my perspective DAG_RANK() is only used within the RPL protocol to
filter out neigbors that should not be considered parent (to avoid 
potential loops, etc). Then when the OF does it's comparison between
parents there is not need to use the DAG_RANK function to truncate
to the integer part of the rank. Thus forcing it to 1 will remove some
of the features that has been designed into RPL and limit how MRHOF
can be implemented.

We have been running MRHOF without metric container on ETX and have
used 256 as MinHipRankIncreas to have a good resolution on the fixpoint
value of ETX and I have not seen any specific problems related to
this. So I vote on removing the constraint on MinHopRankIncrease.

Best regards,
-- Joakim Eriksson, SICS

Omprakash Gnawali skrev 2011-04-28 00:38:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Matteo Paris <[email-masked]>
Date: Thu, 28 Apr 2011 09:56:01 -0400

I second Joakim's email.  We are also using 256 for 
MinHopRankIncrease for good ETX granularity.  Do you intend MRHOF to 
use only integral ETX values?

Matteo

---

From: Philip Levis <[email-masked]>
Date: Thu, 28 Apr 2011 07:42:01 -0700

On Apr 28, 2011, at 6:56 AM, Matteo Paris wrote:

> 
> I second Joakim's email.  We are also using 256 for MinHopRankIncrease for good ETX granularity.  Do you intend MRHOF to use only integral ETX values?

Good catch -- MRHOF should support fractional ETX values.

Phil