Subject: Reducing the battery impact of ND

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 11 Jan 2014 13:25:42 +0900

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
<[email-masked]>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.

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

---

From: Tim Chown <[email-masked]>
Date: Sat, 11 Jan 2014 17:21:52 +0000

Hi,

On 11 Jan 2014, at 04:25, Lorenzo Colitti <[email-masked]> 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 <[email-masked]> wrote:
> This can be a real problem, yes. But as you say, I think we can mitigate it well without changing ND at all.
>  
> 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:
> 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.
> 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'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
>  
> 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.
>  
> 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 :-)
>  
> How much more do you think this sort of thing will help, assuming we do the "100% feasible using the existing protocol" stuff above?
> 
> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Don Sturek <[email-masked]>
Date: Sat, 11 Jan 2014 09:36:42 -0800

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 <[email-masked]>
Date:  Saturday, January 11, 2014 9:21 AM
To:  Lorenzo Colitti <[email-masked]>
Cc:  6man Chairs <[email-masked]>, 6man WG <[email-masked]>,
Andrew 👽 Yourtchenko <[email-masked]>
Subject:  Re: Reducing the battery impact of ND

Hi,

On 11 Jan 2014, at 04:25, Lorenzo Colitti <[email-masked]> wrote:

> 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.
>  
> 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?
> 
> 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.
>  
> 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
> :-)
>  

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

---

From: "cb.list6" <[email-masked]>
Date: Sat, 11 Jan 2014 09:47:16 -0800

I don't have much to offer this thread yet from a technical solution
perspective, but i can share that Samsung and others deactivate ipv6 when
the smartphone screen is off due to battery issues with ipv6 and wifi.

This is not for anyone to judge, this is a problem statement and the
current solution deployed on 10s (100s) of millions of hosts that go from
dual-stack to single stack when the screen is off. We do do quantitative
battery drain studies, and the ipv6-off configuration is meaningful better.

These phones do a fair amount of background traffic to major ipv6 enabled
clouds (google , facebook, yahoo ...) when the screen is of, so that is an
ipv6 opportunity missed ... we need a better solution to take to the
smartphone oems so they can keep ipv6 on and still meet the battery drain
targets.

We already know home routers dont get upgraded ever, so a client based
solution would be nice.  Said another way, i can help drive deployment of a
client based solution.

CB

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 11 Jan 2014 20:20:22 +0000

Hi Cameron,

Thanks for sharing this useful info.

from dual-stack to single stack when the screen is off. We do do quantitative battery drain studies, and the ipv6-off configuration is meaningful better.

I would suspect ipv4-off configuration would have comparable result. IoW, it is the single-stack that drains less battery than that of dual-stack. Nothing specific to v6, one would hope.

Cheers,
Rajiv

On Jan 11, 2014, at 12:48 PM, "cb.list6" <[email-masked]<mailto:[email-masked]>> wrote:

I don't have much to offer this thread yet from a technical solution perspective, but i can share that Samsung and others deactivate ipv6 when the smartphone screen is off due to battery issues with ipv6 and wifi.

This is not for anyone to judge, this is a problem statement and the current solution deployed on 10s (100s) of millions of hosts that go from dual-stack to single stack when the screen is off. We do do quantitative battery drain studies, and the ipv6-off configuration is meaningful better.

These phones do a fair amount of background traffic to major ipv6 enabled clouds (google , facebook, yahoo ...) when the screen is of, so that is an ipv6 opportunity missed ... we need a better solution to take to the smartphone oems so they can keep ipv6 on and still meet the battery drain targets.

We already know home routers dont get upgraded ever, so a client based solution would be nice.  Said another way, i can help drive deployment of a client based solution.

CB

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Sat, 11 Jan 2014 19:58:45 +0000

Lorenzo,

> well without changing ND at all.

assuming some cooperation between L2 and L3, yes :-)

> there are *very few* all-hosts multicasts - basically, only RA. Even RS is

