[Roll] Ralph Droms' Discuss 1 on draft-ietf-roll-of0-15

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 09 August 2011 16:59 UTC

Return-Path: <pthubert@cisco.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 3CDFD21F8C44; Tue, 9 Aug 2011 09:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.467
X-Spam-Level:
X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 LoKbsgbrIc3W; Tue, 9 Aug 2011 09:58:59 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3E05E21F8C3D; Tue, 9 Aug 2011 09:58:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2974; q=dns/txt; s=iport; t=1312909168; x=1314118768; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=lRoBp0TJdAoLpaGwUcXU8M9M7V9cKFop4P3wxctAtRk=; b=DcD4HNRjbdbdFefRoEOTErlVgG3qMdE9NP/3oAtWFsYa8M/DfzUdTSeW lxWKMBcBTia2sO9H8BYc4G4uNrM8BvDkI6bEehTeKOBSokcUuNZKql7ne 55F3K79oySl/X/uaV6YutUMbDVKw86Ix+gIP9yhoxmHJK4we21KawpQQQ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAClnQU6Q/khL/2dsb2JhbABCpz53gUABAQEBAgESAR0KPwUNARYUBhgHVwEEARoah0ugEQGea4VnXwSYF4tb
X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208";a="48297315"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 Aug 2011 16:59:27 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p79GxRx2020240; Tue, 9 Aug 2011 16:59:27 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 18:59:27 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 09 Aug 2011 18:59:23 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D053A3C8F@XMB-AMS-107.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Ralph Droms' Discuss 1 on draft-ietf-roll-of0-15
Thread-Index: AcxWta5HvYJoN9srRXaYVgvvQWCc5g==
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Ralph Droms <rdroms.ietf@gmail.com>, The IESG <iesg@ietf.org>
X-OriginalArrivalTime: 09 Aug 2011 16:59:27.0697 (UTC) FILETIME=[B2DF9C10:01CC56B5]
Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, roll-chairs@tools.ietf.org
Subject: [Roll] Ralph Droms' Discuss 1 on draft-ietf-roll-of0-15
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: Tue, 09 Aug 2011 16:59:00 -0000

> 1. I would like to discuss the interoperability and deployability of
> nodes in a RPL Instance that uses OF0.  If I understand section 4.1
> correctly, a node is free to compute step-of-rank using any method it
> chooses.  There is a suggestion that using link properties for the
> computation is preferred, but the specific link properties and the
> method of computation are not specified.  Later, section 4.1 defines
> two parameters, rank_factor and stretch_factor, that modify
> step_of_rank to generate a "stretched step_of_rank".  The latter value
> is then multiplied by the MinHopRankIncrease to compute the node's
> rank_increase.
> 
> My concern is the degrees of freedom provided to the implementation in
> the computation of rank_increase.  I'm hoping I can get an explanation
> of some reason to believe that independent implementations, using
> different methods to compute step_of_rank and potentially different
> configured values for rank_factor and stretch_factor, will
> interoperate successfully to form an operational network.
> 
[Pascal] Success is defined as reaching the Goal (a set of nodes or the
Internet), using the best links possible.
OF0 does not guarantee a particular optimization for a certain metric,
but trusts the implementation to rank a usable link from 1 to 9.
Section 6.2 indicates that , rank_factor and stretch_of_rank are
configured parameters.
Maybe section 7.1 should indicate that a deployment should ensure they
are homogeneous?


> More specifically, if a simple metric that leads to a hop-count
> computation for path lengths and route computation is known to yield
> unusable performance, why is it not required that a node use some sort
> of computation based on link characteristics?  And, if the computation

[Pascal] this is RECOMMENDED for links such as radio in section 4.1.
But RPL (and OF0) also apply to other links, including 802.3 and 802.11.
If you have a switched fabric as backbone, hop count or similar is
appropriate there.

> of the step_factor is entirely up to the node, why are the rank_factor
> and stretch_factor needed?  Why not just leave the entire computation
> to the implementation, with limitations that the resulting step_factor
> lie in the range MINIMUM_STEP_OF_RANK and
> MAXIMUM_STEP_OF_RANK?

[Pascal] There is only one factor, the rank_factor. It is used to
discriminate different link types.
Eg in homenet, 802.15.4 could have a huge rank_factor (3 or 4), a WIFI
would use say 2 and G/
Ethernet 1. 

This is a parameter that must be configured the same for all nodes for a
given type of link and it has a consequent action on the rank_increase
regardless of implementation.

The result is that the topology OF0 builds can be deployed so as to
limit the wireless hops, and favor .11 over .15.4.
 I think that is what you are really asking for and thus we are probably
on the same line.

What do you think?

Pascal