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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 22 July 2015 13:02 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 DCA5E1B331E for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 06:02:51 -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 79gDz1sX01tb for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 06:02:49 -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 AE0781B3312 for <v6ops@ietf.org>; Wed, 22 Jul 2015 06:02:47 -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 t6MD2hFn008711; Wed, 22 Jul 2015 15:02:43 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CD2F62028D7; Wed, 22 Jul 2015 15:06:18 +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 BEC842028F5; Wed, 22 Jul 2015 15:06:18 +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 t6MD2gCX029020; Wed, 22 Jul 2015 15:02:43 +0200
To: Jen Linkova <furry13@gmail.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> <55AF889F.6080206@gmail.com> <CAFU7BAShd1qOhLi5aRhO31_WFHFXZyUdgMEAi4CGZ=t1cL49JA@mail.gmail.com>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55AF9472.9010209@gmail.com>
Date: Wed, 22 Jul 2015 15:02:42 +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: <CAFU7BAShd1qOhLi5aRhO31_WFHFXZyUdgMEAi4CGZ=t1cL49JA@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/mC2_hyfrSk37jTTXlNXJFhwGwmI>
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 13:02:52 -0000


Le 22/07/2015 14:31, Jen Linkova a écrit :
> On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com>; wrote:
>>
>> "... on Androids and iPhones"?
>>
>> But not on huawei E392.
>
> I'm not sure what the fact that huawei E392 is not affected by a
> particular issue proves.
> So far we know that
> - there are platforms affected;
> - there is one unaffected platform.

I think we discuss here a smartphone world.

Android and smartphones in general are great things that happened to 
Internet, but there is more to it: raspberry pis, and various other 
small yet non-smartphone platforms.

Alex


>
> Therefore I believe it is perfectly find for the title to be 'Reducing
> battery impact of Router Advertisements'. If a particular network and
> its devices are not affected - good, the network administrators MAY
> (or SHOULD?) ignore the draft and not apply the recommendations.
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>