Thanks to Tim for mentioning dns-sd. It is another big offender.
Funnily enough, both RAs and DNS-SD are primarily acting up in the
larger-scale multi-AP environments, due to roaming: according to my
experiments, at least an iPhone roaming from an AP to AP acts as if it
has reattached to another link (and for good reason - there can be
plenty of setups where this is the only robust behavior).

In the home WLAN, the impact of the problem is quite less. Still not
zero, but less - I am enjoying not having to maintain the DNS for the
gadgets at home and just run mDNS on all of them - and the battery
life is okay-ish.

> regardless of what the ND protocol looks like.

While a node can jam the airtime with sending the packets, all packets
first have to travel to the AP, which then retransmits them to all
clients.
So, in the environments where you can not trust the wireless clients,
you can still keep the handle on the clients (with the L2 tweaks
again, of course).

> likely only have one member.

This is indeed quite an elegant approach.

But, the funny part - an intermediate L2.5 can track who has which
address based on DAD/traffic, or  multicast group membership, or,
both. Realistically you have to do both, and this is how the IPv4
already has the similarly (and maybe more) efficient implementation of
ARP for WiFi, for those implementations that care to optimize that
stuff.

Nonetheless, the 2^24 groups do allow additional flexibility.

> So - at least in principle - there are two

Yes. MLD snooping++.

>    sort of filtering can be pretty efficient.

Do you have a pointer to read up more on these results ?

AFAIK, the "radio is always on" is not always true, because:

1) each WiFi packet has a field ("duration/id") which determines how
long the sending station will take for the transmission, so the radio
can be in a tiny "nap" mode for this period (since it *knows* the
carrier is busy anyway).

2) a node going to sleep can indicate so to an AP, and can sleep until
an AP notices incoming frame to be sent onto the air, buffers it, and
sends a beacon an indication that there is traffic for this station.
Till then the radio can stay in a relatively low power mode. (I'd need
to refresh what happens for the multicast packets in this case). Once
the radio sees that it has pending packets, it wases up and sends the
poll packet to the AP, which then resends the buffered packets to the
station, which are then acked by the station..

This "pending traffic" stuff is a bitmap - so I'd imagine not a whole
lot of processing is possible besides that.

so, in my understanding, lone packets are bad, whatever they are.

> unicast RAs per second, it can simply send a multicast RA instead.

One AP can get up to 2007 clients, so it will be a multitude of APs
that will have to boot up and come online.

Each client, before it comes to sending the RS, has to exchange at
least 4 packets with the AP (authentication request/response,
association request/response). This of course has to happen over the
air - which will naturally rate-limit the process.

