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

Philip Levis <pal@cs.stanford.edu> Wed, 30 July 2014 23:59 UTC

Return-Path: <pal@cs.stanford.edu>
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 BF63B1A00DB for <roll@ietfa.amsl.com>; Wed, 30 Jul 2014 16:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 Lk7y1Cf6rYnQ for <roll@ietfa.amsl.com>; Wed, 30 Jul 2014 16:59:04 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AF21A00A5 for <roll@ietf.org>; Wed, 30 Jul 2014 16:59:04 -0700 (PDT)
Received: from [76.14.66.110] (port=61966 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XCdls-0001sT-4M; Wed, 30 Jul 2014 16:59:01 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <21697.1406749685@sandelman.ca>
Date: Wed, 30 Jul 2014 16:58:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE7D9873-1A35-4E72-B48B-C6FEE00BF357@cs.stanford.edu>
References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> <53D8BAF7.8040105@toshiba.co.jp> <6420A78D-4C7D-4DDE-8480-3C913F27F0A9@cs.stanford.edu> <21697.1406749685@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 993826b9125cbf1b907f71dc54053338
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/1PCZiD9eWSDS51W26YdOCb5pW2o
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 23:59:06 -0000

On Jul 30, 2014, at 12:48 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

> 
> Philip Levis <pal@cs.stanford.edu> wrote:
>> I think the most significant concern is when configuration changes
>> significantly modify Imin. In this case, the speed of per-hop update
>> can be bounded by the maximum of the old and new Imin values. E.g., if
>> the update has a much smaller Imin, then it will trigger nodes with the
>> old state to use their Imin, but if it's much larger it will take a
>> while before they transmit and implicitly request an update. Similarly,
>> if the update has a much higher Imin, it will take much longer for each
>> hop to transmit the first broadcast that triggers neighbors to shrink
>> their interval.
> 
> Can you offer any advice for the document on maximum deltas for Imin?
> (a formula, if necessary)


I don't think there are any. If you want to change Imin from a to b, then the most efficient way to do so is to do it in one update. I.e., you won't gain any efficiency by staging it in a series of updates (you'll have log(max(a/b, b/a)) wasted transmissions). If you gotta change Imin, you gotta change it. But it's just useful to know the implications of doing so.

Perhaps the one recommendation is that you should be careful setting Imin to a large value. If you accidentally set it very high, then it's going to bound the speed by which you can fix your mistake. E.g., imagine you by accident set Imin to an hour then find that something starts going wrong with your network over the next few hours. It'll take that long to undo the change because propagation can be bounded by the maximum of the new and old values.

Phil