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

[Alexandru Petrescu <[e-mail]>]

Hmm, it's different hardware, different drivers, different brand names. 
  They have different energy consumption, I measured that.

For the laws of physics: I am interested in asking, and give opinion, 
about how much energy it takes to send or receive one 1280 MTU IPv6 
packet.

I looked at the presentation in 6man titled "Preliminary RA power 
observations on wifi".

There was a RG called EERG which died recently and seemed to discuss 
this as well.

But we dont have an agreement about how much energy packets take, and 
whether or not it's worth trying to make protocols more or less 
energy-aware.

Alex

Le 22/07/2015 14:13, Lorenzo Colitti a écrit :
> I'm sure that the huawei E392 obeys the laws of physics as well.
>
> On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     "... on Androids and iPhones"?
>
>     But not on huawei E392.
>
>     Alex
>
>
>     Le 22/07/2015 14:10, Lorenzo Colitti a écrit :
>
>         I'm told the problem affects iPhones as well.
>
>         On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu
>         <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[e-mail]
>         <mailto:[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]>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>
>                  <mailto:[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]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>                           <mailto:[e-mail]
>         <mailto:[e-mail]> <mailto:[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]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                      <mailto:[e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>>> wrote:
>                               >
>                               > On 7/20/15, Erik Nordmark
>                               <<mailto:[e-mail]
>         <mailto:[e-mail]>
>                      <mailto:[e-mail]
>         <mailto:[e-mail]>>>[e-mail]
>         <mailto:[e-mail]>
>                      <mailto:[e-mail] <mailto:[e-mail]>>
>
>                               <mailto:[e-mail]
>         <mailto:[e-mail]>
>                      <mailto:[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]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>                      <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>                               >>>
>         https://www.ietf.org/mailman/listinfo/v6ops
>                               >>
>                               >>
>         _______________________________________________
>                               >> v6ops mailing list
>                               >> [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>                      <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>                               >> https://www.ietf.org/mailman/listinfo/v6ops
>                               >>
>                               >
>                               >
>         _______________________________________________
>                               > v6ops mailing list
>                               > [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>                      <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>                               > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>           _______________________________________________
>                               v6ops mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                      <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>                           _______________________________________________
>                           v6ops mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                      <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>                       _______________________________________________
>                       v6ops mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail]
>         <mailto:[e-mail]>
>                  <mailto:[e-mail] <mailto:[e-mail]>>>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>                  _______________________________________________
>                  v6ops mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>              _______________________________________________
>              v6ops mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>