Re: [Roll] MRHOF ETX

"Reddy, Joseph" <jreddy@ti.com> Fri, 08 June 2012 18:11 UTC

Return-Path: <jreddy@ti.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BB711E80AB for <roll@ietfa.amsl.com>; Fri, 8 Jun 2012 11:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level:
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUtpJ3UDX-g3 for <roll@ietfa.amsl.com>; Fri, 8 Jun 2012 11:11:12 -0700 (PDT)
Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9111E8089 for <roll@ietf.org>; Fri, 8 Jun 2012 11:11:12 -0700 (PDT)
Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id q58IB4FQ030778; Fri, 8 Jun 2012 13:11:05 -0500
Received: from DLEE74.ent.ti.com (dlee74.ent.ti.com [157.170.170.8]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q58IB4nA013241; Fri, 8 Jun 2012 13:11:04 -0500
Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DLEE74.ent.ti.com ([fe80::a0f1:125b:e7e3:7ed8%18]) with mapi id 14.01.0323.003; Fri, 8 Jun 2012 13:11:04 -0500
From: "Reddy, Joseph" <jreddy@ti.com>
To: Philip Levis <pal@cs.stanford.edu>
Thread-Topic: [Roll] MRHOF ETX
Thread-Index: Ac1Fmg4SPQh/8rD8Q92yAuo1fIkMvwALQtKAAAmbfcA=
Date: Fri, 8 Jun 2012 18:11:04 +0000
Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E35E@DLEE10.ent.ti.com>
References: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu>
In-Reply-To: <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.170.170.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] MRHOF ETX
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2012 18:11:13 -0000

Phil

It doesn't seem right to me that the actual metric used varies based on setting of the MinHopRankIncrease parameter ( since that parameter is defined outside of MrHof draft and its setting may be based on other considerations ). The draft clearly states  ( in section 3.3 ): "... a node MUST advertise an approximation of its ETX in its advertised Rank value....". This sentence should be modified if the intention is to encode an ETX + Hopcount-penalty depending on MinHopRankIncrease setting. 

As an aside, is there a specific reason to use 128 as the factor for multiplying ETX? Since the default value of MinHopRankIncrease is 256 in the RPL spec, using ETX*256 as the encoding would allow the default usage to be ETX without a hopcount penalty ( which is likely to be common usage ).

 -Joseph


-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu] 
Sent: Friday, June 08, 2012 10:36 AM
To: Reddy, Joseph
Cc: roll@ietf.org
Subject: Re: [Roll] MRHOF ETX


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.

Phil