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

[Alejandro Acosta <[e-mail]>]

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 <[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]
> https://www.ietf.org/mailman/listinfo/v6ops