Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

[Lorenzo Colitti <[e-mail]>]

I'm told the problem affects iPhones as well.

On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu <
[e-mail]> wrote:

> "Reducing battery impact of RAs on Androids"?
>
> Alex
>
> Le 22/07/2015 12:22, Lorenzo Colitti a écrit :
>
>> Thanks for all the feedback. We have posted a -01 addressing some of the
>> feedback we got. The new version also contains a new recommendation not
>> to send periodic RAs too frequently, so we have changed the title to
>> "Reducing battery impact of Router Advertisements".
>>
>> https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01
>>
>> If there are no objections, we will upload this as a WG document in the
>> next few days.
>>
>> On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>     Hi There,
>>        I also support this document, it's very positive to see that this
>>     algorithm will save energy.
>>
>>     Regards,
>>
>>     Alejandro,
>>
>>     El 7/21/2015 a las 6:11 PM, Nabil Benamar escribió:
>>
>>>     Hi Folks,
>>>
>>>     I support this document which is very informative, useful and its
>>>     implementation will certainly reduce energy consumption due to
>>>     excessive Multicast RA sent. The proposed algorithm seems to be
>>>     suitable for this end !
>>>
>>>
>>>     Best regards
>>>
>>>
>>>
>>>     On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>         It seems to me that the following algorithm would be
>>>         relatively easy to implement
>>>         and provide reasonable network optimization…
>>>
>>>
>>>         On receipt of an RS:
>>>
>>>                 if(multicast_ra_time_remaining > 15 seconds)
>>>                 {
>>>                   Send_Unicast_ra
>>>                 }
>>>                 else
>>>                 {
>>>                   Send_Multicast_ra
>>>                   reset_multicast_timer
>>>                 }
>>>
>>>         In this way, if the timing is reasonably close, you multicast
>>>         a packet you were about to send
>>>         anyway, but if the timing isn’t close, you’re not wasting
>>>         multicast bandwidth answering a single
>>>         node where nobody else cares.
>>>
>>>         Overall, I’ve always thought that multicast response to RS was
>>>         kind of silly. It’s probably most
>>>         harmful on WiFi.
>>>
>>>         Owen
>>>
>>>         > On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko
>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>         >
>>>         > On 7/20/15, Erik Nordmark
>>>         <<mailto:[e-mail]>[e-mail]
>>>
>>>         <mailto:[e-mail]>> wrote:
>>>         >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote:
>>>         >>>> So the next logical thing to do would be to have the
>>>         router default to
>>>         >>>> unicast Router Advertisements, measure the rate of
>>>         received Router
>>>         >>>> Solicitations, and switch to multicast RA mode past a
>>> certain
>>>         >>>> threshold to cover this sort of situation. Once the
>>>         number of RSes
>>>         >>>> falls, it switches back to unicast RA mode.
>>>         >>>>
>>>         >>>> That would get rid of the configuration knob proposed in
>>>         this ID, and
>>>         >>>> is behaviour that I think could be universal for all link
>>>         types,
>>>         >>>> rather than just for the case of wireless ones with
>>>         mobile devices.
>>>         >>> If it were me implementing it, I think I would go about
>>>         this in a little
>>>         >>> different way, hopefully simpler. I would want to send at
>>>         most one (e.g.,
>>>         >>> either zero or one) RA per some interval (a second?). In
>>>         the normal case,
>>>         >>> that is sent unicast. However, having sent a unicast RA at
>>>         time t, if I
>>>         >>> now receive another RS before t+1, I send the next one (at
>>>         time t+1) as a
>>>         >>> multicast.
>>>         >>
>>>         >> First of all I support this document as a WG document.
>>>         >>
>>>         >> But in terms of implementation, isn't it simpler to
>>>         always(*) respond to
>>>         >> a RS with a unicast RA?
>>>         >
>>>         > Yes. I did not respond on-list yet - but from operational
>>>         perspective
>>>         > "always send solRA unicast" / "always send solRA multicast"
>>>         definitely
>>>         > wins in my book, and I'd avoid premature optimizations (but
>>>         maybe we
>>>         > can say the implementers are explicitly free to do their own
>>>         > optimizations if they see fit)
>>>         >
>>>         > That said, will be very interesting to hear data from folks
>>>         who will
>>>         > run "all-unicast solRA", in real networks and then compare
>>>         the effect
>>>         > of their proposal optimizations on their real-world scenarios.
>>>         >
>>>         >> As background, the text in RFC4861 comes from the old
>>>         concern that all
>>>         >> devices might boot at the same time when the power is
>>>         re-established
>>>         >> after a building power failure; that doesn't happen since
>>>         most devices
>>>         >> (laptops, smartphones, IoT devices) have batteries today.
>>>         In that case
>>>         >> it might have made sense to sending fewer RA messages by
>>>         using multicast.
>>>         >>
>>>         >> (*) the only case in RFC 4861 when I think a multicast
>>>         response might be
>>>         >> considered is when the source IPv6 address in the RS is the
>>>         unspecified
>>>         >> address. Further, an implementation which rate limits
>>>         received RS
>>>         >> packets (e.g., CoPP in a router) might also want to detect
>>>         when the rate
>>>         >> limit might have dropped RS packets and multicast an RA in
>>>         that case.
>>>         >>
>>>         >>
>>>         >> I do wonder why implementations haven't already changed to
>>>         send unicast
>>>         >> solicited RA, and whether it would make a difference if we
>>>         have an
>>>         >
>>>         > TBH that's my concern as well. I think we should tweak the
>>>         text in
>>>         > 4861 to encourage a bit more consideration on the
>>>         implementer's side.
>>>         >
>>>         >> informational document asking them to do this.
>>>         Alternatively we could
>>>         >> have a proposed standard which updates section 6.2.6 to
>>>         change the "MAY
>>>         >> unicast" to a "SHOULD unicast".
>>>         >
>>>         > Yeah, I actually have had the different text aimed for 6man,
>>> but
>>>         > Lorenzo's concern was 6man would say "there is no protocol
>>>         update
>>>         > here, go away", so he rewrote it for v6ops.
>>>         >
>>>         > We should probably discuss this at the mic and get the
>>>         opinion of the
>>>         > 6man chairs - if there is no outright "no" on this, a
>>>         normative doc
>>>         > would be a better way to convince the implementers ?
>>>         >
>>>         >>
>>>         >> FWIW the draft incorrectly refers to section 6.2.4 instead
>>>         of 6.2.6.
>>>         >
>>>         > Nice catch, thanks!
>>>         >
>>>         > --a
>>>         >
>>>         >>
>>>         >> Thanks,
>>>         >>    Erik
>>>         >>
>>>         >>>
>>>         >>>
>>>         >>> _______________________________________________
>>>         >>> v6ops mailing list
>>>         >>> [e-mail] <mailto:[e-mail]>
>>>         >>> https://www.ietf.org/mailman/listinfo/v6ops
>>>         >>
>>>         >> _______________________________________________
>>>         >> v6ops mailing list
>>>         >> [e-mail] <mailto:[e-mail]>
>>>         >> https://www.ietf.org/mailman/listinfo/v6ops
>>>         >>
>>>         >
>>>         > _______________________________________________
>>>         > v6ops mailing list
>>>         > [e-mail] <mailto:[e-mail]>
>>>         > https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>         _______________________________________________
>>>         v6ops mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     v6ops mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>