One document matched: draft-desmouceaux-ipv6-mcast-wifi-power-usage-01.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-desmouceaux-ipv6-mcast-wifi-power-usage-01" ipr="trust200902">
<front>
<title abbrev="IPv6 multicast, WiFi power usage">Power consumption due to IPv6 multicast on WiFi devices</title>
<author fullname="Yoann Desmouceaux" initials="Y" surname="Desmouceaux">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<code>92130</code>
<city>Issy Les Moulineaux</city>
<country>France</country>
</postal>
<email>yoann.desmouceaux_ietf@polytechnique.org</email>
</address>
</author>
<date day="1" month="August" year="2014" />
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>IPv6</keyword>
<keyword>multicast</keyword>
<keyword>wifi</keyword>
<keyword>power consumption</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Multicast is widely used in IPv6 for configuration purposes through the Neighbor Discovery protocol <xref target="RFC4861" />. On IEEE 802.11 wireless links, this can have a negative impact on low-energy devices such as smartphones, as stated in <xref target="I-D.vyncke-6man-mcast-not-efficient" />. The 802.11 protocol <xref target="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 <xref target="RFC4541" />, hence all devices will be woken up when multicast traffic is pending.</t>
<t>In this document, we provide data illustrating the issue at 3 levels:
<list style="symbols">
<t>typical multicast traffic emitted by a device when joining an IPv6 network, and 'background multicast noise' generated once connected;</t>
<t>power consumption statistics for wireless devices when confronted to multicast traffic;</t>
<t>orders of magnitude of connections frequencies and durations in large-scale wireless networks.</t>
</list>
Confronting these 3 levels makes it possible to model the power consumption overhead of multicast traffic on typical large wireless networks.</t>
<t>We finally discuss possible solutions at the IP and the 802.11 level.</t>
</section>
<section title="IPv6 typical multicast traffic" anchor="typical-traffic">
<section title="Behavior when joining a network" anchor="join">
<t>When joining an IPv6 network, devices usually emit the following multicast traffic:
<list style="numbers">
<t>duplicate address detection for the link-local address;</t>
<t>router solicitation;</t>
<t>duplicate address detection for the SLAAC address;</t>
<t>duplicate address detection for the SLAAC privacy address.</t>
</list>
In addition, MLDv2 <xref target="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.</t>
<t>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.</t>
<t>On Linux and Apple MacOS X clients that were tested, joining the network also induces Multicast Domain Name System (mDNS) <xref target="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) <xref target="RFC4795" /> multicast traffic when they connect to the network.</t>
</section>
<section title="Behavior once connected">
<t>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).</t>
<t>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 protocols, as it was measured:</t>
<figure>
<artwork>
Protocol ICMPv6 mDNS LLMNR WS-D
Ratio 0.53 0.33 0.12 0.03
</artwork>
</figure>
<t>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:</t>
<!--
1 device emits 4.5/160 = 0.028 packets/second, i.e. 101 frames per hour
-->
<figure>
<artwork>
Protocol ICMPv6 mDNS LLMNR WS-D
Frames per hour 53 33 12 3
</artwork>
</figure>
</section>
</section>
<section title="Power consumption induced by multicast traffic" anchor="consumption">
<t>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.</t>
<t>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.</t>
<t>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.)</t>
<t>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.</t>
<t>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.</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>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.</t>
<t>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.</t>
</section>
<section title="Large-scale wireless networks">
<t>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.</t>
<t>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.</t>
<section title="Typical orders of magnitude" anchor="orders-of-magnitude">
<t>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.</t>
<section title="Arrival rates">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Connection durations">
<t>Once clients are connected, duration of their connections follow a less typical probability distribution, whose form is represented below:</t>
<figure>
<artwork>
dur. distr.
^
| ||
| ||
| |\
| | |
| | |
| | |
| | \
| | \_
| | \__
| | \_____
|____| \______
| \_________
+--------------------------------------> t
</artwork>
</figure>
<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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Influence of such networks over devices">
<t>In this section, we model the influence of a large wireless network over a device, in terms of power consumption.</t>
<t>Let us assume that in average, N devices are present in the network, and that the arrival rate is lambda. (See <xref target="orders-of-magnitude" /> for typical numerical values). Then, <xref target="typical-traffic" /> 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:</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>Finally, using <xref target="consumption" />, 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:</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>Thus, battery consumption induced by multicast traffic will be doubled in a network of 30 nodes where the arrival rate is 10 minutes.</t>
</section>
<section title="Roaming">
<t>Depending on the configuration of the wireless network, roaming might have different consequences on multicast traffic emission.</t>
<t>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.</t>
<t>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 <xref target="join" />.</t>
</section>
</section>
<section title="Possible solutions">
<t><xref target="I-D.yourtchenko-colitti-nd-reduce-multicast" /> already provides solutions at the IP layer. These include:
<list style="symbols">
<t>increasing intervals between Router Advertisements, and possibly remove the limit of 9000 s set by <xref target="RFC4861" />;</t>
<t>increasing the timer value for Neighbor Unreachability Detection;</t>
<t>unicasting Router Advertisements;</t>
<t>multicast filtering at the infrastructure level (MLD snooping).</t>
</list>
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.</t>
<t>We explore other possible solutions in the next sections.</t>
<section title="Optimizing Router Solicitations retransmissions">
<t>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.</t>
<t>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.</t>
</section>
<section title="Proxying multicast traffic">
<t>Some multicast traffic is only relevant to routers (for instance, MLD reports) or can be proxied by them (mDNS, ND). For instance, <xref target="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.</t>
<t>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 <xref target="RFC6085" />). A disadvantage of this solution, though, is that it requires changes to the hosts.</t>
</section>
</section>
<section title="Acknowledgements">
<t>The author would like to thank Andrew Yourtchenko, Eric Vyncke, Ole Troan, Brian Hart and Mark Townsley for their precious opinions on the subject.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>None.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.4861.xml"?>
<?rfc include="reference.RFC.3810.xml"?>
<?rfc include="reference.RFC.6762.xml"?>
<?rfc include="reference.RFC.6085.xml"?>
<reference anchor="IEEE80211">
<front>
<title>Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name='IEEE Standard' value='802.11' />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4541.xml"?>
<?rfc include="reference.RFC.4795.xml"?>
<?rfc include="reference.RFC.4389.xml"?>
<?rfc include="reference.I-D.draft-yourtchenko-colitti-nd-reduce-multicast-00.xml"?>
<?rfc include="reference.I-D.draft-vyncke-6man-mcast-not-efficient-01.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:07:56 |