Re: Reducing the battery impact of ND

Don Sturek <> Sat, 11 January 2014 17:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 53C231AE0AB for <>; Sat, 11 Jan 2014 09:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n_oToz1KsDy4 for <>; Sat, 11 Jan 2014 09:36:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2FF4F1AE017 for <>; Sat, 11 Jan 2014 09:36:59 -0800 (PST)
Received: from [] by with NNFMP; 11 Jan 2014 17:36:48 -0000
Received: from [] by with NNFMP; 11 Jan 2014 17:36:48 -0000
Received: from [] by with NNFMP; 11 Jan 2014 17:36:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1389461808; bh=Ivr1XgNzN2FX69skXRtZeHKc2Hq/n4sgkVLkWVdexDk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=Gs2wlVJN0TPxs/e+Ov/hoZ5giqi92DO0NY8oP8LA6rg0v5chXPI29j42kaS4w/eknRdrBD/62WXxZTVQWt/YV0MPTRGaLmxX72IZtOhnMQnLGTstb3uW669o8gsU1XibpBvzdXJJQzCo6Vnadl3nVNukvbxSqmEElMwaYujQn5s=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 3GI4HfcVM1kv0Z7BBKSmPv0J.FfCyPi9JW6uF8RZTEBCcJz r1x73mAW1apT1HQTBnJQ8kRCrpoktPNe2dP3c4vUmXTHB6OO9Ipck8H2jdBY Op9565xAdW_9Ju0c.3pU7ebF1JHWgXTC4Bx05OKx4J89S0TCkDa3WPW5PlNA HEQw6J_m5.0kT_njz00G_BrWBYrrB_SaZ.X2UH5t1pWbLnzqyj6.4g1iJJhY .EvPskPFCvlhMPC3nyJa99OdToQTNuxzFZBlICVxocc.l3Er2cMU_W.y9iv7 eNUk6blOt3T7jy3wgjukecii7uauZf6f4v_Qy.Z30PQeznHIndxDu9FOgFga _yusAHbiokf5.fn3PFAWEVOGBGoACwxYKsTlr5WdbMubiYYPU5kuf0CYU2N4 i5gOVHzSB3IAO17KJ7MDV.1kJVXmBouLkeLy_LQxtlFjf6rHtwMaHrLNQaYH OYyRWdBRbbs2EucaveN3u5KRefkHrqFusszMGlXYR46EcBpS3o.r89lm3jCL oRGX9h3.I5oMI0aHSqySgj6eCUY2nae0myjk6rU1LU1Vc.EhYMt0BxdBl1Q- -
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [] (d.sturek@ with plain []) by with SMTP; 11 Jan 2014 09:36:48 -0800 PST
User-Agent: Microsoft-MacOutlook/
Date: Sat, 11 Jan 2014 09:36:42 -0800
Subject: Re: Reducing the battery impact of ND
From: Don Sturek <>
To: Tim Chown <>, Lorenzo Colitti <>
Message-ID: <>
Thread-Topic: Reducing the battery impact of ND
References: <> <> <EMEW3|2a5cad910dfa2e68d1809f030d2e9d5aq0AHNH03tjc||>
In-Reply-To: <EMEW3|2a5cad910dfa2e68d1809f030d2e9d5aq0AHNH03tjc||>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3472277807_552699"
Cc: 6man Chairs <>, Andrew 👽 Yourtchenko <>, 6man WG <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Jan 2014 17:37:02 -0000

Hi Tim,

