Subject: [Roll] comments on mrhof draft

From: Omprakash Gnawali <[email-masked]>
Date: Wed, 16 Feb 2011 21:43:30 -0800

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

---

From: Nicolas Tsiftes <[email-masked]>
Date: Wed, 23 Feb 2011 15:27:26 +0100

Hello,

I have a few comments after having implemented most of the functionality
in this draft. In general, I think that this document would benefit from
having some discussion regarding the choice of parameter values -- in
particular the hysteresis threshold. Currently, the document just states
that "The parameter values are assigned depending on the selected
metric.". But it is unclear how these values should be assigned once we
have selected a metric. It seems that selecting a suitable
PARENT_SWITCH_THRESHOLD requires intricate knowledge of lower layers;
e.g., how the link cost is calculated (if using an EWMA, what alpha
value is used?) or what the physical layer is of the interface through
which the parent is reachable. In addition, perhaps it should be
recommended that these parameters be made configurable by the network
administrator, who may be able to make a better decision for a
particular network deployment.

Section 1:

"MRHOF can be used with additive metric"

I think that stronger wording would be appropriate if additive metrics
is the only metric type in consideration for this OF.

Section 3.1:

"However, long intervals between periodic computation or deferring the
computation for too long after new metric advertisements or updates to
the selected link metric prevents results in node making parent
selection based on stale link and path information."

Drop "prevents". The sentence is also somewhat complex. Would the
following slightly shorter sentence preserve the meaning?

"However, deferring the path cost computation for too long after new
metric advertisements or updates to the selected link metric results in
parent selection based on stale link and path information."

Section 3.3:

The conversion table does not apply to the node with ROOT_RANK, but this
is not specified.

It would be good if the initial path cost set by the root could be
specified for each metric. Section 4 gives an example of the ETX
MIN_PATH_COST where it is set to 0. Instead, I think that this would be
more appropriate to have in the specification of the metrics
themselves, i.e., draft-ietf-roll-routing-metrics.

Node fanout: This element stands out in the list, because I haven't seen
it specified in draft-ietf-roll-routing-metrics-17, which the others
have been.

Section 4:

"Switch to a new path only if it is requires at least one fewer
transmission than the current path."

Drop "is".

Nicolas

Omprakash Gnawali skrev 2011-02-17 06:43:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

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

Thanks for the comments. Some notes inline.

On Wed, Feb 23, 2011 at 6:27 AM, Nicolas Tsiftes <[email-masked]> wrote:
> which the parent is reachable.

Not only that, it also depends on the degree to which you are willing
to pay the cost of path change for incremental gains in path quality.
If some of these issues raise questions about interoperability, and a
reasonably efficient interoperation at that, I agree that it has to be
in some draft. You seem to have hit upon this issue during your
implementation, so if you want to share some examples, that will help.

> In addition, perhaps it should be

Do you mean runtime reconfiguration or configuration when we "program"
the nodes? It would be hard to argue that the form is essential.

> themselves, i.e., draft-ietf-roll-routing-metrics.

I think the metrics draft is supposed to be general and not dictate
the values to be used by specific OFs. That is probably why it does
not talk about min cost for the metrics.

I will incorporate the rest of your comments in the next version.

- om_p