Re: [Roll] MRHOF draft-07 comments

Federico Consoli <admin@ipv6it.org> Thu, 29 March 2012 11:18 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 022EC21F8915 for <roll@ietfa.amsl.com>; Thu, 29 Mar 2012 04:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 h3fdj1B5cXaP for <roll@ietfa.amsl.com>; Thu, 29 Mar 2012 04:18:14 -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 6677D21F8894 for <Roll@ietf.org>; Thu, 29 Mar 2012 04:18:13 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2026255bku.31 for <Roll@ietf.org>; Thu, 29 Mar 2012 04:18:12 -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:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=7RvkBDr1ihjLxdpA/zxGc0fZ8t1A/aQAM7DVJ0AOvyY=; b=Cu5wO4f8c8sR4sAqhtXiAtxpjRG1QGpRtYl66rB/5YV+lrTTVZdXZKtb1Rf5pGQm28 AErQgTnce4ru+KplSpYbwf7TCRifAfDsQWy9nE47rf8HOFRH2/znmRp8lDnrSL0gOxk9 /Xqp4zZeVPVhSRyrdM29TsoBEveCANndhrCNwXX2LhxLR5RkrAqd5RNBhwu6HG0BJKn5 r7ZonXiGcGjJfWv0KhhKlyHlk1HYElIw5eu+vsEVJwrSFMBmWgxjmpQZ3WeFsb6fkmOg otsUpqt1/8K488mPWv+9o+YoGLwvFHwW0CnzuF4hqdosyV6P9XK0/hQ7E2jNP8cug1A1 ay4w==
Received: by 10.205.137.14 with SMTP id im14mr13863276bkc.137.1333019892298; Thu, 29 Mar 2012 04:18:12 -0700 (PDT)
Received: from [127.0.0.1] (myskyn.iet.unipi.it. [131.114.59.252]) by mx.google.com with ESMTPS id u5sm12985555bka.5.2012.03.29.04.18.09 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:18:10 -0700 (PDT)
Message-ID: <4F7444F0.3020101@ipv6it.org>
Date: Thu, 29 Mar 2012 13:18:08 +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
To: Philip Levis <pal@cs.stanford.edu>
References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu>
In-Reply-To: <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkFKfOjqHoGs8Ghajnct4yKsTquLJd4fWxgE0wVtOnxYJNJVDpqGL4qu3vxGFb055+vqF1n
Cc: Roll@ietf.org
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 11:18:15 -0000

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"

-- 
Regards
Consoli Federico.