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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 22 July 2015 12:07 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 117F01A00EE for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:07:52 -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 ntG-lTzebfRl for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:07:46 -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 276621A0161 for <v6ops@ietf.org>; Wed, 22 Jul 2015 05:07:45 -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 t6MC7hs7021101 for <v6ops@ietf.org>; Wed, 22 Jul 2015 14:07:43 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0952A2027B5 for <v6ops@ietf.org>; Wed, 22 Jul 2015 14:11:19 +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 F31D6200C4C for <v6ops@ietf.org>; Wed, 22 Jul 2015 14:11: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 t6MC7hbA019053 for <v6ops@ietf.org>; Wed, 22 Jul 2015 14:07:43 +0200
To: v6ops@ietf.org
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>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55AF878E.1090200@gmail.com>
Date: Wed, 22 Jul 2015 14:07: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: <CAKD1Yr2y7e3bK8oYorCBPfdBAiyEkY5JJLaE+ixGczQdDjSPuw@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/dtwFX7hmrlQatrfmP7vg90xkQAc>
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:07:52 -0000

"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>>
> 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>> 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>> wrote:
>>         >
>>         > On 7/20/15, Erik Nordmark
>>         <<mailto:nordmark@acm.org>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>
>>         >>> 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 <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
>