Re: [Roll] MRHOF ETX

Omprakash Gnawali <gnawali@cs.uh.edu> Sat, 07 July 2012 11:09 UTC

Return-Path: <gnawali@cs.uh.edu>
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 AF0E721F85B1 for <roll@ietfa.amsl.com>; Sat, 7 Jul 2012 04:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Level:
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 PgxuS8x3z9uS for <roll@ietfa.amsl.com>; Sat, 7 Jul 2012 04:09:47 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 852CE21F8564 for <roll@ietf.org>; Sat, 7 Jul 2012 04:09:47 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id E19C723CA8A for <roll@ietf.org>; Sat, 7 Jul 2012 06:09:58 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.uh.edu
Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi2-C+lFuMkb for <roll@ietf.org>; Sat, 7 Jul 2012 06:09:56 -0500 (CDT)
Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 57C8623CA89 for <roll@ietf.org>; Sat, 7 Jul 2012 06:09:56 -0500 (CDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by it.cs.uh.edu (Postfix) with ESMTP id 33B532A2807B for <roll@ietf.org>; Sat, 7 Jul 2012 06:09:44 -0500 (CDT)
Received: by pbcwy7 with SMTP id wy7so16501413pbc.31 for <roll@ietf.org>; Sat, 07 Jul 2012 04:09:57 -0700 (PDT)
Received: by 10.66.82.2 with SMTP id e2mr51724515pay.67.1341659397677; Sat, 07 Jul 2012 04:09:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.9.202 with HTTP; Sat, 7 Jul 2012 04:09:37 -0700 (PDT)
In-Reply-To: <914AE372-FA64-4A62-A029-F83F73CF9545@gmail.com>
References: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu> <914AE372-FA64-4A62-A029-F83F73CF9545@gmail.com>
From: Omprakash Gnawali <gnawali@cs.uh.edu>
Date: Sat, 7 Jul 2012 04:09:37 -0700
Message-ID: <CAErDfUQwb50PuqgCHU2LeO1b48a1dF9iFNWGfOe2z5ygiH3P8A@mail.gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: roll <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: Sat, 07 Jul 2012 11:09:49 -0000

On Fri, Jul 6, 2012 at 9:38 AM, Ralph Droms <rdroms.ietf@gmail.com>; wrote:
> 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.


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 less-than-optimal route generation with the way ETX is used?

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