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

Lorenzo Colitti <lorenzo@google.com> Wed, 22 July 2015 12:14 UTC

Return-Path: <lorenzo@google.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 D77901B2FFC for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 sAXPMJ_Grn3I for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:14:24 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7851B301A for <v6ops@ietf.org>; Wed, 22 Jul 2015 05:14:12 -0700 (PDT)
Received: by ykdu72 with SMTP id u72so190547741ykd.2 for <v6ops@ietf.org>; Wed, 22 Jul 2015 05:14:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/CEcQsn0rCnJgR0BX1BWWTzsE0LOJHwfyVrHBZBQVEk=; b=b5aYnyEcpoLJsRVdkLyhBb85UgDtISeQL69oNLDZ5LF5Kvss4xQrqTVpp3He00J9bg Yc/NUhYhIoX7MC1TNckWixWIiwj+/bq1srB+WKsezPLlFXCPl6WOYWUlxjBJRFh84Mmi sjSg7l/q0SClBWJwGp1Jidw/9KJdj4TcxVWOt62j8+mzDbMXglF29+JervMH2J+qKjzT kVvgpVq+jJPXdyoIKx6vDkO5rv6+w1BmHYiCXGnHQhJzRBArUFjwuqkfubs+tpM2A6hx V0n8Fj7pr5tySbSZIf9hUuUv/ZOlaDY6IMvBlpy/+bFRRdhxo5qEO+iWKSJorcWztUpu nAew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/CEcQsn0rCnJgR0BX1BWWTzsE0LOJHwfyVrHBZBQVEk=; b=WhBABBfd69ahQCvb5oqFIcS3jJFeZ6LwxIE1yQ0tAm9Zvg82WiPkKudhpeNDkdDMD6 Q63dHlacK+IWZM445x6Xh5M+AO6H2bAaz5PVOd7rYMqpHbIo/kev564LYAmZ7AGC5o3g mD4kdZMik4zxNpMS64Tm7eP+JT/rFjxpEJNdWz21k8i/Vh8K56qb4bdxsnGalfuRhNHS hahGdCav0JW/wFYkWY9FuIBaxtj/eUJimT5GaSZUdkIO1l2c9paFsYgrJ5dPIKjpFELb Y7q/yI9zRtefgexQUV5RtEvu+4MW+ET+zobggE0T6TULhkJq/ASaKi/dsnKZpif2cHoY HxkA==
X-Gm-Message-State: ALoCoQkgPF3YZjjXiQFF9+QonKzRNRLUIuCzTBqK0DUgh0N2p2nECWwR3BWbWIPc8+JPyG1nNq/R
X-Received: by 10.13.247.3 with SMTP id h3mr2134187ywf.142.1437567252077; Wed, 22 Jul 2015 05:14:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 05:13:52 -0700 (PDT)
In-Reply-To: <55AF889F.6080206@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>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 22 Jul 2015 14:13:52 +0200
Message-ID: <CAKD1Yr153D-R7FyYh_harv7L22Ac1RnSaqa6p7yPWWEP1_7UGQ@mail.gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c0802a066f5fd051b75b539
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/iycmXuFnMKwPqesOW-lnkepO_EU>
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:14:29 -0000

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 <
alexandru.petrescu@gmail.com>; 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
>> <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 [image: 👽]
>> 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
>>
>>
>>
>