Re: [Roll] MRHOF ETX

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
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll