Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes

Yusuke DOI <yusuke.doi@toshiba.co.jp> Wed, 30 July 2014 09:29 UTC

Return-Path: <yusuke.doi@toshiba.co.jp>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA121B2A35 for <roll@ietfa.amsl.com>; Wed, 30 Jul 2014 02:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level:
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCO5HV73Pncq for <roll@ietfa.amsl.com>; Wed, 30 Jul 2014 02:29:31 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1421B2A25 for <roll@ietf.org>; Wed, 30 Jul 2014 02:29:30 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s6U9TSf1017359 for <roll@ietf.org>; Wed, 30 Jul 2014 18:29:28 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id s6U9TSZs027697 for roll@ietf.org; Wed, 30 Jul 2014 18:29:28 +0900 (JST)
Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA27695; Wed, 30 Jul 2014 18:29:28 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s6U9TRUg004656 for <roll@ietf.org>; Wed, 30 Jul 2014 18:29:27 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6U9TROo006660; Wed, 30 Jul 2014 18:29:27 +0900 (JST)
Received: from [133.196.16.151] (ncg-dhcp151.isl.rdc.toshiba.co.jp [133.196.16.151]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C6D8097D33; Wed, 30 Jul 2014 18:29:27 +0900 (JST)
Message-ID: <53D8BAF7.8040105@toshiba.co.jp>
Date: Wed, 30 Jul 2014 18:29:27 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Routing Over Low power and Lossy networks <roll@ietf.org>
References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu>
In-Reply-To: <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/fBvoSifSohZVpjhWEpckfzuT5wI
Cc: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org
Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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, 30 Jul 2014 09:29:33 -0000

Phil,

Thank you for your kind review.

First of all, please let me clarify this effect is transient. Inconsistent parameter shall be avoided but AFAIK we currently have no handy way to change all the parameter in a network at once (at least, in IETF standards). DHCP is basically client-driven update and some transitional inconsistency is inevitable. In addition, the proposal assumes the old and new parameter sets should be reasonable parameters in a transient period. The motivation is to make a slow 'control knob' to handle steadly-changing environments.

(2014-07-30 02:25), Philip Levis wrote:

> Given the L in RPL/MPL includes the term "low power", harming battery-powered nodes is kind of important. It's easy to try to ignore them because they're so challenging, but I'd strongly recommend against it.

Do you strongly recommend synchronized update of parameter set of all nodes in a MPL domain? If so, I'd like to add some way (adding a time to activate/deactivate a parameter, etc). But it may become difficult to operate in standard DHCP context.

Thanks for your comments and advices. I admit my argument is not precise and strict. There are some hidden assumptions (for example, our use case is AMI and uneven load was acceptable). I'll add reference to 6206 section 6 as operational considerations.

Best Regards,

Yusuke