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

Andrew 👽 Yourtchenko <ayourtch@gmail.com> Wed, 22 July 2015 12:36 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 162351B32D0 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:36:57 -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 QThyYSlwLFMd for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 05:36:55 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 278031B32CC for <v6ops@ietf.org>; Wed, 22 Jul 2015 05:36:55 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so170313890wib.0 for <v6ops@ietf.org>; Wed, 22 Jul 2015 05:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F7M3OYkY4EnIAbxED/wRsTvyhOMP533UnVhnHXiRML4=; b=vz5JunMokMEGppplJU3W3VAywQt55IMyapot6zk+iUWJ3aSeFAUih5PSsns4u8Mw8T gNEhI1qM+3+aYWOygZtXyJoHJlQokNqR/cQt413ICKrNFcEBoPrkBwG6IwN8FPZqyCvD MkpOQ4RgSWc0n5jD7VWfHNWgQDjcDE9jYG8SzmK3TSsTxEdkRDXI/J6qS/oH0+lini5k euW5Bucy16PNr3R07LaW9txDn3MauR58VlJURUr9xgpSuuHzE+5hm09yk3HlmwrAY1jz /AhjeXDPlv11IlPWxXHyjbbZ0aBJYk8auS4yIc8H6PfjA6ofk3rqwrLpazUbjoqWTsKy 2fEQ==
X-Received: by 10.180.82.230 with SMTP id l6mr39880569wiy.61.1437568613864; Wed, 22 Jul 2015 05:36:53 -0700 (PDT)
Received: from ?IPv6:2001:67c:1231:998:9900:5b6f:6e05:7e42? ([2001:67c:1231:998:9900:5b6f:6e05:7e42]) by smtp.gmail.com with ESMTPSA id x6sm21881240wiy.6.2015.07.22.05.36.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 05:36:52 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= <ayourtch@gmail.com>
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <55AF85F5.7070407@gmail.com>
Date: Wed, 22 Jul 2015 14:36:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EC4AA93-24C6-48F1-B3F1-B8F55B7FDD7D@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> <CAPi140N2qftrcqeBm7bq=21pdReR6YceBn-G4zPTiKOm92R8eA@mail.gmail.com> <55AF85F5.7070407@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/j7FRgOhhImntQFkFXfmpEXBRhyM>
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 12:36:57 -0000

> On 22 Jul 2015, at 14:00, Alexandru Petrescu <alexandru.petrescu@gmail.com>; wrote:
> 
> 
> 
> Le 22/07/2015 09:20, Andrew 👽  Yourtchenko a écrit :
>>> 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.
> 
> But mentioning 'mobile' for the nodes, makes think so.  Because fast address auto-configuration is a characteristic of mobile nodes.  One wants to spend as little time as possible waiting for RAs.  For that reason the multicast RAs period was reduced to milliseconds.

Yes. We made changes in the newly submitted -01 to make it clearer which networks it will apply to, hopefully it clarifies the scope enough.

--a

> 
>> Also, we wanted to be very focused what we talk about in this
>> document, to be able to ship it quicker.
> 
> I agree.
> 
>> 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".
> 
> I agree.  It should also say it does not apply to LTE.  BEcause in LTE an RA is sent on only one ptp link, there is no risk of waking up somebody
> 
>> Or something along these lines of that - feel free to propose the text
>> if the above is not what you had in mind.
> 
> On a scale MUST NOT, MAY, SHOULD - SHOULD is the right term.
> 
> "SHOULD [...] unless the network is of type LTE or 802.11p".
> 
> Or:
> 
> "SHOULD [...] unless there is an interest in as numerous RAs as possible to help in fast address auto-configuration to large number of mobiles".
> 
> or
> 
> "SHOULD [...] unless the Hosts are allowed to explicitely express interest in the multicast group dst of RA".
> 
> or
> 
> "SHOULD [...] unless RFC-MLD is updated to require Hosts to express interest in the multicast group dst of RA".
> 
> Alex
> 
>> 
>> --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
>