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
Abstract
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.
Status of this Memo
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 Notice
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
Roux, et al. Expires April 24, 2014 [Page 1]
Internet-Draft mpl-eval October 2013
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Simulated Network Layout . . . . . . . . . . . . . . . . . . . 3
4. Simulator Principle . . . . . . . . . . . . . . . . . . . . . 4
5. Radio Simulation Aspects . . . . . . . . . . . . . . . . . . . 4
6. Simulation Conditions . . . . . . . . . . . . . . . . . . . . 5
7. Types of Results . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Preliminary Results with Respect to Achievable Data
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Preliminary results with respect to the influence of
redundancy constants . . . . . . . . . . . . . . . . . . . 8
7.3. Preliminary results with respect to the influence of
transmit poser . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Roux, et al. Expires April 24, 2014 [Page 2]
Internet-Draft mpl-eval October 2013
1. Introduction
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.
2. Terminology
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].
3. Simulated Network Layout
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.
Roux, et al. Expires April 24, 2014 [Page 3]
Internet-Draft mpl-eval October 2013
+----------------------------------------+
| |
| +-----+ |
| |void | 500 nodes, |
| o seed |sub | random |
| |area | locations |
| | | |
| +-----+ |
| |
+----------------------------------------+
4. Simulator Principle
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:
o Check data trickle timers and control trickle timer (if one
exists).
o Treat incoming messages.
o Take care of (data or control) message transmission (start,
continue or complete a message transmission).
5. Radio Simulation Aspects
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
Roux, et al. Expires April 24, 2014 [Page 4]
Internet-Draft mpl-eval October 2013
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.
6. Simulation Conditions
When not explicitly stated, preliminary results are obtained with the
following parameter values:
Roux, et al. Expires April 24, 2014 [Page 5]
Internet-Draft mpl-eval October 2013
+-----------------------------------------+-------------------------+
| Parameter | Value |
+-----------------------------------------+-------------------------+
| Maximum number of messages in buffer | 10 |
| message set | |
| Seed message rate | 1 per each 4 seconds |
| | period |
| Number of messages sent during one | 200 |
| simulation | |
| 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
Table 1
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.
7. Types of Results
The following performance indicators are exploited:
Roux, et al. Expires April 24, 2014 [Page 6]
Internet-Draft mpl-eval October 2013
+-------------+-----------------------------------------------------+
| Indicator | Explanation |
+-------------+-----------------------------------------------------+
| Proactive, | Data message loss ratio observed in each node after |
| or reactive | simulation, and averaged across all nodes in the |
| date loss | network. |
| ratio | |
| Proactive, | Total number of data messages transmitted from any |
| or reactive | node during simulation, divided by the number of |
| data | nodes in the network, and divided again by the |
| expansion | number of data messages sent from the seed. |
| Reactive | Total number of control messages transmitted from |
| control | any node during simulation, divided by the number |
| expansion | of nodes in the network, and divided again by the |
| | number of data messages sent from the seed. |
| Reactive | Sum of the reactive data expansion plus the |
| expansion | reactive control expansion |
+-------------+-----------------------------------------------------+
Performance indicators
Table 2
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.
Roux, et al. Expires April 24, 2014 [Page 7]
Internet-Draft mpl-eval October 2013
7.1. Preliminary Results with Respect to Achievable Data Rate
+---------------------------------------+------+------+------+------+
| Data message generation period at the | 0.5s | 1s | 2s | 4s |
| seed | | | | |
+---------------------------------------+------+------+------+------+
| 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
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.
7.2. Preliminary results with respect to the influence of redundancy
constants
+--------------------------+------+------+-----+
| DATA_MESSAGE_K | 1 | 2 | 4 |
+--------------------------+------+------+-----+
| Proactive data expansion | 1.79 | 2.95 | 4.4 |
+--------------------------+------+------+-----+
Data expansion in proactive mode, versus redundancy constant
Table 4
Roux, et al. Expires April 24, 2014 [Page 8]
Internet-Draft mpl-eval October 2013
+----------------------------+------+------+------+
| 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 5
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.
7.3. Preliminary results with respect to the influence of transmit
poser
+----------------------------+------+------+------+------+------+
| 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
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
Roux, et al. Expires April 24, 2014 [Page 9]
Internet-Draft mpl-eval October 2013
course this result is obtained at the cost of higher expansion rates.
8. Security Considerations
9. IANA Considerations
10. Acknowledgements
This work has been supported by the A2NETS project (Autonomic
Services in M2M Networks) which is funded by the ITEA 2 program.
11. Normative References
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)",
draft-ietf-roll-trickle-mcast-05 (work in progress),
August 2013.
[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.
Appendix A. ChangeLog
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:
o first version.
Roux, et al. Expires April 24, 2014 [Page 10]
Internet-Draft mpl-eval October 2013
Authors' Addresses
Pierre Roux
CEA
http://www.cea.fr,
France
Phone:
Email: Pierre.Roux@cea.fr
Alexandru Petrescu
CEA
http://www.cea.fr,
France
Phone:
Email: Alexandru.Petrescu@cea.fr
Mounir Kellil
CEA
http://www.cea.fr,
France
Phone:
Email: Mounir.Kellil@cea.fr
Roux, et al. Expires April 24, 2014 [Page 11]