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

Lorenzo Colitti <lorenzo@google.com> Wed, 22 July 2015 10:23 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 6146D1AD1A6 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 03:23:01 -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 rpE5mLTy8sS3 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 03:22:58 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 7CE341AD16B for <v6ops@ietf.org>; Wed, 22 Jul 2015 03:22:58 -0700 (PDT)
Received: by ykfw194 with SMTP id w194so108527580ykf.0 for <v6ops@ietf.org>; Wed, 22 Jul 2015 03:22:58 -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=y1PP+OwROsoVZaSiOH0OS87o0U2PYJyAV0UyiJOAwyM=; b=GuiBS81aTrfkg8c23n99up++Yaz6fXXXsmcQ9BZH4lU8HHwT7EmLtFD41TII+jYwj5 YokFOlUqoTVgzH4Kl1esimgKx7Wi8tLzuP6CXCHZRzRpcqwjvUzcZ7ZfHzIePxlZMwtd YtTTOqFzibBOPCn1DePm8/rZHwscQVOwLziYpk4H2V+/xFsnn8lC6xn8nu9twYBd54oG ukYkLF0L/PmURhz69M3M/OfLJMYXL68G3lJ/NhIZ/GFwNwQdaXWSewg0wq7zyMC+hk44 7f82cq6sCwPe+Sx2NET7cTwwp+Ph9UOvjCKf5MYfwQ2SpNJ6vp7O6/7mwW531GxH0HVn o7Yg==
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=y1PP+OwROsoVZaSiOH0OS87o0U2PYJyAV0UyiJOAwyM=; b=NJSKon2CIsWypgr1o5aUwCaCHSAr+ZNudDWYZfzxG1OFaUtujvwM6o2byCzzCEFUHg CZBK1KIUrycRNbjZLpkntFMS+fTpHOrs7izIcBgplvEtETSMKQ5WzRCAcXlg4tJoYaUs 5b7hCyfugf/k/anpr0FdGXlyIoizufO//VX8tomKfw9JWMTjSrhelkYxsm8XvohayBKX GgR7LnAZYy5EgIddWiCVf+BGyh7HqoAAaT4McaqOxKTjjQdrj/5dTm0O1rsC1YgQJwmP wrjAA9iWKmsDLXh5+TpysbwYF3hykd1q80vfgAF8KAUWQD+xdkBQUaEx5bMO0lWiZEeB kl9Q==
X-Gm-Message-State: ALoCoQkmgOFKVU277oIoi1q6v8S/3IMrKZ9HvfgBqYC7mWzrA+nbPMFVvvBWQ/lF8OEwsxvTGXtl
X-Received: by 10.129.77.213 with SMTP id a204mr1683222ywb.40.1437560577736; Wed, 22 Jul 2015 03:22:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 03:22:38 -0700 (PDT)
In-Reply-To: <55AF0964.1060006@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>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 22 Jul 2015 12:22:38 +0200
Message-ID: <CAKD1Yr2y7e3bK8oYorCBPfdBAiyEkY5JJLaE+ixGczQdDjSPuw@mail.gmail.com>
To: Alejandro Acosta <alejandroacostaalamo@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140c55294cc40051b742713
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/OXJVHFes2ZRO6GTS4MLFQXS5Bms>
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 10:23:01 -0000

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>; 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>; 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>;
>> wrote:
>> >
>> > On 7/20/15, Erik Nordmark < <nordmark@acm.org>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
>> >>> https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> v6ops@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
>
> _______________________________________________
> v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>