[Roll] MRHOF draft-06 comments

Dario Tedeschi <dat@exegin.com> Wed, 07 March 2012 11:39 UTC

Return-Path: <dat@exegin.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 EB11C21F87BE for <roll@ietfa.amsl.com>; Wed, 7 Mar 2012 03:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1]
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 RWO9Y9ti43H5 for <roll@ietfa.amsl.com>; Wed, 7 Mar 2012 03:38:59 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFEAA21F87A8 for <roll@ietf.org>; Wed, 7 Mar 2012 03:38:57 -0800 (PST)
Received: by werb10 with SMTP id b10so4842784wer.31 for <roll@ietf.org>; Wed, 07 Mar 2012 03:38:56 -0800 (PST)
Received: by 10.180.78.130 with SMTP id b2mr25705179wix.1.1331120336719; Wed, 07 Mar 2012 03:38:56 -0800 (PST)
Received: from [192.168.0.178] ([41.6.248.185]) by mx.google.com with ESMTPS id cc3sm93937924wib.7.2012.03.07.03.38.50 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 03:38:56 -0800 (PST)
Message-ID: <4F5748B6.6030503@exegin.com>
Date: Wed, 07 Mar 2012 13:38:30 +0200
From: Dario Tedeschi <dat@exegin.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: roll@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlX0Tz6lz6yeYrzOWD+0dftxa91ilAhAxKEJrcSCq6fJhv/NVHPNPB4QrthUIh5ZduCnqx4
Subject: [Roll] MRHOF draft-06 comments
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: Wed, 07 Mar 2012 11:39:04 -0000

Below are some comments and questions on a few areas in the latest MRHOF 
draft that seem a little confusing.

In section 3.3. "
     MRHOF uses this Rank value to compute the Rank it associates with the
     path through each member of the parent set. The Rank associated with
     a path through a member of the parent set is the maximum of the
     corresponding calculated Rank value from above and that node's
     advertised Rank plus MinHopRankIncrease.
"

Which of the following formulae match the above description?
     PathRank = RankValue + AdvRank + MinHopRankIncrease
     PathRank = MAX(RankValue, AdvRank) + MinHopRankIncrease
     PathRank = MAX(RankValue, (AdvRank + MinHopRankIncrease))
Where:
     PathRank is the Rank associated with a path through a member of the 
parent set
     AdvRank is a node's advertised Rank
     RankValue is the Rank value taken from Table 1 in the draft.

Perhaps adding something like one of the above formulae would help in 
describing exactly how a node arrives at its own Rank?

In section 3.3. "
     A node sets its Rank to the maximum of three values:
     ...
"
Could the above be simplified/removed by just saying that members in the 
parent set meet the following condition:
     ( DAGRank(PathRank) < DAGRank(thisNode.AdvRank) )
Where:
     thisNode.AdvRank is a joining node's current Rank (starting at 
infinity before having joined a DODAG).
The above condition allows a parent's path Rank to vary up to an upper 
bound implicitly set by MinHopRankIncrease, before a node might exclude 
that parent from the set and possibly choose another preferred parent.

In section 3.4. "
                             This value is the path cost of the member of
    the parent set with the highest path cost.  Thus, while
    cur_min_path_cost is the cost through the preferred parent, a node
    advertises the highest cost path from the node to the root through a
    member of the parent set.  The value of the highest cost path is
    carried in the metric container corresponding to the selected metric
    when DIO messages are sent.
"
It's quite strange that the advertised path cost could be one associated 
with a member in the parent set that isn't currently in the path to the 
root. In my view, this could quite easily distort a DODAG away from its 
optimum, because nodes may advertised costs that are more pessimistic 
than need be. Surely once a node has selected a preferred parent, it 
should advertise the cost of that path through that parent, since that 
is the real and optimal cost to the root.

Reading the section further, MRHOF with ETX is exclude from the above 
requirement. Was that intentional?

Regards
Dario