In short: you *really* don't want APs with 10000 connected clients to
lose them all at once - with or without IPv6 :-) - so for realistic
scenarios, unicast solicited RAs might work fine. (I don't have the
practical experience of rebooting a 10000-node network in such a
situation, can't tell where the bottleneck is going to be :-)

> between BSSIDs on the same SSID. Is this a bug? Should they?

Thinking more - I might be mixing the DNS-SD packets being sent. I
tested in the office capturing the DNS-SD traffic (also all-hosts)
while walking around. I do not remember if I captured the RA. I'll
retest on monday.

Intuitively, in the well-behaved enterprise environment we probably
don't want to be gratuitous about multicast  - the infra knows all
well about the node. But I can easily see where a mobile device
manufacturer, confronted with a multitude of weird 2-3 uncoordinated
APs home WLAN setups, could be compelled to flash the packets "just to
be sure".

> efficient ND approach - but it doesn't require complicating the ND protocol

Lots of enterprises have to migrate VMs around the place - which, in
the absence of any hooks, for the host looks like it magically wakes
up in a completely different place in the network, and for the network
looks like the host has disappeared in one place and reappeared in the
other. And presumably there is a L2-like link between these two
places, with X layers of CAM tables, at the same time some parts of
this stuff run atop the overlays across the L3 network. All this time,
you want to ensure that this MAC address that reappeared, is a
legitimate MAC address, and not someone spoofing your server.

Also, on the WiFi the roaming decisions are host-driven and undoable
(of the reauthentication to the new AP fails, the host can stay at the
old AP), in the VM migration case they are external to the host and
host has no control over them.

So, it is not the same situation.

> don't know if there's a use case here.

if you go unicast-only-RA (the all-ones case), you can achieve all the
benefits that you speficied power-savings wise, with zero changes to
the pipes between the router and the hosts. Some networks may have
control over the hosts, limited control over the routers, and less of
control over the wifi inbetween.

Also, for a major part of WiFi networks (university campus,
enterprise, large-scale event, etc) 18 hours is "infinity" for
practical purposes: a huge percentage of the clients will not be on
the network for that long.

This would provide a valuable pain relief mechanism in case there is
some multicast-related issue which prevents the multicast RAs reaching
the client.

The other reason for this, besides the above, is that since the host
is required to handle all the ranges of the lifetimes anyway, we might
as well have the behavior 100% predictable and they do not blow up if
someone decides to send such a packet.

> might help persuade vendors that are not your employer to implement stuff

Definitely interested! Let's sync unicast.

> "100% feasible using the existing protocol" stuff above?

I don't know. Depends on how many L2 belts and suspenders we are
aiming to make unnecessary.

I suppose we could see how much remains after axing the issue with the
existing protocol.

> shows up. That should be extremely rare.

As I wrote above, my understanding was by the time you are awake
enough to poke into the MAC address, you are way too much awake
already :-)

But as I said I'd be interested to see more info to educate myself
better on this !

--a

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Sat, 11 Jan 2014 20:17:53 +0000

> battery drain studies, and the ipv6-off configuration is meaningful better.

Is this with or without IPv6 configured (thus, RAs) on the home gateway ?

I'm keeping my fingers crossed that this could be one of the cases
where the WiFi chipset is IPv4-smart and IPv6-unsmart, therefore
requiring the CPU for anything IPv6 related..

Did you have a chance to further narrow down the root cause of this ?

--a

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Sat, 11 Jan 2014 20:44:19 +0000

> shows up. That should be extremely rare.

Found this:

http://cseweb.ucsd.edu/~snoeren/papers/slomo-nsdi13.pdf

The exhibit of interest is table 1: if I interpret it correctly,
merely receiving the frame is 30% more power consumption compared to
idle.

--a

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Jan 2014 09:23:34 -0800

On 1/10/14 8:25 PM, Lorenzo Colitti wrote:
 > <[email-masked] <mailto:[email-masked]>> wrote:
 >

Lorenzo,

One of your "yes please" below is a change to ND - Andrew's b) about 
restarting RS would require a (small) standards update.

And if you work out the details on b) I suspect you'll find that to 
completely avoid the periodic multicast RAs the routers need to know 
whether hosts expect periodic RA as opposed to all the hosts doing the 
RS restart. That would imply some more protocol change.

And just to be perfectly clear, I don't think assuming (near) perfect 
MLD snooping including in WiFi APs is undesirable. Hence my focus has 
been to remove as much as possible of the ND multicasts including the 
DAD and NS packets.

But my overall observation is that if we think we can fix (even a subset 
of) this without a standards update, then we are just fooling ourselves.

Regards,
    Erik

 > 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
 > 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.
 >
 > layers at which the battery impact of NS packets can be reduced to zero
 > or close to zero:
 >
 >     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.
 >     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.
 >
 >
 > 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
 >
 > 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.
 >
 > 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
 >
 > How much more do you think this sort of thing will help, assuming we do
 > the "100% feasible using the existing protocol" stuff above?
 >
 > 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
 >
 >

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Jan 2014 09:20:35 -0800

Lorenzo,

Regards,
    Erik

> stuff like this :-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 18 Jan 2014 07:49:26 +0900

