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

From: "roll issue tracker" <[email-masked]>
Date: Thu, 17 Jul 2014 12:02:33 -0000

#157: mpl-parameter-configuration-00 - Effect of inconsistent parameter set among
nodes

Comment (by [email-masked]):

 In version 01 - section 2.7 addresses this issue

 "2.7.  Operational Considerations

            A parameter set for an MPL domain SHOULD NOT updated more often
 than
            two times of expected refresh interval.

            If a node with MPL forwarder configured by MPL Parameter
            configuration Option failed to refresh the option for two times
 of
            information refresh time, it SHALL suspend the MPL forwarders
 of MPL
            domains configured by the option.  MPL forwarders configured by
 other
            methods such as static configuration file SHALL NOT be
 suspended."

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-doi-roll-mpl-
  [email-masked]          |  parameter-
     Type:  defect                   |  [email-masked]
 Priority:  major                    |      Status:  new
Component:  draft-doi-roll-mpl-      |   Milestone:
  parameter-configuration            |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/157#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: Philip Levis <[email-masked]>
Date: Tue, 29 Jul 2014 10:25:40 -0700

On May 26, 2014, at 2:01 AM, Yusuke DOI <[email-masked]> wrote:

> Hi,
> 
> Thank you for summarizing issues on my draft.
> On #157, my understanding is as follows. If there are any issues you know, please let me know.
> 
> Inconsistent but valid parameter does not harm the network much (it may harm battery-powered nodes).

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.

> 
> Reason:
> 
> 1) If a node have smaller Imin/Imax, it takes more responsibility to repeat messages than surrounding nodes. The node will consume more power and the area will have higher traffic than expected until MPL parameters of the node is updated.

It's worth noting that transmission (in most link layers MPL/RPL care about) does not consume significantly more energy than reception. Therefore, one node that has a smaller Imin or Imax introduces an energy cost on *all* of the nodes around it.

A smaller Imin can double the latency of propagation over a single hop, as nodes, on receiving an update, receive multiple Trickle messages and so suppress for their first interval.

Depending on K, a difference in Imax can do more than just increase/reduce responsibility. It could actually lead to complete suppression. Consider the case where three nodes have Imax=t and one node has Imax=t+2 (so the actual time interval is 4 times greater). K<=3. The three nodes will almost always completely suppress the fourth node with the longer interval.

> 2) If a node have larger Imin/Imax, it takes less responsibility to send messages than surrounding nodes. As other nodes will send the message instead of the node with old parameters, effect for traffic load and e2e delay is negligible on dense mesh clusters. If the node with old parameters is on sparse area of a mesh network, larger Imin/Imax will cause larger e2e delay than new parameter's expectation untilthe node is updated.

You should disambiguate the effects of Imin and Imax. 

> 3) If a node have smaller K, it takes less responsibility to repeat messages than surrounding nodes. On dense network, the effect is negligible. On sparse network, messages pass through the node will have less reliability until the node is updated.

It also introduces uneven transmission load. A node with a higher K will transmit with a much higher probability that those with the lower K (within the logarithmic bounds introduced by packet loss).

I'd suggest re-reading 6206 (Section 6), which goes into greater detail than the bullet points above and is much more specific.

> 4) If a node have larger K, it will repeat almost all the messages. The area will have excessive traffic untile the node is updated.
> 

This is not true. Note that packet loss/imperfect duplicate suppression/uneven topologies often cause some nodes to receive more than K packets. Again, I'd suggest re-reading 6206.

Phil

---

From: Yusuke DOI <[email-masked]>
Date: Wed, 30 Jul 2014 18:29:27 +0900

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.

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

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

---

From: Philip Levis <[email-masked]>
Date: Wed, 30 Jul 2014 12:11:08 -0700

> 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 re…

Yusuke,

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.

Thanks!

Phil

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Jul 2014 15:48:05 -0400

Philip Levis <[email-masked]> 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)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Philip Levis <[email-masked]>
Date: Wed, 30 Jul 2014 16:58:59 -0700

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