Re: [6tsch] Zero Objective Function discussion

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 06 September 2013 17:14 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6611E82B1 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.906
X-Spam-Level:
X-Spam-Status: No, score=-9.906 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6, 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 cV688JsXy+K8 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:14:26 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D89FA11E81BE for <6tsch@ietf.org>; Fri, 6 Sep 2013 10:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10377; q=dns/txt; s=iport; t=1378487666; x=1379697266; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9XW6kcmQ6xSaVbg3SUvjCdUkaiM/gGos1JGLWtrN+rQ=; b=Krd6mi1B130U+mQPvE8oR5vHPBx3kvjiZL5xf3KpTf5gmJkOLGARoMY3 WIPEBJmOjpX191SNwyrSTyXUfE4yjofCn3AvFx5iU4/q0i9EyJ++np+CE 4gi4MGJQqJNDlcfox2UoQcBOFSLCVYgNZHwRXR7jOhdnLWJmM4FyPNkLO E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFALcMKlKtJV2b/2dsb2JhbABbDoI1RDVRwVWBJhZ0giQBAQEELVwCAQgRBAEBCx0HMhQJCAIEARIIEYdpvhGPSzcBgx2BAAOFS6QQgmE/gio
X-IronPort-AV: E=Sophos; i="4.90,855,1371081600"; d="scan'208,217"; a="256580631"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 06 Sep 2013 17:14:25 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86HEPMV022932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 17:14:25 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 12:14:24 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>, 6TSCH <6tsch@ietf.org>
Thread-Topic: [6tsch] Zero Objective Function discussion
Thread-Index: AQHOqxyrmdzGpsuAKEqe7jTsIgMIRJm47Ugg
Date: Fri, 6 Sep 2013 17:14:23 +0000
Deferred-Delivery: Fri, 6 Sep 2013 17:14:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD84145CF1E@xmb-rcd-x01.cisco.com>
References: <CADJ9OA8vNGCmy-2X901pqnmZuSCQ1d=GPeHPE=SD25JJkfwGgw@mail.gmail.com>
In-Reply-To: <CADJ9OA8vNGCmy-2X901pqnmZuSCQ1d=GPeHPE=SD25JJkfwGgw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.64.110]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84145CF1Exmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: Re: [6tsch] Zero Objective Function discussion
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2013 17:14:31 -0000

Hello Thomas:

The idea behind RFC 6552 is that we can say nothing if we do not want to specify anything. Node will interoperate and a rather correct network will form as long as devices use a normalized value for Sp(best = 1, good = 3, worst = 9)

We can make the life simpler for implementers by defining that we use ETX and that the normalization process is, say, 2*ETX as in my example; by RFC 6552 standards would mean that good link is ETX = 1.5 and ETX is acceptable up to 4.5

RFC 6719 provides another OF that can be used without a metric container, see section 3.5. In that case, ETX /2 is used. This gives a larger span to the network but means trouble to map in a join priority or a flow label.

I proposed a general formula Sp = a*ETX + b where a is between 1 and 3 and b is between 0 and 2 or 3. If b is not null, the Rank grows faster with the number of hops so deeper networks are not favored. To be honest I'm not convinced that it is a great idea for data instances or to encourage duocast it could be good.

An example of that would be a=1, b=2, which means that each hop incurs an additional penalty equivalent to an ETX of 2. This would mean that ETX is acceptable up to 7.

Probably specififying that we use OF0 with
Rf = 1
Sp = 2* ETX
Sr = 0

Is not a lot of work is it?

Pascal

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
Sent: vendredi 6 septembre 2013 18:18
To: 6TSCH
Subject: [6tsch] Zero Objective Function discussion

Pascal,

Thank you for presenting the OF0 discussion on the call today. I have a quick question about the depth penalty. In your example on the call, you used b=0. Could you detail a case where using a value of b different than 0 is applicable?

Also, do you think there is an alternative to defining our own computation of Sp? Certainly in the minimal draft, it would be good if we could use a OF as-is, without introducing anything new.

Thomas