Subject: Re: [Roll] MRHOF ETX

From: Ralph Droms <[email-masked]>
Date: Fri, 6 Jul 2012 12:38:37 -0400

I'm reviewing the draft-ietf-roll-minrank-hysteresis-of-11, and I have a question...

On Jun 8, 2012, at 1:36 PM 6/8/12, Philip Levis wrote:

> 
> On Jun 8, 2012, at 10:24 AM, Reddy, Joseph wrote:
> 
>> The advertised Rank of the parent is a 16-bit value that has integer and fractional parts. The MinHopRankIncrease parameter determines the length of the Integer/Fraction parts. 
> 
> I think you're misreading MRHOF, and misinterpreting MinHopRankIncrease. The MRHOF draft tries to be very explicit about this. MRHOF with ETX encodes the ETX in Rank, but MinHopRankIncrease can change the computation. If MinHopRankIncrease is greater than 128, then Rank no longer really encodes a fixed-point version of ETX, it encodes ETX plus a per-hop penalty.
> 
>> Now when the draft says to add the Rank and link ETX parameters, clearly this cannot be a simple addition of the Rank with either ETX or (ETX*128). Instead, the ETX value must be converted to the same Integer/Fraction representation as the Rank ( i.e., using MinHopRankIncrease )
> 
> Disagree -- the draft is pretty explicit on what you do, and it's not this.

One place where the document is not explicit about operation with ETX - at least as far as I can tell - is in section 3.1:

   A non-root node
   computes a neighbor's path cost by adding two components:

   1.  If the selected metric is a link metric, the selected metric for
       the link to a candidate neighbor.  If the selected metric is a
       node metric, the selected metric for the node.

   2.  The value of the selected metric in the metric container in the
       DIO sent by that neighbor.

But, ETX is not carried in the metric container for this OF.  Perhaps the correct action, which I think would be to use the neighbor's rank as its ETX metric, can be inferred from section 3.4:

   Instead, a node MUST advertise an approximation of
   its ETX in its advertised Rank value, following the rules described
   in Section 3.3.

But section 3.3 isn't exactly clear, as it specifies how to convert a path cost to a rank.  And I might be entirely wrong about inferring how to compute a path cost using ETX.

Anyway, I suggest step 2 in section 3.1 ought to have some additional text explicitly describing how to compute a neighbor's path cost when the selected metric is ETX.

Just out of curiosity, and apologizing for not taking part in the discussion that lead to the design decision, why is ETX treated specially and is there danger of some information loss leading to less-than-optimal route generation with the way ETX is used?

- Ralph

> 
> Phil
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Sat, 7 Jul 2012 04:09:37 -0700

> Anyway, I suggest step 2 in section 3.1 ought to have some additional text explicitly describing how to compute a neighbor's path cost when the selected metric is ETX.

Here is an excerpt from the terminology section:

Selected metric:  The metric chosen by the network operator to use
         for path selection.  MRHOF supports using a single metric for
         path selection.  The decision to use a metric (other than ETX)
         as the selected metric is indicated by the presence of the
         chosen metric in the DIO metric container.  The selection of
         the ETX metric is indicated by the absence of the metric
         container.

I believe that addresses your concern about the potential to confuse
the implementers about the use of ETX or other metric. The sentences
about how the selected metric is indicated (including ETX) in the
definition of selected metric was one the updates in -11.

> Just out of curiosity, and apologizing for not taking part in the discussion that lead to the design decision, why is ETX treated specially and is there danger of some information loss leading to l…

It is likely that ETX will be the most commonly used metric so we
decided to make this case the most byte-efficient. We don't see any
danger of loss of information due to this design decision.

- om_p