Subject: [v6ops] unicast RA to save battery: link-layer joining multicast groups

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 15:10:02 +0200

On another hand,

IEEE 802.11bgn multicast groups (33::1 etc) are 'joined' at MAC layer by 
setting filters.  (maybe even by MAC messaging for joining MAC multicast 
groups).

Maybe we can request the Hosts to set local filters to not receive 
multicast RAs.  Or request the Hosts short on energy to express interest 
in these IPv6 multicast groups.

Alex

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 22 Jul 2015 10:34:52 +0200

This is what some phones do today and is exactly the problem we are
trying to solve.

https://code.google.com/p/android/issues/detail?id=32662

--a

On 7/21/15, Alexandru Petrescu <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 14:06:39 +0200

Thanks for the pointer, but that's a long discussion, it's hard to draw 
quickly a conclusion on it.

I would think to argue that if Android has a problem in this then it's 
an Android problem.

If it's a particular driver problem (dependent on the card of that 
samsung phone) then fix that problem.

Maybe it's not so.

But I am sure the linux devices I use dont consume more power when 
receiving more RAs, on wifi.

And even if they did, I have enough batteries and enough other sources 
of energy to provide them in order to be able to make handovers fast 
enough to not loose 1 single packet.

Not sure whether the goal here is to save energy?

Alex

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 22 Jul 2015 14:18:17 +0200

You proposed dropping all multicast RAs when device is I standby. I commented that the devices are already doing it and it is exactly a problem that we are trying to solve with the draft, thus the suggestion is unhelpful. 

Makes sense ?

--a

Sent from my iPhone

> On 22 Jul 2015, at 14:06, Alexandru Petrescu <[email-masked]> wrote:
> 
> Thanks for the pointer, but that's a long discussion, it's hard to draw quickly a conclusion on it.
> 
> I would think to argue that if Android has a problem in this then it's an Android problem.
> 
> If it's a particular driver problem (dependent on the card of that samsung phone) then fix that problem.
> 
> Maybe it's not so.
> 
> But I am sure the linux devices I use dont consume more power when receiving more RAs, on wifi.
> 
> And even if they did, I have enough batteries and enough other sources of energy to provide them in order to be able to make handovers fast enough to not loose 1 single packet.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 11:58:29 +0200

If in addition to battery, one problems is: Router drops incoming
facetime call to a standby smartphone.

The drop is because Router does not buffer the call during its search
for the smartphone's MAC address (NS/NA).

A call made of two sequenced packets would suffice, two hammers
hitting a bell.

But the smartphone could also periodically send an unsolicited NA just
before standing by.

Of course, provided that I understand the problem in addition to the
battery problem.

And y es, let us discuss f2f tomorrow.

Alex

Le 22/07/2015 14:18, Andrew Yourtchenko a écrit :
> You proposed dropping all multicast RAs when device is I standby. I
> commented that the devices are already doing it and it is exactly a
> problem that we are trying to solve with the draft, thus the
> suggestion is unhelpful.
>
> Makes sense ?
>
> --a
>
> Sent from my iPhone
>
>> And even if they did, I have enough batteries and enough other
>> sources of energy to provide them in order to be able to make
>> handovers fast enough to not loose 1 single packet.
>>
>>> This is what some phones do today and is exactly the problem we
>>> are trying to solve.
>>>
>>>> On 7/21/15, Alexandru Petrescu <[email-masked]>
>>>> wrote: On another hand,
>>>>
>>>> IEEE 802.11bgn multicast groups (33::1 etc) are 'joined' at MAC
>>>> layer by setting filters.  (maybe even by MAC messaging for
>>>> joining MAC multicast groups).
>>>>
>>>> Maybe we can request the Hosts to set local filters to not
>>>> receive multicast RAs.  Or request the Hosts short on energy to
>>>> express interest in these IPv6 multicast groups.
>>>>
>>>> Alex
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]