Re: [Roll] MRHOF ETX

Ralph Droms <> Fri, 06 July 2012 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5DBC21F86A7 for <>; Fri, 6 Jul 2012 09:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.58
X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aNrUbOA5s1dS for <>; Fri, 6 Jul 2012 09:38:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 53E9F21F869E for <>; Fri, 6 Jul 2012 09:38:25 -0700 (PDT)
Received: by qcsg15 with SMTP id g15so7292315qcs.27 for <>; Fri, 06 Jul 2012 09:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=2taZ1Mwzvz0lJLI312am+/C7Bb1piijSxp8Vk5vd0NY=; b=HXtE6vb7rLTuu5ULqgny1gWoNZWPRyRVg2uVngVznay7KCNLMgX1DoU53kfhsUBIob 6P7BlIt2364W1a+SwPWqGMZ4GTP3SQSejDGT3/lng+MHxlXIVZ4Pzp8eGoNQuLr9Obyb QHvmiij9RXe3kFNM67iFIZP10ZLB6pX28Rek46e1D1fy5az3eldpKJkOAKLIfoJwUFmL 0gw/Ghg0th0hY/BzI9rcLUZixFPHMnU8qHFFGXez6l3yrxSYGA8YfH4WQ8QZ1GLQCqit gVv5o/WJXsoEpSx8RTs9JtodvnbM/iePvMiRHw9zGJMWUk5TOjDDD5Q56UjdOGyvQHDN OGRw==
Received: by with SMTP id l10mr12100599qct.103.1341592721598; Fri, 06 Jul 2012 09:38:41 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id p12sm50795526qae.0.2012. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 09:38:40 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
From: Ralph Droms <>
In-Reply-To: <>
Date: Fri, 6 Jul 2012 12:38:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: roll <>
X-Mailer: Apple Mail (2.1278)
Subject: Re: [Roll] MRHOF ETX
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jul 2012 16:38:34 -0000

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