[Roll] Revisiting MPL Reconfiguration (Re: On Operation and Management of Large Scale MPL Network (Fwd: I-D Action: draft-doi-roll-mpl-nan-requirements-00.txt))

Yusuke DOI <yusuke.doi@toshiba.co.jp> Mon, 16 December 2013 02:49 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 B53061AE290 for <roll@ietfa.amsl.com>; Sun, 15 Dec 2013 18:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.331
X-Spam-Level:
X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZLvz8742Lnwy for <roll@ietfa.amsl.com>; Sun, 15 Dec 2013 18:49:24 -0800 (PST)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9891ADFDC for <roll@ietf.org>; Sun, 15 Dec 2013 18:49:23 -0800 (PST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id rBG2nJNT004628 for <roll@ietf.org>; Mon, 16 Dec 2013 11:49:19 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id rBG2nJOQ006481 for roll@ietf.org; Mon, 16 Dec 2013 11:49:19 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id MAA06480; Mon, 16 Dec 2013 11:49:19 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id rBG2nJt4003096 for <roll@ietf.org>; Mon, 16 Dec 2013 11:49:19 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id rBG2nEKb025876; Mon, 16 Dec 2013 11:49:14 +0900 (JST)
Received: from [133.196.16.96] (ncg-dhcp96.isl.rdc.toshiba.co.jp [133.196.16.96]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 01B6797D66 for <roll@ietf.org>; Mon, 16 Dec 2013 11:48:28 +0900 (JST)
Message-ID: <52AE6A29.3060200@toshiba.co.jp>
Date: Mon, 16 Dec 2013 11:49:13 +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.2.0
MIME-Version: 1.0
To: roll@ietf.org
References: <20131203122215.10762.618.idtracker@ietfa.amsl.com> <52A6B4F1.6020103@toshiba.co.jp>
In-Reply-To: <52A6B4F1.6020103@toshiba.co.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Roll] Revisiting MPL Reconfiguration (Re: On Operation and Management of Large Scale MPL Network (Fwd: I-D Action: draft-doi-roll-mpl-nan-requirements-00.txt))
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: Mon, 16 Dec 2013 02:49:33 -0000

Hi,

(2013-12-10 15:30), Yusuke DOI wrote:
> The issue I have is how to deploy a mesh network over even larger
> network, maybe up to 10,000 nodes, with very low application traffic.
> At the same time, we need communication channels for relatively-low
> latency (few seconds) broadcast for commanding and enough reliable
> broadcast file transfer. The draft
> draft-doi-roll-mpl-nan-requirements-00 introduces the requirement.
>
> For the objective, MPL seems to be the only choice for us. But it
> lacks some functionarities for operation and management. One of the
> spec we need is to configure and/or update MPL forwarder after
> deployment. My proposal for configuration and re-configuration is
> DHCPv6 option:
> http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-03

Let me describe little bit more on this topic.

The following issues are what I need to solve.

1) MPL configuration and reconfiguration
  - New domains may appear after deployment
  - Existing domain configuration may be changed
  - Of course, it should be scalable
    (Peter suggested me to use SNMP, but we're going to scale out up to 10k)

2) Management I/F of MPL nodes, especially, seeds.
  - MIBs? Netconf? CoAP???
  - How many 'active transmitting data messages'? for rate control

I did preliminary analysis on MPL reconfiguration after ML discussion two-months ago, and now nearly-confident that the only problem is unbalanced transmission and almost no message will be lost just because of parameter update. Timers for running transmissions can be 'reset' as if there are some inconsistency detected, just after parameter update.

Here's list of parameters and expected effects after reset. Assumption is the forwarder is the only one with the updated parameter set:

PROACTIVE_FORWARDING false->true:
  the forwarder is almost always have to send the first data messages

PROACTIVE_FORWARDING true->false:
  the forwarder will not send the data message at the first interval

SEED_SET_ENTRY_LIFETIME increased:
  the forwarder will continue to keep old data message and bitmap, if
  there are some transmission happend after neighbor's expiry and
  before the node's expiry, the forwarder may need to send old messages
  again (should not happen frequently)

SEED_SET_ENTRY_LIFETIME decreased:
  vice versa, the forwaeder may receive old messages.

IMIN, IMAX decreased or K increased:
  more chance to send messages

IMIN, IMAX increased or K decreased:
  less chance to send messages

TIMER_EXPIRATIONS incresed:
  more messages to send. At the end of consistent intervals before
  expiration, the forwarder may be the only node to send the message

TIMER_EXPIRATIONS decreased:
  less messages to send.

So, as far as I can recognize, parameter update is possible for implementations that can accept temporal unbalanced load of transmission. For battery-powered devices it may not be acceptable, but for power-supplied devices it should be acceptable as far as it does not harm the mesh network itself.

Regards,

Yusuke

p.s. I'll be on winter vacation on later this week, and many of you weel be in holiday week when I'm back to office, so please accept longer latency on communication. Happy hollidays!