Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
Andrew đź‘˝ Yourtchenko <ayourtch@gmail.com> Thu, 23 July 2015 11:10 UTC
Return-Path: <ayourtch@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 29D8C1A89FD for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 04:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 E_MZdufTHo0j for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 04:09:57 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 F05E11A8729 for <v6ops@ietf.org>; Thu, 23 Jul 2015 04:09:56 -0700 (PDT)
Received: by ietj16 with SMTP id j16so189469288iet.0 for <v6ops@ietf.org>; Thu, 23 Jul 2015 04:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dFIYyIlraPPFpar7P7IN3EZTwLg7Zeq4OW7M9WhiNiU=; b=x5ku5OlrWCIs3GWy2BF5q1ocKcUg8HRfAxmt85+TXIZO0ucKE8H3VT8k4uGJq0kpCZ q7v746Jp9ixpSaG3jhy2k8rUp1T72EbB7ObHOrkuwQOme16lp+PyyDQR47t25g0d9o70 LjcMloFprg8ap+g6s9JnXJfhNvsLJO814ZfQQ+InIB+9NMAGpeywFvEHLquZqptxUmFA nGr9YnBhcrxVbYksxt05Y3S1XQN9tqYXFTAnhN4y6FQ7i4298IIAvycCqnPnJRLW/wIO Z7DprdvwpO9P1EGqZtFKfQf6ZntN83tk8RUhjakgG/mRmgyMgf9i+sJ8xFn4isSakeuy K0lw==
MIME-Version: 1.0
X-Received: by 10.107.128.214 with SMTP id k83mr13201365ioi.7.1437649796412; Thu, 23 Jul 2015 04:09:56 -0700 (PDT)
Received: by 10.107.182.7 with HTTP; Thu, 23 Jul 2015 04:09:56 -0700 (PDT)
In-Reply-To: <77D742C8-C295-4813-8392-DE272EAEA39E@delong.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> <CAPi140OsFT3cZXBF0xowVH8=Svs3cEtEGv9Rk4X1e-z2JKPLeg@mail.gmail.com> <77D742C8-C295-4813-8392-DE272EAEA39E@delong.com>
Date: Thu, 23 Jul 2015 04:09:56 -0700
Message-ID: <CAPi140OqA7RkNyr6hRFAyWae3KysU167=09Yi9PNNQO+z+uqHA@mail.gmail.com>
From: Andrew đź‘˝ Yourtchenko <ayourtch@gmail.com>
To: Owen DeLong <owen@delong.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Qv2FgqfydnS-NxSMY8Y1a5EX6RE>
Cc: v6ops list <v6ops@ietf.org>, "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" <draft-yc-v6ops-solicited-ra-unicast@tools.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: Thu, 23 Jul 2015 11:10:02 -0000
On 7/22/15, Owen DeLong <owen@delong.com> wrote: > >> On Jul 22, 2015, at 01:19 , Andrew 👽 Yourtchenko <ayourtch@gmail.com> >> wrote: >> >> My brain can not compile this pseudocode... >> >> reset_multicast_timer resets multicast_ra_time_remaining to what value ? > > To whatever value it would get reset to when a multicast_ra is transmitted > normally. > > Why is this difficult to comprehend? > >> In the large-scale WiFi networks I operate I send multicast RA once in >> 30 minutes, and an immediate unicast solicited RA upon RS. > > Seems reasonable. > >> >> If the "reset" is done to the MinRtrAdvInterval...MaxRtrAdvInterval, >> then this algorithm would optimize last 15 seconds of these 30 minutes >> ? > > Yep. > > If you think the 15s mark should be increased, I’ve got no problem with > that… > > If you think it should be configurable, I’m OK with that, too. > > If you think it should be computed as a fraction of some value related to > {Min,Max}RtrAdvInterval, > then propose something, I’m probably OK with that as well. > > The point is it seems to me if you’re reasonably close to transmitting a > multicast, then it makes > sense to answer the solicitation with a multicast and reset the multicast > timer. Otherwise, send > a unicast RA. > > If this seems like a good idea other than arguing about the value of > “reasonably close”, then I > think we’re in general agreement and I’m mostly willing to let others pick > the value or formula > for determining “reasonably close”. Upon more thinking, this algorithm is actually a harmful idea - regardless of the settings it does not save any packets while deceiving everyone involved (including yourself) that it does, and is of course more complex than a single knob. --a > > Owen > >> >> --a >> >> On 7/21/15, 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> 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] new draft: draft-yc-v6ops-solicited-ra-un… fred
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Tore Anderson
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Ole Troan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Jen Linkova
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Tarko Tikan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Sri Gundavelli (sgundave)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Gert Doering
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Ole Troan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Gert Doering
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Hemant Singh (shemant)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Nabil Benamar
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alejandro Acosta
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Jen Linkova
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Jared Mauch
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Nabil Benamar
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Gert Doering
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Ole Troan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith