Internet DRAFT - draft-desmouceaux-ipv6-mcast-wifi-power-usage
draft-desmouceaux-ipv6-mcast-wifi-power-usage
Network Working Group Y. Desmouceaux
Internet-Draft Cisco
Intended status: Informational August 1, 2014
Expires: January 31, 2015
Power consumption due to IPv6 multicast on WiFi devices
draft-desmouceaux-ipv6-mcast-wifi-power-usage-01
Abstract
IPv6 networks make a consequent use of multicast for several
purposes, including mandatory functions such as Neighbor Discovery.
Although this use of multicast does not create real difficulties on
wired networks, it can become painful on wireless ones, notably in
terms of power consumption. There might be little effect on home
networks, however, such effects become more important on large-scale
networks. This memo provides statistics about the multicast traffic
rate in a large IPv6 wireless network and the induced device power
consumption, in response to a call emitted at IETF 89.
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 January 31, 2015.
Copyright Notice
Copyright (c) 2014 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
Desmouceaux Expires January 31, 2015 [Page 1]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IPv6 typical multicast traffic . . . . . . . . . . . . . . . . 3
2.1. Behavior when joining a network . . . . . . . . . . . . . 3
2.2. Behavior once connected . . . . . . . . . . . . . . . . . 3
3. Power consumption induced by multicast traffic . . . . . . . . 4
4. Large-scale wireless networks . . . . . . . . . . . . . . . . 5
4.1. Typical orders of magnitude . . . . . . . . . . . . . . . 5
4.1.1. Arrival rates . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Connection durations . . . . . . . . . . . . . . . . . 6
4.2. Influence of such networks over devices . . . . . . . . . 7
4.3. Roaming . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Optimizing Router Solicitations retransmissions . . . . . 8
5.2. Proxying multicast traffic . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Multicast is widely used in IPv6 for configuration purposes through
the Neighbor Discovery protocol [RFC4861]. On IEEE 802.11 wireless
links, this can have a negative impact on low-energy devices such as
smartphones, as stated in [I-D.vyncke-6man-mcast-not-efficient]. The
802.11 protocol [IEEE80211] includes a power-save mode for such
devices, allowing them to be in a sleep state in which they will be
notified when packets addressed to them are pending. However, there
is no known powerful equivalent of wired-links Multicast Listener
Discovery (MLD) snooping [RFC4541], hence all devices will be woken
up when multicast traffic is pending.
In this document, we provide data illustrating the issue at 3 levels:
o typical multicast traffic emitted by a device when joining an IPv6
network, and 'background multicast noise' generated once
connected;
o power consumption statistics for wireless devices when confronted
to multicast traffic;
o orders of magnitude of connections frequencies and durations in
Desmouceaux Expires January 31, 2015 [Page 2]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
large-scale wireless networks.
Confronting these 3 levels makes it possible to model the power
consumption overhead of multicast traffic on typical large wireless
networks.
We finally discuss possible solutions at the IP and the 802.11 level.
2. IPv6 typical multicast traffic
2.1. Behavior when joining a network
When joining an IPv6 network, devices usually emit the following
multicast traffic:
1. duplicate address detection for the link-local address;
2. router solicitation;
3. duplicate address detection for the SLAAC address;
4. duplicate address detection for the SLAAC privacy address.
In addition, MLDv2 [RFC3810] frames are emitted for registration to
the solicited-node multicast addresses needed for Duplicate Address
Detection. Their number is not deterministic since other multicast
protocols may interfere, but is typically at least 4.
Depending on the configuration of the router, the Router
Advertisement sent by the router in response to the node's Router
Solicitation may also be multicast.
On Linux and Apple MacOS X clients that were tested, joining the
network also induces Multicast Domain Name System (mDNS) [RFC6762]
traffic. Once more, the number of packets emitted depends on the
network environment, but is around 20. Likewise, Microsoft Windows
clients generate Link-local Multicast Name Resolution (LLMNR)
[RFC4795] multicast traffic when they connect to the network.
2.2. Behavior once connected
Once connected, some devices keep on sending IPv6 multicast frames.
Protocols inducing such traffic include Neighbor Discovery, MLD, and
local discovery or name-resolution protocols, such as mDNS, LLMNR,
Simple Service Discovery Protocol (SSDP), Web Services Dynamic
Discovery (WS-D).
On a typical middle-scale enterprise network, IPv6 multicast traffic
induced by these protocols has a noticeable impact. Our measures on
a 160-hosts network show that the average rate of multicast traffic
transiting through the link is 4.5 frames per second. The following
table shows the repartition of the multicast traffic between these
Desmouceaux Expires January 31, 2015 [Page 3]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
protocols, as it was measured:
Protocol ICMPv6 mDNS LLMNR WS-D
Ratio 0.53 0.33 0.12 0.03
Based on the previous data, we can deduce how much multicast traffic
is generated by a "representative" device. Doing a simple cross-
multiplication, we obtain a rate of 0.028 multicast packets/s for a
single device, or 101 frames/hour. (This result is confirmed on a
small isolated test network of two hosts.) The following table shows
the indicative number of multicast packets emitted by a such a
representative device on our test network in an hour:
Protocol ICMPv6 mDNS LLMNR WS-D
Frames per hour 53 33 12 3
3. Power consumption induced by multicast traffic
While multicast traffic has no significant influence on actively
connected devices, it might have a poor impact on the ones that are
in power-save mode.
In power-save mode, the hardware of such a device needs to regularly
wake up in order to check whether pending frames are buffered for it.
To do so, it wakes up every DTIM_PERIOD beacons (DTIM_PERIOD usually
being set to 1 or 2) and retrieves the beacon emitted by the Access
Point (AP). If multicast traffic is pending, this will be indicated
by the AP by setting a specific bit in the beacon's Time Information
Management (TIM) information element to 1.
If a device sees that this bit is set, it will stay awake in order to
retrieve the frames. The device CPU will then be awakened and frames
will be transmitted by the wireless firmware to the IP stack. (Note
that this might not happen if the firmware implements a multicast
filter, but even in this case, current will be drawn to retrieve the
frames.)
Power consumption measurements on smartphone devices confirm the
negative impact of multicast traffic on sleeping devices. The
measurement was performed on a Samsung i9195 by attaching an ammeter
between the battery and the phone. When idle (screen off, GSM off,
WiFi on, 802.11 power-save enabled by the device), current drawn is
10 mA in average. When a multicast frame is received and the CPU
awakened to process it, the current draw goes to between 100 and 150
mA during a small peak of time.
Desmouceaux Expires January 31, 2015 [Page 4]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
Assuming that the duration of the current peak induced by processing
a multicast frame is 0.1 s, a device would hence use K times more
energy when it receives RATE multicast packets per second, than when
it receives none, where K = (10*(1 - RATE*0.1) + 150*RATE*0.1)/10.
The following table gives K as a function of RATE.
RATE (pkts/s) 0.01 0.1 0.5 1 2 4 >10
K 1.014 1.14 1.7 2.4 3.8 6.6 15
A possible workaround to this issue is to implement a multicast
filter at the firmware level, which will only forward multicast
packets to the IP stack if their destination address matches one of
those registered by the device. Although this would have a positive
impact on battery consumption, the following measurements show that
this is not entirely satisfying.
Indeed, current drawn to retrieve pending multicast frames at L2
without waking up the main CPU is around 40 mA, which is still 4
times more than idle consumption. In order to simulate this, one can
tweak a router so that it always advertises the presence of multicast
frames by setting the TIM multicast bit to 1. The device's radio will
then always try to retrieve frames following this beacon.
4. Large-scale wireless networks
Previous sections provide data about the battery usage induced by
individual multicast frames, and the number of multicast frames
generated by a single host when connecting and once connected.
In order to model the battery usage of real-life networks, the
following section provides data about connection arrival rates and
connection durations in usual large-scale wireless networks.
4.1. Typical orders of magnitude
The following results are based on anonymized data from a dual-stack
WiFi network in a conference setup. These data provide interesting
statistics about user habits in a network characterized by mobility,
where users move much from one room to another. Plus, it is a good
example of a large wireless network, since the user count during
working hours is between 600 and 700.
4.1.1. Arrival rates
Arrival rates in this test network follow a probability distribution
that is very close to an exponential law (the error rate being only
6%). The observed parameter for this law is such that 1/lambda = 6
seconds.
Desmouceaux Expires January 31, 2015 [Page 5]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
We are therefore in a scheme expected by the classical queuing
theory, where arrivals are memoryless and have the Markov property of
independence of the past. The smallness of the parameter is also an
indicator of the great mobility of such networks: in average, a
client joined the network every 6 seconds.
There is a small bias in previous measures due to people arriving en
masse at the beginning of the day and going to lunch at noon. This
bias does not affect the exponential nature of the law. However, it
has an non-negligible effect over the parameter of the distribution.
Computing the probability distribution over a shorter unbiased amount
of time leads to a greater arrival rate: 1/lambda becomes 4.5
seconds.
From these data it appears that arrival rates in wireless networks
characterized by mobility are high. Since arrivals mean multicast
traffic issued by the client's IPv6 stack, this already provides a
rough intuition that large wireless networks feature high rates of
multicast frames.
4.1.2. Connection durations
Once clients are connected, duration of their connections follow a
less typical probability distribution, whose form is represented
below:
dur. distr.
^
| ||
| ||
| |\
| | |
| | |
| | |
| | \
| | \_
| | \__
| | \_____
|____| \______
| \_________
+--------------------------------------> t
From these data it appears that there is a peak of connections that
last 5 minutes, whereas almost no connection lasts less than this. A
plausible explanation for this is that there are two kinds of
behaviors: devices that automatically join the network without human
intervention and disconnect after an idle timeout, and users who
consciously connect to the network. After this peak, the
distribution is roughly an exponential law, which correspond to the
latter case.
Desmouceaux Expires January 31, 2015 [Page 6]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
An average connection time of 55 minutes has been measured: at least,
clients do not seem to be eager to leave the network too soon once
they have joined it.
In our test network, arrivals follow an exponential law, and service
times do not follow a close-form probability distribution. We can
therefore model it as an M/G/oo queue. Once stabilized, the number
of hosts in such a system follows a Poisson law of parameter S/T,
where S is the expected service time and T=1/lambda the expected time
between two arrivals.
4.2. Influence of such networks over devices
In this section, we model the influence of a large wireless network
over a device, in terms of power consumption.
Let us assume that in average, N devices are present in the network,
and that the arrival rate is lambda. (See Section 4.1 for typical
numerical values). Then, Section 2 implies that the rate of multicast
frames in the network is RATE = 0.025*N + 4*lambda. The following
table gives RATE for a few values of N and lambda:
N 5 10 50 100 500 500
1/lambda (s) 600 600 60 60 60 5
RATE (pkts/s) 0.13 0.26 1.32 2.57 12.6 13.3
Finally, using Section 3, we can compute what is the energy overhead
induced by the multicast traffic on a device. When comparing to idle
mode, K more times energy will be used, where K = (10*(1 - (0.025*N +
4*lambda)*0.1) + 150*(0.025*N + 4*lambda)*0.1)/10. The following
table gives K as a function of N and lambda:
N 5 10 50 100 500 500
1/lambda (s) 600 600 60 60 60 5
K 1.18 1.36 2.84 4.59 15 15
Thus, battery consumption induced by multicast traffic will be
doubled in a network of 30 nodes where the arrival rate is 10
minutes.
4.3. Roaming
Depending on the configuration of the wireless network, roaming might
have different consequences on multicast traffic emission.
Desmouceaux Expires January 31, 2015 [Page 7]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
When a host moves from one access point to another, roaming is
supposed to be seamless. If a device detects a drop in signal
quality, it will probe for a nearer access point with the same SSID.
If it finds one, it will send an Authentication frame and a
Reassociation Request. This will seem transparent to L3, except that
some timers may time out, causing retransmissions.
However, if access points are not properly geographically distributed
within the network, a device might lose connection to one before it
can reconnect to another. In such a case, seamless roaming cannot
happen and the device will have to go through the whole process of
connection at the IPv6 level. This will generate multicast traffic
as discussed in Section 2.1.
5. Possible solutions
[I-D.yourtchenko-colitti-nd-reduce-multicast] already provides
solutions at the IP layer. These include:
o increasing intervals between Router Advertisements, and possibly
remove the limit of 9000 s set by [RFC4861];
o increasing the timer value for Neighbor Unreachability Detection;
o unicasting Router Advertisements;
o multicast filtering at the infrastructure level (MLD snooping).
At the L2 layer, it suggests using an efficient on-device multicast
filter which would send frames to the IP layer only if their
destination address is registered.
We explore other possible solutions in the next sections.
5.1. Optimizing Router Solicitations retransmissions
Some wireless systems retransmit all multicast packets received, so
that hosts have a better chance to obtain them. This causes a
problem when retransmitted packets are not desirable for hosts.
Without having to implementing a full multicast snooping mechanism,
which can be costly in terms of resources and complexity for small
systems like home boxes, a simple fix can be applied to APs in order
to reduce the amount of multicast traffic retransmitted. APs should
refrain from retransmitting packets destined to the all routers
address (ff02::2), since routers should not be present on the
wireless side. Essentially, Router Solicitations will be concerned.
5.2. Proxying multicast traffic
Desmouceaux Expires January 31, 2015 [Page 8]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
Some multicast traffic is only relevant to routers (for instance, MLD
reports) or can be proxied by them (mDNS, ND). For instance,
[RFC4389] specifies a means to proxy Neighbor Discovery traffic.
Hosts are informed of the router proxying Neighbor Discovery traffic
thanks to a bit in Router Advertisements.
On the same model, a more general option in Router Advertisements
could indicate which multicast addresses a router is able to proxy.
When a host receives such a Router Advertisement, it will record
those addresses. It will then use the router L2 address instead of a
33:33:XX:XX:XX:XX multicast L2 address as destination for
corresponding packets, thus reducing multicast traffic emission. The
router will still be able to know that the final destination is
multicast, since the destination IP address remains multicast (a
behavior permitted by [RFC6085]). A disadvantage of this solution,
though, is that it requires changes to the hosts.
6. Acknowledgements
The author would like to thank Andrew Yourtchenko, Eric Vyncke, Ole
Troan, Brian Hart and Mark Townsley for their precious opinions on
the subject.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
None.
9. References
9.1. Normative References
[IEEE80211]
Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 2012.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O. and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, January 2011.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
Desmouceaux Expires January 31, 2015 [Page 9]
Internet-Draft IPv6 multicast, WiFi power usage August 2014
9.2. Informative References
[I-D.vyncke-6man-mcast-not-efficient]
Vyncke, E., Thubert, P., Levy-Abegnoli, E. and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", Internet-Draft draft-vyncke-
6man-mcast-not-efficient-01, February 2014.
[I-D.yourtchenko-colitti-nd-reduce-multicast]
Yourtchenko, A. and L. Colitti, "Reducing Multicast in
IPv6 Neighbor Discovery", Internet-Draft draft-
yourtchenko-colitti-nd-reduce-multicast-00, February 2014.
[RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4541] Christensen, M., Kimball, K. and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-local Multicast
Name Resolution (LLMNR)", RFC 4795, January 2007.
Author's Address
Yoann Desmouceaux
Cisco
Issy Les Moulineaux, 92130
France
Email: yoann.desmouceaux_ietf@polytechnique.org
Desmouceaux Expires January 31, 2015 [Page 10]