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: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= <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
>>>
>>>
>
>