For the ZigBee networks, we had to extend mDNS (a now expired draft called
Extended mDNS) since with a ROLL RPL mesh, each hop is defined as a link (so
there was no way to use ff02::fb and reach all devices in a single ROLL RPL
instance, or an attached subnet of Wi-Fi/HomePlug/etc. devices in a single

I hope dnssd takes up this topic and come up with a more complete standard
that covers multi-hop subnets.


From:  Tim Chown <>
Date:  Saturday, January 11, 2014 9:21 AM
To:  Lorenzo Colitti <>
Cc:  6man Chairs <>, 6man WG <>,
Andrew 👽 Yourtchenko <>
Subject:  Re: Reducing the battery impact of ND


On 11 Jan 2014, at 04:25, Lorenzo Colitti <> wrote:

> Andrew,
> thank you for bringing solid data and analysis to the equation. That is always
> appreciated.
> On Sat, Jan 11, 2014 at 8:57 AM, Andrew 👽  Yourtchenko <>
> wrote:
>> 2) The bigger problem - the battery life:
> This can be a real problem, yes. But as you say, I think we can mitigate it
> well without changing ND at all.
>> WiFi is a pretty expensive thing to do, power-wise. To help extend the
>> battery, the mobile devices try very hard to shut off the radio
>> whenever they can. The wireless station would go to sleep, and inform
>> the AP about this fact - so the AP can buffer the frames for it [1].
>> Further optimizations in this area were introduced by 802.11e (WMM-PS)
>> [2], where the frames destined to workstation could be transmitted
>> more efficiently and radio duty cycle is reduced.
>> Spontaneous all-hosts multicasts interfere with these mechanisms, thus
>> the battery drain on the devices is much higher
> One thing that I think we haven't discussed here is that in principle, there
> are *very few* all-hosts multicasts - basically, only RA. Even RS is
> all-routers multicast, not all hosts. So really the only thing we're talking
> about is solicited-node multicasts for NS (and occasional unsolicited NAs,
> which should only really happen when nodes change their MAC addresses. Note
> that I'm not talking about malicious nodes here because any malicious node can
> decide to spam the link with multicast messages regardless of what the ND
> protocol looks like.

This is a useful reminder to consider the use/impact of multicast in the
dnssd work, given one of the scenarios is Zigbee networks. mDNS uses
ff02::fb iirc.


> I think that using multicast instead of broadcast and defining solicited-node
> multicast addresses based on the IID, were very wise choices. This is because
> there are so many different groups (2^24), that even in very large networks,
> each solicited-node multicast group will likely only have one member. So - at
> least in principle - there are two layers at which the battery impact of NS
> packets can be reduced to zero or close to zero:
> 1. If the AP keeps state of what MAC addresses have joined which multicast
> groups, it can selectively turn multicast NS into a set of unicast NS (L2
> unicast; not L3 unicast). This will be a pretty significant bandwidth
> optimization both because a) as you say, unicast is faster than multicast, and
> b) because one multicast NS will almost certainly turn into only one unicast
> NS. Win/win.
> 2. 
> 3. Even if the AP does not do #1, if the wifi chipset in the device keeps
> state of what multicast groups the device has joined, then the wifi chipset
> can simply drop packets that aren't interesting to the device's main CPU. From
> experience we know that this can also lead to massive battery savings - the
> wifi chipset is basically on a lot of the time anyway, because it has to
> listen for beacons and incoming packets, and this sort of filtering can be
> pretty efficient.
> That leaves RAs. Multicast RAs are a bane for battery life, because every time
> a device joins the network, it sends an RS. If the router responds with a
> multicast RA, then all devices on the link get a packet which they didn't
> need. On large wifi networks, I've seen this cause RAs once every 3-4 seconds,
> which is really painful in terms of battery life. Fortunately, there's an easy
> solution here: respond to router solicitations with unicast RAs sent to the
> sender. This is pretty trivial, and it doesn't require any state anywhere.
> There is a corner case where, if 10000 devices come online at the same time
> because the AP just booted up, you can get a thundering herd problem and have
> to send 10000 unicast packets, but this is can be optimized too: if the router
> sees that it's sending more than 100 solicited unicast RAs per second, it can
> simply send a multicast RA instead.
>>  - especially in a typical network where the mobile devices move, and might
>> trigger an RS/RA on each L2 roam between BSSIDs.
> The client devices I'm familiar with don't send RSes when L2 roaming between
> BSSIDs on the same SSID. Is this a bug? Should they?
>> I hear someone saying: "Yes, but this is all about wireless, DC is all
>> different story - it's all switches, they don't hold the state!" - yes
>> and no.
> I'd argue that it's not "yes and no", it's just "no". The state required by
> the approaches I suggest above is the same amount of state as multicast
> snooping, and it's pretty much the same amount of state required by the
> efficient ND approach - but it doesn't require complicating the ND protocol
>> Maybe worth to split the problem area into smaller subsets and see
>> whether a "cheaper" solutions are possible. Let's first take the
>> "multicast RAs" problem, and assume we do the below steps:
>> a) Allow the environments that wish to do so, to send solicited RAs
>> unicast. (standard already permits to do so).
> Yes please!
>> b) Have the hosts restart the  Resilient RS [5] process at 1/2 or so
>> of router lifetime expiry: the router now can have the heuristic to
>> know which hosts are supporting the "unicast RA update" mechanism
>> *and* did not receive the periodic RA which would have been sent
>> usually at 1/3 the lifetime expiry (three RAs per lifetime rule of
>> thumb).
> Yes please!
>> c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to
>> their maximum theoretically possible values (spec says the hosts
>> should already be able to handle those, I did not test though) - this
>> would allow to further reduce the periodic RA frequency, from 2.5
>> hours today to ~18.2 hours, or, if we feel adventurous, put all-ones
>> to be a "solicited-only RAs by default" - thus, unless another router
>> sends an RA with different lifetime, refreshing the router info
>> becomes host-driven, with an option for a router to override at any
>> time.
> This sort of depends what device you have. For example - on a mobile phone,
> receiving one packet every 2.5 hours is *so far down* in the noise that it
> just doesn't matter. Your phone is doing a massive amount of stuff already -
> it's syncing your email, receiving wifi beacons, checking calendar alarms,
> etc. etc. All of that uses way more CPU than receiving one multicast RA.
> There may be other devices that have lower power requirements, though I'm not
> sure - perhaps these devices simply can't use 802.11-style wifi because it's
> too expensive, and so already have to use something like 6LowPAN. I don't know
> if there's a use case here.
>> These steps take care of the "multicast RA" problem. But again, also,
>> each of them by itself brings incremental usefulness, and is doable on
>> a single device => no "chicken and egg", they gradually shrink the
>> issue - and are compatible with the existing tweaks that solve the
>> same problem (in a more layer-violating way).
> Care to work together on a document that provides operational guidance to
> optimize battery impact of ND on wifi networks? Since they involve zero
> protocol changes, v6ops would be a good candidate group for it. And it might
> help persuade vendors that are not your employer to implement stuff like this
> :-)
>> Now let's think of updating the various caches while roaming:
> How much more do you think this sort of thing will help, assuming we do the
> "100% feasible using the existing protocol" stuff above?
>> NB: the above does not take care of the "defending the host's address
>> on behalf of the sleeping node" problem.
> An NS is 72 bytes, and if we do multicast snooping, then a sleeping node is
> only ever going to be woken up if a node with the same last 3 address bytes
> shows up. That should be extremely rare.
> Cheers,
> Lorenzo
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

-------------------------------------------------------------------- IETF
IPv6 working group mailing list Administrative Requests: