Subject: [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: Fri, 16 May 2014 23:00:05 -0000

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

 Source: [http://www.ietf.org/mail-archive/web/roll/current/msg08604.html]

 From: Yusuke DOI <yusuke.doi at toshiba.co.jp>
 Date: Fri, 14 Mar 2014 08:23:26 +0900

 "Typical open topics are:

 1) Effect of inconsistent parameter set among nodes
    (transitional state / update failure)"

-- 
-------------------------------------+-------------------------------------
 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       |   Keywords:
-------------------------------------+-------------------------------------

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

---

From: Yusuke DOI <[email-masked]>
Date: Mon, 26 May 2014 18:01:00 +0900

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).

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

Of course, if nodes does not update parameters, they may cause under/overcapacity. All the nodes should have proper timer setting to expire/renew DHCPv6 configuration if the network is likely to be updated. MPL parameter update in my use case is something like 'town rennovation' and does not expect rapid and unscheduled update. So, for example, it is perfectly ok to set the update parameters for weeks, or a month (at least for me).

If you notice anything, please let me know.

Regards,

Yusuke