> restarting RS would require a (small) standards update.

We should try to get that into draft-6man-resilient-rs.

> whether hosts expect periodic RA as opposed to all the hosts doing the RS
> restart. That would imply some more protocol change.
>

You don't need to avoid them. You just need to make them infrequent enough
that they are not a substantial cause of power drain. I know from solid
data that on a device like a mobile phone on a wifi network, an RA every 30
minutes is *way* down in the noise in terms of power consumption. (While
"one RA every 3 seconds because the router sends a multicast RS to everyone
every time a device joins the network" *does* have an impact).

> And just to be perfectly clear, I don't think assuming (near) perfect MLD
> snooping including in WiFi APs is undesirable. Hence my focus has been to
> remove as much as possible of the ND multicasts including the DAD and NS
> packets.
>

You don't need to do the snooping on the APs. You can do it on the client
side, in the wifi firmware. The power savings between "received but
filtered out in wifi firmware" and "received, passed to the main processor
and ignored" are substantial; again, for a mobile phone on wifi, we have
data on this.

> of) this without a standards update, then we are just fooling ourselves.

It depends what sort of device you're talking about. If you're talking
about a mobile phone, then we can fix it for sure. If you're talking about
a sensor whose battery needs to last for months, then maybe not. But that's
what we have 6LowPAN for.

Cheers,
Lorenzo

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Jan 2014 21:01:46 -0800

On 1/17/14 2:49 PM, Lorenzo Colitti wrote:
> On Fri, Jan 17, 2014 at 9:20 AM, Erik Nordmark <[email-masked]
> <mailto:[email-masked]>> wrote:
>

It seems to be out of scope for the problem resilent-rs set out to solve 
which was loss issues for the initial RS. It might not be wise to expand 
that drafts scope to also cover (part of) efficient-nd.

    Erik

>     whether hosts expect periodic RA as opposed to all the hosts doing
>     the RS restart. That would imply some more protocol change.
>
>
> You don't need to avoid them. You just need to make them infrequent
> enough that they are not a substantial cause of power drain. I know from
> solid data that on a device like a mobile phone on a wifi network, an RA
> every 30 minutes is *way* down in the noise in terms of power
> consumption. (While "one RA every 3 seconds because the router sends a
> multicast RS to everyone every time a device joins the network" *does*
> have an impact).
>
>     And just to be perfectly clear, I don't think assuming (near)
>     perfect MLD snooping including in WiFi APs is undesirable. Hence my
>     focus has been to remove as much as possible of the ND multicasts
>     including the DAD and NS packets.
>
>
> You don't need to do the snooping on the APs. You can do it on the
> client side, in the wifi firmware. The power savings between "received
> but filtered out in wifi firmware" and "received, passed to the main
> processor and ignored" are substantial; again, for a mobile phone on
> wifi, we have data on this.
 >
>
>     But my overall observation is that if we think we can fix (even a
>     subset of) this without a standards update, then we are just fooling
>     ourselves.
>
>
> about a mobile phone, then we can fix it for sure.

If all you want is to max the RA timers to > 30 minutes then you don't 
need a standards change. But the other things that have been discussed 
seem to require an update to RFC 4861.

FWIW I don't have a problem with an opt-in update to 4861. I even think 
efficient-nd is the way to go because it reduces overall ND multicast 
traffic and not just your narrow focus on mobile phone battery life.

    Erik

> If you're talking
> about a sensor whose battery needs to last for months, then maybe not.
> But that's what we have 6LowPAN for.
>
> Cheers,
> Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Jan 2014 12:34:35 -0800

> that drafts scope to also cover (part of) efficient-nd.

To my mind, sending an RS when the RA lifetime is about to expire is a
robustness fix, not an efficiency fix. In a world where IPv6 is optional
and IPv4 is the main protocol, just having your IPv6 address expire is not
necessarily a problem. But in a world where IPv6 is the main protocol, then
hosts will probably want to try harder to keep their IPv6 address around.

