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

Andrew πŸ‘½ Yourtchenko <ayourtch@gmail.com> Wed, 22 July 2015 07:20 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 4D9831ACEC4 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 00:20:39 -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 DyoeANlyKy0m for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 00:20:38 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 D68A71ACDF0 for <v6ops@ietf.org>; Wed, 22 Jul 2015 00:20:37 -0700 (PDT)
Received: by igr7 with SMTP id 7so60979827igr.0 for <v6ops@ietf.org>; Wed, 22 Jul 2015 00:20:37 -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=qL9wrtkhxF9BaV4IN7XtiEeV2B16LctCLhzeOpLgMOU=; b=mtoh2xJHIhOyCnxStSqVx5a2ReKF626OkPZ61WYo6AbmqcN26l1xukT1S5WJTLYkA/ cjo9JwZ8q+ZiI9Pr4DKOE++xjFvVrYIiiNY5VeOncDuzir+J4SJKMZt9aJRMtrp0OKao I7vWC0ZFiTOlc2tO6N5KVCSVZyrz8iNvxgmoI1z4kyaiuJclhBrCScWw/LqX35MEH4O8 OxpGyyK+V5hJMEo0nmQheuYOvU8si/j0fp59oHdduI+Q/5Si9r6j/iWsUpc2xb9L5gwl mt14N/8Jp5Ac0jRZQ+Y/W/3ndf2XY23zPxeZuM5ivZRMsoggtzb4LoMFX3p6yFN+MWpi S+Tw==
MIME-Version: 1.0
X-Received: by 10.50.178.133 with SMTP id cy5mr29603812igc.5.1437549637305; Wed, 22 Jul 2015 00:20:37 -0700 (PDT)
Received: by 10.107.182.7 with HTTP; Wed, 22 Jul 2015 00:20:37 -0700 (PDT)
In-Reply-To: <55AE5270.8000301@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> <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> <55AE5270.8000301@gmail.com>
Date: Wed, 22 Jul 2015 09:20:37 +0200
Message-ID: <CAPi140N2qftrcqeBm7bq=21pdReR6YceBn-G4zPTiKOm92R8eA@mail.gmail.com>
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= <ayourtch@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/5eEwf_E-PS9OzUoEPmRqls0PvWc>
Cc: "v6ops@ietf.org" <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 07:20:39 -0000

> On 21 Jul 2015, at 16:08, Alexandru Petrescu <alexandru.petrescu@gmail.com>; wrote:
>
>
>
> Le 17/07/2015 18:57, Andrew Yourtchenko a Γ©crit :
>>
>> On 17 Jul 2015, at 09:34, Fred Baker (fred) <fred@cisco.com>; 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.
>>
>> values of T less than 3 seconds would make performance worse than today.
>>
>> There are many things to optimize for:
>>
>> - wireless airtime
>> - bandwidth used by RAs
>> - CPU usage sending unicast RAs by router
>> - energy consumption on devices for more than one medium
>
> and:
>
> - fast handovers: on some links the more frequent the multicast RAs the
> faster the handovers are, i.e. less packet loss for end nodes, less
> glitches in the video conference stream.
>

If the network sends the periodic RAs frequently enough to avoid the
glitches of the video stream, this is explicitly *NOT* the network we
are concerned about in this draft.

Also, we wanted to be very focused what we talk about in this
document, to be able to ship it quicker.

We can say "does not apply to 802.11p, applies to 802.11(a|b|g|n|ac).
Applicability to other networks is left at readers' discretion".

Or something along these lines of that - feel free to propose the text
if the above is not what you had in mind.

--a

> Alex
>
>>
>> Some of them are orthogonal, some of them contradict each other, some of them align. People may want to optimize differently.
>>
>> I'd opt for simplicity - and use the text Erik Kline posted in another email.
>>
>> This would allow the developers to adapt for individual use cases on the spot.
>>
>> --a
>>
>>> _______________________________________________
>>> 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