Re: [Roll] MRHOF draft-07 comments

Federico Consoli <admin@ipv6it.org> Thu, 29 March 2012 17:55 UTC

Return-Path: <admin@ipv6it.org>
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 F250121F8911 for <roll@ietfa.amsl.com>; Thu, 29 Mar 2012 10:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level:
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 1qIRBnkqm9eV for <roll@ietfa.amsl.com>; Thu, 29 Mar 2012 10:55:18 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA94721F8912 for <Roll@ietf.org>; Thu, 29 Mar 2012 10:55:17 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2474401bku.31 for <Roll@ietf.org>; Thu, 29 Mar 2012 10:55:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=4VPYJhLRup8wEDeWDrhXgQex5ODmmwrrmHFPI5q0LaU=; b=I5Gi3zy3cGIyW+3JG2jdxyes6fatGoNSvP4//cXZ4VL21uBDK9KTOyUlWLYPzJBVEh h9btjpECoUDevNk2vfnJsCAV7i5VvHAe3c1Y2trvCQOaYUCNKbUDyJ98Rhcky77z8gAi 4rC0gNqcQj9nq3T6uMCjGTr44NmlZ6MctJNM2kdsNJVoryTEuIw9LcsVQISDQ369LBhN 7/rWi4uQcsvJ+2VxglrE/0c4X6pCe4YlrhQMA4CqjF+P0+PLIKXuXixCdLDIzia57Olu l8rcWJmoHfe4H/5rus4RYso6ysz7NGZhN/OnmuUFMIYJdTf0cLnK47EzMt4CYfP7fqUr 5tEg==
Received: by 10.204.156.206 with SMTP id y14mr14681764bkw.14.1333043716831; Thu, 29 Mar 2012 10:55:16 -0700 (PDT)
Received: from [127.0.0.1] (host243-59-dynamic.56-82-r.retail.telecomitalia.it. [82.56.59.243]) by mx.google.com with ESMTPS id f6sm15371770bkg.10.2012.03.29.10.55.15 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 10:55:15 -0700 (PDT)
Message-ID: <4F74A202.2040206@ipv6it.org>
Date: Thu, 29 Mar 2012 19:55:14 +0200
From: Federico Consoli <admin@ipv6it.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
CC: Roll@ietf.org
References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> <4F7444F0.3020101@ipv6it.org> <A78FB66B-E578-4D2D-9D13-AF9A57F35859@cs.stanford.edu>
In-Reply-To: <A78FB66B-E578-4D2D-9D13-AF9A57F35859@cs.stanford.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnSDXfual81a0sF4hsJBAFc0N2/05oJUYxTQTab6TSjA5tyeQH1nLhfp6Um5VHoiKahbTpz
Subject: Re: [Roll] MRHOF draft-07 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: Thu, 29 Mar 2012 17:55:19 -0000

Il 29/03/2012 19.27, Philip Levis ha scritto:
> On Mar 29, 2012, at 1:18 PM, Federico Consoli wrote:
>
>> Il 28/03/2012 11.56, Philip Levis ha scritto:
>>> On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote:
>>>
>>>> Hi, I have a doubt about the root's rank with ETX.
>>>> Assume I have 2 nodes A and B and I use ETX as metric with MRHOF:
>>>> A is root
>>>> B is non-root
>>>> Link between A and B has a cost of 256 (ETX=2)
>>>>
>>>> A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in its DIO message in its advertised Rank value(6*).
>>>>
>>>> B will receive a DIO with rank value = 0 so B will set his rank to 256(7*) and will annunce a path_cost of 256.
>>>>
>>>> But now I got 2 nodes with the same rank value. I think it's not a problem with the algorith of DODAG creation but it's not RPL complaint(5*).
>>> Good catch.
>>>
>>> I think the issue here is the MRHOF draft is not clear: A (a root) should advertise a Rank of 256, and B, following 3.3, would advertise a Rank of 256 + MinHopRankIncrease (case 3 of 3.3).
>>>
>>> This does get at a more fundamental issue, one where the rules on Rank and the rules on metrics can diverge. I'd argue that the text saying Root nodes set to MIN_PATH_COST should instead relate to MinHopRankIncrease; 3.3 was designed given the RPL specification, but I think the cur_min_path_cost clause is out of sync with it. What do you think?
>>>
>>> Phil
>> Hi, thank you for your reply.
>>
>> I think that if the root node advertise a Rank of 256 it means that it got a path_cost to the worst parent of 256 (1*), so it means that it got a ETX of 2 to the worst parent.
>> It's not RPL complaint(2*).
>> If instead we suppose that root send packet to itself, it means that the root can lost packet (ETX=2) to itself.
>> IMHO, a way to fix that (still assuming that root send packet to itself) is that root could advertise a Rank of 128 (ETX=1) so it got no loss to itself.
>> Anyway I don't like this fix.
>>
>> I think that a goot fix is that a root set it's rank to MinHopRankIncrease and (only root) MUST use the metric container to carry ETX=0.
>>
>> I think it's a pretty significant change in MRHOF but I have other ideas. What do you think?
>>
>>
>>
>>
>> (1*) MRHOF - Section 3.4
>> "...It then calculates the metric it will advertise in
>> its metric container. This value is the path cost of the member of
>> the parent set with the highest path cost..."
>>
>> (2*) RPL-RFC - Section 8.2.1 - Rules 2
>> "A DODAG root MUST have a DODAG parent set of size zero"
>>
> The RPL specification is what says the Rank value a root must advertise.
>
> 8.2.2.2 says
>     2.  A DODAG root MUST advertise a rank of ROOT_RANK.
Yes. I agree with that. Root nodes got rank=256.
>
> To some degree, absolute ETX values do not matter -- what matters is their relative values. If all DODAG Roots advertise a Rank of 256, corresponding to an ETX of 2, then that's what they advertise, and a route with an computed ETX of 5 involves 3 transmissions within the LLN.
>
> I don't think I'm understanding the issue -- could you explain it again?
>
> Phil
I don't agree that root nodes could advertise a ETX=2.

"Once the preferred parent is selected, the node sets its 
cur_min_path_cost variable to the path cost corresponding to its 
preferred parent. It then calculates the metric it will advertise in its 
metric container. This value is the path cost of the member of the 
parent set with the highest path cost."

Root nodes have parent set of size zero so they got a 
cur_min_path_cost=0 so ETX=0.

Because "a node MUST advertise an approximation of its ETX in its 
advertised Rank value" root nodes must advertise ETX=0.
I agree with the fact that absolute ETX do not matter but I think that 
the root advertisement does not match the definition in the MRHOF draft.


-- 
Regards
Consoli Federico