> traffic and not just your narrow focus on mobile phone battery life.

The tradeoff is that efficient ND adds more state to the network about host
addresses and changes a pretty core part of the IPv6 specs. I think that if
we can reduce the battery impact of multicast traffic, we will have fixed
most of the problem without doing either of those, and to my mind, that's a
much better tradeoff.

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Jan 2014 23:35:01 +0100

Lorenzo,

> It seems to be out of scope for the problem resilent-rs set out to solve which was loss issues for the initial RS. It might not be wise to expand that drafts scope to also cover (part of) efficient-nd.

the abstract has the following text:
   "Furthermore, on some links, unsolicited multicast
   Router Advertisements are never sent and the mechanism in this
   document is intended to work even in such scenarios."

> To my mind, sending an RS when the RA lifetime is about to expire is a robustness fix, not an efficiency fix. In a world where IPv6 is optional and IPv4 is the main protocol, just having your IPv6 address expire is not necessarily a problem. But in a world where IPv6 is the main protocol, then hosts will probably want to try harder to keep their IPv6 address around.

I believe you have found a bug in the resilient-rs draft.
could you reply to the WGLC thread for that document and notify the authors?

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jan 2014 13:44:20 -0800

On 1/21/14 12:34 PM, Lorenzo Colitti wrote:

> and IPv4 is the main protocol, just having your IPv6 address expire is
> not necessarily a problem. But in a world where IPv6 is the main
> protocol, then hosts will probably want to try harder to keep their IPv6
> address around.

Lorenzo,

Whether you call it "efficiency" or "robustness" doesn't make much 
difference from a technical or a process perspective.

The approach you advocate is insufficient to ensure better robustness 
for at least two reasons:
  - the lifetime(s) of the prefixes are independent of the lifetimes of 
the default routers. Hence in this approach a host can have default 
routers but no prefixes.
  - the reachability state in the NCEs is independent of the default 
router list - per RFC 4861 the router stays in the default router list 
even if it is unreachable. Thus your last router might be unreachable 
but with remaining lifetime - it was the next-to-last router in the list 
that was reachable.

Solving those without risking hosts sending lots of RSs during failure 
events or resulting in a steady state of RSs from hosts seems tricky.

>     FWIW I don't have a problem with an opt-in update to 4861. I even
>     think efficient-nd is the way to go because it reduces overall ND
>     multicast traffic and not just your narrow focus on mobile phone
>     battery life.
>
>
> The tradeoff is that efficient ND adds more state to the network about
> host addresses and changes a pretty core part of the IPv6 specs. I think
> that if we can reduce the battery impact of multicast traffic, we will
> have fixed most of the problem without doing either of those, and to my
> mind, that's a much better tradeoff.

Changing from periodic RAs to (effectively) periodic RSs as you propose 
would change RFC 4861 is a very fundamental way.

It may or may not be the right thing to do for the future, but I think 
that requires a bit more work then forcing some edits into a document 
which has almost completed the WG process. I think resilient-rs has 
significant benefits in its current form and scope.

Regards,
    Erik

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jan 2014 22:52:33 +0100

Erik,

> I think that text can be read in different ways.
> 
> One way is within the scope of the  initial configuration (which is what the RSs are for) is robust even if there are no unsolicited multicast RAs.
> 
> Another way is that the document intended to get rid of the need for unsolicited multicast RAs.
> 
> Based on the title, name, and content of the document, my conclusion is that the first reading is much more accurate.

the first reading implies that the host looses connectivity after router lifetime seconds.
"never sent" doesn't leave much room for interpretation.

> It makes sense having the document be clear on its scope, so some clarification is in order.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jan 2014 22:57:13 +0100

Erik,

