| Network Working Group | P. Roux |
| Internet-Draft | A. Petrescu |
| Intended status: Experimental | M. Kellil |
| Expires: April 24, 2014 | CEA |
| October 21, 2013 |
Preliminary results about MPL performance evaluation
draft-roux-roll-mpl-eval-00.txt
This draft presents simulation work and first results related to MPL performance evaluation. The simulation makes it possible to evaluate MPL performances in the context of a large network. The simulated network introduces 500 nodes. The general principles of the simulator are described. Then reference settings are introduced, and evaluation indicators are proposed. Finally preliminary results are presented under the form of a few tables, that show the proposed indicator values depending on some specific parameter which is used as a variable argument. Among various results, the advantage of using reactive mode for MPL is shown in terms of the capability to maintain loss free diffusion in harsh radio conditions.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The RPL protocol is an IPv6 protocol for low-power and lossy networks, defined in [RFC6550].
The [I-D.ietf-roll-trickle-mcast] draft introduces the so called MPL algorithm, with a lot of freedom in terms of possible configuration. The current draft is a preliminary attempt to provide guidance for finding good algorithm settings for MPL.
Simulation makes it possible to address algorithmic capabilities in terms of scalability. A network made of 500 nodes is considered in this document. The proposed objective is to assess performance of the MPL protocol in such large networks, and to compare various MPL settings, in order to understand their influence on performances, so that setting guidelines may be derived.
However, the presented results are still not mature enough to propose solid and motivated guidelines. This draft should be considered as a preliminary attempt in this direction. Depending on the feedback, a more complete set of results may be presented in the coming months.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
A reference network layout has been assumed for all simulations. It is composed of 500 nodes randomly distributed within a rectangular area, excluding a void sub-area in its center, as shown in Figure 1. The main area width is 20 km and the height is 10 km. The void sub-area is 2 km and its height is 5 km. The layout is built by dropping nodes randomly in the main area. Once a potential node has been dropped at a random location in the main area, it is retained only if it is not located in the void sub-area, and if its closest neighbour among previously defined nodes, is not closer than 20 meters. This process continues until 500 nodes has been retained in the area. Then the closest node to the point of coordinates (x=2km,y=5km) is selected as the seed node.
+----------------------------------------+ | | | +-----+ | | |void | 500 nodes, | | o seed |sub | random | | |area | locations | | | | | | +-----+ | | | +----------------------------------------+
The simulator elementary time step has been set in such a way that it takes 4 elementary steps for a sender to send the longest messages, which are supposed not to exceed 128 bytes. The simulator doesn't address anything below this time step. As an example the simulator doesn't actually fill messages with bits.
At each elementary step, the simulator spans each node in the network several times in order to:
As said above, only a fragment of a message can be transmitted during an elementary time step of the simulator. The term of fragment, as used in this document, refers to the part of a message which can be transmitted during an elementary simulator step time.
The radio coverage radius if set to 100m, which means that beyond this distance, no fragment can be transmitted between 2 nodes. Below this distance, there is a probability for a transmitted fragment to be received which depends on the simulated power received at the receiver.
The static attenuation in dB is assumed to be equal to 50 + 30.log10(d/50), with d in meters, which means that we assume 3 as the path loss exponent. A log normal shadowing with 3 dB as standard deviation is added as a dynamical attenuation. Dynamical attenuation spectrum is limited with a 3 Hz cut off frequency.
A fragment being sent may not be received (or corrupted) at the receiver depending on a probability which is bound to the received level at the receiver at the receiving time. A predefined table defines the probability for a fragment to be received depending on the received power.
For a message to be transmitted between a sender and a receiver it is necessary that all segments involved in the message are received uncorrupted. Otherwise, the message is assumed to be lost (because of the UDP checksum mechanism, it is assumed that a message received corrupted is also a non delivered UDP message). If any segment has been lost then the message is lost as well.
Collisions are simulated as well: if a receiver receives fragments from multiples neighbour nodes under its coverage, then a collision may occur for the received fragment. For a message to be delivered, it is necessary that no collision occurs on any fragment of this message. A collision condition occurs if the received power from a first neighbour is interfered with the received power from one or a set of other neighbours which a total interfering power which is equal at least to half the useful received power from the first neighbour.
When not explicitly stated, preliminary results are obtained with the following parameter values:
| Parameter | Value |
|---|---|
| Maximum number of messages in buffer message set | 10 |
| Seed message rate | 1 per each 4 seconds period |
| Number of messages sent during one simulation | 200 |
| DATA_MESSAGE_IMIN | 1.28 second (128 simul. steps) |
| DATA_MESSAGE_IMAX | 10 (max interval = 21 minutes) |
| DATA_MESSAGE_K | 1 |
| DATA_MESSAGE_TIMER_EXPIRATIONS | No expiration |
| CONTROL_MESSAGE_IMIN | 128 |
| CONTROL_MESSAGE_IMAX | 10 |
| CONTROL_MESSAGE_K | 1 |
| Transmission power | 5 mW |
Default values assumed for simulation
This set of default values should not be seen as a proposed configuration which would be optimum in some sense. It is just meant as a reference point to explore configuration space. A future contribution may propose a more optimized reference configuration, once systematic simulations will have been run.
The following performance indicators are exploited:
| Indicator | Explanation |
|---|---|
| Proactive, or reactive date loss ratio | Data message loss ratio observed in each node after simulation, and averaged across all nodes in the network. |
| Proactive, or reactive data expansion | Total number of data messages transmitted from any node during simulation, divided by the number of nodes in the network, and divided again by the number of data messages sent from the seed. |
| Reactive control expansion | Total number of control messages transmitted from any node during simulation, divided by the number of nodes in the network, and divided again by the number of data messages sent from the seed. |
| Reactive expansion | Sum of the reactive data expansion plus the reactive control expansion |
Performance indicators
With respect to expansion figures, there is no claim about any generic properties for the results which are presented in this document. Given the present definitions, it is expected that the denser is the network (in terms of average number of neighbours per node) the lower expansions rates will be. Therefore expansion rates are not only depending on the routing algorithmic aspects, they also depend on the network layout. Their interest in the context of this document is to compare different configuration settings, rather than to obtain generic performance indicators.
| Data message generation period at the seed | 0.5s | 1s | 2s | 4s |
|---|---|---|---|---|
| Proactive data loss ratio | 0.38 | 0.15 | 0.03 | 0 |
| Proactive data expansion | 0.37 | 0.85 | 1.37 | 1.79 |
| Reactive data loss ratio | 0.38 | 0.2 | 0.02 | 0 |
| Reactive data expansion | 0.36 | 0.91 | 1.58 | 1.93 |
| Reactive control expansion | 0.1 | 0.22 | 0.44 | 0.72 |
| Reactive total expansion | 0.46 | 1.13 | 2.02 | 2.65 |
Preliminary results with respect to achievable data rates
Table 3 provides results for several message rates at the seed. It can be seen that a saturation phenomenon is observed (introducing significant message loss ratios) when the message rate is too high. Of course, this result is strongly related to the DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters, which have both been set in this case to 1.28 s.
The other observation seems to be that the reactive mode introduces more transmissions in the network (higher total expansion), with no real benefit in terms of achievable message rate given the constraints of negligible message loss ratios.
| DATA_MESSAGE_K | 1 | 2 | 4 |
|---|---|---|---|
| Proactive data expansion | 1.79 | 2.95 | 4.4 |
Data expansion in proactive mode, versus redundancy constant
| DATA_MESSAGE_K | 1 | 2 | 4 |
|---|---|---|---|
| Reactive data expansion | 1.93 | 2.88 | 4.18 |
| Reactive control expansion | 0.72 | 0.7 | 0.72 |
| Reactive total expansion | 2.65 | 3.58 | 4.9 |
Data and control expansion in reactive mode, versus redundancy constants
Table 4 shows the effect of redundancy constant of trickle timers on data expansion, in case of proactive mode. The other configuration parameters are set as described in the simulation conditions section. In particular, the message rate is 1 message for 4s, so that there are not message losses in any simulation. With no surprise, it can be observed that the redundancy constant has a strong influence on expansion ratio.
Table 5 shows the same result with respect to proactive mode. It shows that expansion figures are higher when reactive mode is used, as compared to proactive mode. The influence of introducing vlues that are different of 1 for CONTROL_MESSAGE_K will be studied later.
| Tx power (mW) | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Proactive data loss ratio | 0.56 | 0.14 | 0.03 | 0.01 | 0 |
| Proactive data expansion | 0.8 | 1.85 | 1.95 | 1.88 | 1.8 |
| Reactive data loss ratio | 0.4 | 0.07 | 0.01 | 0 | 0 |
| Reactive data expansion | 1.61 | 2.55 | 2.29 | 2.07 | 1.92 |
| Reactive control expansion | 0.68 | 0.88 | 0.81 | 0.76 | 0.72 |
| Reactive total expansion | 2.29 | 3.43 | 3.1 | 2.83 | 2.64 |
Results versus transmit power
Table 6 shows the effect of varying the transmit power.
It shows the interest of using reactive mode has it is able to achieve lower message loss ratios in harsh radio environments. Of course this result is obtained at the cost of higher expansion rates.
This work has been supported by the A2NETS project (Autonomic Services in M2M Networks) which is funded by the ITEA 2 program.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6550] | Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. |
| [I-D.ietf-roll-trickle-mcast] | Hui, J. and R. Kelsey, "Multicast Protocol for Low power and Lossy Networks (MPL)", Internet-Draft draft-ietf-roll-trickle-mcast-04, February 2013. |
The changes are listed in reverse chronological order, most recent changes appearing at the top of the list.
From draft-roux-roll-mpl-eval-00.txt to draft-authors-ipv6-over-80211p-00.txt: