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

Philip Levis <> Wed, 30 July 2014 19:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A00F51A0397 for <>; Wed, 30 Jul 2014 12:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sye25nnxF_py for <>; Wed, 30 Jul 2014 12:11:11 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D89071A0389 for <>; Wed, 30 Jul 2014 12:11:11 -0700 (PDT)
Received: from [] (port=59233 helo=[]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <>) id 1XCZHH-0007On-PV; Wed, 30 Jul 2014 12:11:08 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <>
In-Reply-To: <>
Date: Wed, 30 Jul 2014 12:11:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Routing Over Low power and Lossy networks <>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 34530ccd932157cd24ba9d2c27818ca4
Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jul 2014 19:11:13 -0000

On Jul 30, 2014, at 2:29 AM, Yusuke DOI <> wrote:

> 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,


Synchronized updates of parameters aren't necessary: the differences reduce efficiency/load balancing in potentially significant ways over the long term but not significantly for transient periods. E.g., it matters in the long term if one node always transmits and another is always suppressed, but if this happens for some small number of intervals per configuration change that's not tremendous in practice and definitely not worth greater complexity.

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.

There's also a potential livelock case with a buggy implementation when Imin is changed significantly -- the specification notes this with the clause "If Trickle hears a transmission that is "inconsistent" and I is greater than Imin, it resets the Trickle timer. " If an implementation elides the check that I is greater than Imin, then hearing a series of inconsistent transmissions could cause it to keep on resetting I.

Overall, I think the approach is sound and does not warrant any modifications. I just thought that the operational considerations on parameter differences were a bit vague and inaccurate. Trickle is on one hand very simple but on the other very subtle, so anything we can do to guide people on how to use it is valuable.