> Whether you call it "efficiency" or "robustness" doesn't make much difference from a technical or a process perspective.
> 
> The approach you advocate is insufficient to ensure better robustness for at least two reasons:
> - the lifetime(s) of the prefixes are independent of the lifetimes of the default routers. Hence in this approach a host can have default routers but no prefixes.
> - the reachability state in the NCEs is independent of the default router list - per RFC 4861 the router stays in the default router list even if it is unreachable. Thus your last router might be unreachable but with remaining lifetime - it was the next-to-last router in the list that was reachable.
> 
> Solving those without risking hosts sending lots of RSs during failure events or resulting in a steady state of RSs from hosts seems tricky.
> 
> Changing from periodic RAs to (effectively) periodic RSs as you propose would change RFC 4861 is a very fundamental way.
> 
> It may or may not be the right thing to do for the future, but I think that requires a bit more work then forcing some edits into a document which has almost completed the WG process. I think resilient-rs has significant benefits in its current form and scope.

not trying to speak for Lorenzo, but I don't think he is proposing replacing periodic RAs with periodic RSs.
example: a host successfully does router discovery. RA lifetime is relatively short, e.g. 3 * router advertisement interval.
host doesn't receive any of the multicast RAs (network drops them or whatever).

what would be the best behaviour for the end-user?
a) host sits quietly and waits for a periodic RA
b) host restarts the initial router discovery

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jan 2014 14:01:10 -0800

