Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

Erik Nordmark <nordmark@sonic.net> Thu, 23 April 2015 21:55 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DA41A6F13 for <ipv6@ietfa.amsl.com>; Thu, 23 Apr 2015 14:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.31
X-Spam-Level:
X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 7PV9fOgPIN1k for <ipv6@ietfa.amsl.com>; Thu, 23 Apr 2015 14:55:28 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A348A1A8833 for <ipv6@ietf.org>; Thu, 23 Apr 2015 14:55:09 -0700 (PDT)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t3NLt4Yv014090 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Apr 2015 14:55:04 -0700
Message-ID: <55396A38.1050107@sonic.net>
Date: Thu, 23 Apr 2015 14:55:04 -0700
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: 神明達哉 <jinmei@wide.ad.jp>, Erik Nordmark <nordmark@acm.org>
Subject: Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01
References: <16407124-2B19-4B8F-AEAC-F04D3C7E5C3A@gmail.com> <CAKD1Yr1c80-04CgQKCdGCZPeRgT_M_oeRzzZUnSCVKsaS9kqug@mail.gmail.com> <CAJE_bqfdw_wQRNYept1h8s8a_gj2NOYcqWsGpsFztZbr-B_UEg@mail.gmail.com> <55368786.5000507@acm.org> <CAJE_bqciFNkukedq6pFYUHVvdh02GEYWEA0Wdb3dFcySz_K4NQ@mail.gmail.com>
In-Reply-To: <CAJE_bqciFNkukedq6pFYUHVvdh02GEYWEA0Wdb3dFcySz_K4NQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sonic-CAuth: UmFuZG9tSVbEaPP9FR26zX6LWwJP3ltBibG6sM1uT0czoTOKYItYCu7JJVCZ9xaQd8FHdDJHEZ0VVMUiXJfJw9yOWZPA32rW
X-Sonic-ID: C;6uo2ZgPq5BGMHOVSju/ZCg== M;lPlBZgPq5BGMHOVSju/ZCg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/S2lqG5ADTgrjIsdyTTYtpymMAhI>
X-Mailman-Approved-At: Thu, 23 Apr 2015 15:18:21 -0700
Cc: IPv6 List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2015 21:55:30 -0000

On 4/23/15 11:32 AM, 神明達哉 wrote:
> At Tue, 21 Apr 2015 10:23:18 -0700,
> Erik Nordmark <nordmark@acm.org> wrote:
>
>>> I was not sure if we had agreed on sufficient need for making
>>> non-trivial (if not substantial) changes to a core part of the
>>> protocol.  If what Lorenzo was trying to say is a different form of
>>> what I tried to ask, I tend to agree with part of his argument.
>>> Although I'm not necessarily opposed to adopting the document just
>>> because of that, I think it's reasonable to request clarifying the
>>> problem statement and expected goal.
>> Please send text on what you would want to see as (part of) PS and goals.
> It was very vague and abstract level of thought when I wrote this, so
> I wouldn't have been able to propose any specific text.  But I guess
> Lorenzo seemed to answer the request pretty well in his later message:
> http://www.ietf.org/mail-archive/web/ipv6/current/msg22477.html

Jinmei,

That email doesn't have any useful text which can be included in the 
document as a problem statement. To quote:
"1. Mobile network paging channel excessive usage. I think the numbers 
in that argument were dubious, because in any mobile network today the 
vast majority of devices is sending packets *way* more often than one 
every half an hour. But even supposing they weren't, that problem can be 
fixed by increasing the maximum RA interval and/or piggybacking RAs onto 
unicast traffic, and/or sending an RA to the node opportunistically 
right after the node sends a packet and thus has the channel grant.

2. Excessive multicast use on wifi. Most of this problem problem can be 
solved by sending solicited RAs unicast. RA isn't really a high-order 
contributor to this problem anyway - bonjour is much worse, and so is ARP.

3. Low-battery nodes. Here you can construct an argument that justifies 
anything: all you need to do is posit the existence of a node whose 
constraints make it a poor fit for the periodic RA model, and then 
decide to optimize for that node. For example, you can posit a node that 
is super-constrained, whose battery has to last years of sending one 
packet per day, but cannot disconnect because it needs to receive 
unicast packets on someone else's schedule instead of the natural option 
for a constrained device of *disconnecting* and only polling 
periodically. Even here, though - why are these devices not using 
special link layers? For example, 802.11 in particular is terrible at 
power consumption for this sort of device. It's a high-speed technology 
intended to provide XXX megabit speeds, not optimizing low power. Why 
are we trying to use it?"


That is mostly Lorenzo's personal views about different potential 
problems, and isn't something I can cut and paste into the document as a 
PS, which is really what "send text" means.


Note that the document already has a goals section. If you disagree with 
it, then please suggest edits, additions, removals.

Thanks,
    Erik

>
> --
> JINMEI, Tatuya
>