Re: Reducing the battery impact of ND

[Don Sturek <[e-mail]>]

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
residence).

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

Don



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

Hi,

On 11 Jan 2014, at 04:25, Lorenzo Colitti <[e-mail]> 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 <[e-mail]>
> 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.

Tim

> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-------------------------------------------------------------------- IETF
IPv6 working group mailing list [e-mail] Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------