[I don't think this made it to the list.]

-------- Original Message --------
Subject: Re: Reducing the battery impact of ND
Date: Wed, 22 Jan 2014 13:48:13 -0800
From: Erik Nordmark <[email-masked]>
To: Ole Troan <[email-masked]>, Lorenzo Colitti <[email-masked]>
CC: Erik Nordmark <[email-masked]>, Andrew Yourtchenko 
<[email-masked]>,        6man Chairs <[email-masked]>, 
6man WG <[email-masked]>

One way is within the scope of the  initial configuration (which is what
the RSs are for) is robust even if there are no unsolicited multicast RAs.

Another way is that the document intended to get rid of the need for
unsolicited multicast RAs.

Based on the title, name, and content of the document, my conclusion is
that the first reading is much more accurate.

> could you reply to the WGLC thread for that document and notify the authors?

It makes sense having the document be clear on its scope, so some
clarification is in order.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jan 2014 14:00:05 -0800

> "never sent" doesn't leave much room for interpretation.

That would only be true if resilent-rs claims that no periodic 
unsolicited RAs are needed. I don't see any such text in the protocol 
specification in that draft (section 2-4). The introductory text talks 
about scenarios, and perhaps that scenario text doesn't match what the 
proposed protocol actually does?

Thus the document needs to be more clear.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jan 2014 14:12:10 -0800

> not trying to speak for Lorenzo, but I don't think he is proposing replacing periodic RAs with periodic RSs.

Ole,

I think that is the effective result of what you two are cooking up.

> host doesn't receive any of the multicast RAs (network drops them or whatever).

You are speculating about some particular failure or misfeature in the 
network that makes it (persistently? sometimes?) drop multicast RAs. It 
would be good to flesh out that particular failure mode to see
  - whether it is realistic, and
  - what impact it has elsewhere.

For instance, the failure could be that all ICMP packets to the host are 
dropped (due to some misconfigured security policy - we've seen those in 
IPv4). That would drop unicast RAs as well, and affect the old path MTU 
discovery protocol.

Or it could be that link-local multicast is misconfigured or broken, 
resulting in DNSSD and other protocols breaking.

Having every host on the planet send a RS every 30 seconds "just in 
case" doesn't sound helpful.

    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jan 2014 14:48:34 -0800

On Wed, Jan 22, 2014 at 1:44 PM, Erik Nordmark <[email-masked]> wrote:

> the default routers. Hence in this approach a host can have default routers
> but no prefixes.
>

This can be tricky to implement, but in principle, the host has this
information already.

>  - the reachability state in the NCEs is independent of the default router
> list - per RFC 4861 the router stays in the default router list even if it
> is unreachable. Thus your last router might be unreachable but with
> remaining lifetime - it was the next-to-last router in the list that was
> reachable.
>

I agree that there are a lot of corner cases here.

> that requires a bit more work then forcing some edits into a document which
> has almost completed the WG process. I think resilient-rs has significant
> benefits in its current form and scope.
>

Fair enough. That said - if that's what we want to do, then resilient-rs
should make it clear that it is only for initial solicitations and thus
does not specify or allow behaviour on multicast-capable links where there
are no periodic multicast RAs, because the IPv6 standards as written do not
work on such links.

---

From: Ole Troan <[email-masked]>
Date: Thu, 23 Jan 2014 00:41:22 +0100

Erik,

again, no hats.

> I think that is the effective result of what you two are cooking up.

I cannot claim credit for cooking up that dish.
aren't you proposing to do exactly that, replace periodic RAs with periodic RSs in:
draft-chakrabarti-nordmark-6man-efficient-nd

> You are speculating about some particular failure or misfeature in the network that makes it (persistently? sometimes?) drop multicast RAs. It would be good to flesh out that particular failure mode to see

it's relatively trivial to reproduce, but I suppose you can argue that setting timers that way is a misconfiguration.
802.11 networks are multicast challenged, so I would expect drops to be somewhat common.
a more robust RS retransmit mechanism will help that somewhat.

> For instance, the failure could be that all ICMP packets to the host are dropped (due to some misconfigured security policy - we've seen those in IPv4). That would drop unicast RAs as well, and affect the old path MTU discovery protocol.
> 
> Or it could be that link-local multicast is misconfigured or broken, resulting in DNSSD and other protocols breaking.
> 
> Having every host on the planet send a RS every 30 seconds "just in case" doesn't sound helpful.

true, although it wouldn't be 'just in case'. I think you are making a good argument that the current RS/RA mechanism is designed quite well.

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 29 Jan 2014 22:20:29 -0800

On 1/22/14 3:41 PM, Ole Troan wrote:
> I cannot claim credit for cooking up that dish. aren't you proposing 
> to do exactly that, replace periodic RAs with periodic RSs in: 
Ole,

The difference is between trying to replace periodic RAs by adding 
periodic RSs from all the hosts, but still needing the periodic RAs 
versus actually removing the need for periodic and muticast RAs.

efficient-nd has the hosts tell the routers "I don't need a periodic RA" 
by the hosts including the ARO.
Thus even on a potentially mixed link, the routers can be smart.

But trying to accomplish the same thing without some additional 
information in the packets can't remove the periodic RAs as far as I can 
tell - it can only add load.
> a more robust RS retransmit mechanism will help that somewhat.
Occasional loss is handled by having the period RA timer be less than 
the default router lifetime (by 3x in the default values). Thus some RAs 
can be lost without any effect. If your multicast loss rate is higher 
than the config on the routers can change that ratio.

Using unicast RSs could be more efficient (FWIW resilent-rs is about 
multicast RS - hard to know what proposal we are talking about when 
there isn't an actual complete proposal written up). But if the 
multicast period RAs have to be there to handle unmodified hosts you 
haven't gained much.
> true, although it wouldn't be 'just in case'. I think you are making a good argument that the current RS/RA mechanism is designed quite well.
I'm merely arguing that it has a consistent design - worked well on 
yellow coax Ethernet.
A different consistent and complete design might make sense for today's 
more multicast challenged networks.

But I don't think that is just a tweak here and there - it would be a 
different design.
I've been exploring this space for a while (starting in 6lowpan) and I'd 
be interested in working out a different design.
There are ideas in efficient-nd, but that isn't complete.

The frustrating thing is that the same folks that argue that the WG 
shouldn't work on a different design (targeting multicast challenged 
links), keep on suggesting tweaks. If the WG thinks we should work on 
improving ND for such links (and perhaps also improve it for battery 
operated hosts), then let's do that work. If not, then let's stop 
suggesting tweaks.

    Erik

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 11:22:53 +0100

Erik,

> The frustrating thing is that the same folks that argue that the WG shouldn't work on a different design (targeting multicast challenged links), keep on suggesting tweaks. If the WG thinks we should work on improving ND for such links (and perhaps also improve it for battery operated hosts), then let's do that work. If not, then let's stop suggesting tweaks.

before designing anything new, I would like to see:
 - a clear description of the problem(s)
 - an analysis of how well we can do with existing protocols

does that sound fair?

cheers,
Ole

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 Jan 2014 06:12:03 -0500

>  - an analysis of how well we can do with existing protocols

... and can someone please remind me what exactly was wrong with ARP?
Other than the fact that v4 uses it?!

W

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 30 Jan 2014 10:15:31 -0800

>   - an analysis of how well we can do with existing protocols
efficient-nd has that. If there are specific requests to clarify its 
description I'm all ears.

But perhaps we should first determine whether the WG wants to work on 
something in this area, and whether efficient-nd is a reasonable 
starting point.

So far I hear folks saying that we shouldn't work on this area, but at 
the same time providing suggestions (which have some issues as we've 
seen on the list) to improve things.
So I'm confused.

    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jan 2014 10:38:50 -0800

> operated hosts), then let's do that work. If not, then let's stop

What tweaks are we talking about? The major change that's being suggested
here is to increase the robustness of initial attach by changing "try three
times and then give up" to "exponential backoff". I don't think anyone
disagrees with that, right?

As for unicast RAs, that's an operational issue. The specs allow it, and as
Ole says, before going and changing the specs, we should hear (perhaps from
v6ops?) that this is a real-world problem, and that changing the specs is
the only or best way to fix that problem.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jan 2014 10:41:40 -0800

>  Other than the fact that v4 uses it?!

It's not energy-efficient. When anyone sends an ARP request, every node on
the link has to wake up to process it, even though the packet is useful for
only one node. Typically, ARP is also chattier than ND in terms of
multicast/broadcast packets, because (in most implementations) it relies on
timeouts rather than unreachability detection via unicast probes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jan 2014 10:42:59 -0800

On Thu, Jan 30, 2014 at 10:15 AM, Erik Nordmark <[email-masked]> wrote:

> So far I hear folks saying that we shouldn't work on this area, but at the
> same time providing suggestions (which have some issues as we've seen on
> the list) to improve things.
>  So I'm confused.

Perhaps those folks are saying that they would like to see improvements in
this area, as long as they can be made without major changes to the way the
ND specs work.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 31 Jan 2014 23:49:02 -0800

> Other than the fact that v4 uses it?!

Warren,

Are you asking about the specifics of this topic (how to save on battery 
and multicast), or a general question on the original motivation for ND?

On the more general question:

ARP didn't have any of
  - NUD (called dead gateway detection back in the days),
  - prefix discovery,
  - router discovery,
  - address allocation (bootp -> dhcp was brand new and unproven at the 
time)
(I might be missing something.)
ARP only had the address resolution functionality.

There was a perceived need to be able to handle multiple prefixes and 
addresses per interface, and a way to renumber those addresses. The 
nascent DHCPv4 wasn't architected to support multiple addresses.

We had RFC 1256 (ICMP router discovery) as a protocol with very limited 
deployment for one of the above pieces.

We wanted a more extensible packet format than ARP and reusing IP/ICMP 
seemed like a good idea since it could enable reusing IP security 
mechanisms. (Much later when SeND was designed it turned out reusing 
IPsec was hard - but the more extensible packet format was key.)

For the more general question of battery and multicast/broadcast, folks 
seem to agree that current ND (with address resolution spread across a 
large number of multicast addresses) is more scalable than ARP's 
broadcast. (But on WiFI where broad/multicast is lower bandwidth and 
less reliable they have the same issue.)

    Erik