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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 22 July 2015 12:12 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549021A0390 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8-HnWrz4XYJ for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:12:19 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601771A0173 for <v6ops@ietf.org>; Wed, 22 Jul 2015 05:12:18 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MCCGE6022761; Wed, 22 Jul 2015 14:12:16 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 584652027AA; Wed, 22 Jul 2015 14:15:51 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4A5E22027A8; Wed, 22 Jul 2015 14:15:51 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MCCFIh022549; Wed, 22 Jul 2015 14:12:15 +0200
To: Lorenzo Colitti <lorenzo@google.com>
References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <CAO42Z2x7mNFbB_w_+W+80pY+LeCAKXaOBXMmQvkcaMSWhwW60g@mail.gmail.com> <EF21B630-5D0A-415A-A93F-9058900CC80C@cisco.com> <CAO42Z2zAqMXhBZ2wa=q0wtHGhMpMWU9TSjfFyd2quiki9w0oSw@mail.gmail.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <CAO42Z2w3fOxGJHasKqYZRfGZ2u=7FnZBm+jgLtgDvfZ7HYW=iw@mail.gmail.com> <CAO42Z2z+DwOin23HQTysrZ9dNP924+LQ-vOExmJc_xZUEB4yCQ@mail.gmail.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <CAPi140P+kfpyQKzCRDA7bZQRowQx_YRcZYa85hHe64g4AvsVTg@mail.gmail.com> <C5901B99-F3A7-4DB0-8216-38D95EA89D6A@delong.com> <CAMugd_Xox_zYv6oftPdAZVZGz+FYZo+Dm-QRSSn4pMEj-x1XjA@mail.gmail.com> <55AF0964.1060006@gmail.com> <CAKD1Yr2y7e3bK8oYorCBPfdBAiyEkY5JJLaE+ixGczQdDjSPuw@mail.gmail.com> <55AF878E.1090200@gmail.com> <CAKD1Yr1xnKaYrFG4izZ4MbB1aRh89CGzTkc1ZjjryOgvdN0hQw@mail.gmail.com>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55AF889F.6080206@gmail.com>
Date: Wed, 22 Jul 2015 14:12:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr1xnKaYrFG4izZ4MbB1aRh89CGzTkc1ZjjryOgvdN0hQw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/0wAFbquPQ69LyJnejM6lPMqYsto>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 12:12:24 -0000

"... 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
> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> 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
>         <alejandroacostaalamo@gmail.com
>         <mailto:alejandroacostaalamo@gmail.com>
>         <mailto:alejandroacostaalamo@gmail.com
>         <mailto:alejandroacostaalamo@gmail.com>>>
>         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
>             <owen@delong.com <mailto:owen@delong.com>
>                  <mailto:owen@delong.com <mailto:owen@delong.com>>> 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
>                      <ayourtch@gmail.com <mailto:ayourtch@gmail.com>
>             <mailto:ayourtch@gmail.com <mailto:ayourtch@gmail.com>>> wrote:
>                      >
>                      > On 7/20/15, Erik Nordmark
>                      <<mailto:nordmark@acm.org
>             <mailto:nordmark@acm.org>>nordmark@acm.org
>             <mailto:nordmark@acm.org>
>
>                      <mailto:nordmark@acm.org
>             <mailto:nordmark@acm.org>>> 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
>                      >>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>             <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>                      >>> https://www.ietf.org/mailman/listinfo/v6ops
>                      >>
>                      >> _______________________________________________
>                      >> v6ops mailing list
>                      >> v6ops@ietf.org <mailto:v6ops@ietf.org>
>             <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>                      >> https://www.ietf.org/mailman/listinfo/v6ops
>                      >>
>                      >
>                      > _______________________________________________
>                      > v6ops mailing list
>                      > v6ops@ietf.org <mailto:v6ops@ietf.org>
>             <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>                      > https://www.ietf.org/mailman/listinfo/v6ops
>
>                      _______________________________________________
>                      v6ops mailing list
>             v6ops@ietf.org <mailto:v6ops@ietf.org>
>             <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>             https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>                  _______________________________________________
>                  v6ops mailing list
>             v6ops@ietf.org <mailto:v6ops@ietf.org>
>             <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>             https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>              _______________________________________________
>              v6ops mailing list
>         v6ops@ietf.org <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org
>         <mailto:v6ops@ietf.org>>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>         _______________________________________________
>         v6ops mailing list
>         v6ops@ietf.org <mailto:v6ops@ietf.org>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>