Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

Sander Steffann <sander@steffann.nl> Thu, 09 January 2014 21:48 UTC

Return-Path: <sander@steffann.nl>
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 C3C4D1A1F5E for <ipv6@ietfa.amsl.com>; Thu, 9 Jan 2014 13:48:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.194
X-Spam-Level:
X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 ybW4drp2H5_z for <ipv6@ietfa.amsl.com>; Thu, 9 Jan 2014 13:48:36 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 757E81A1F06 for <ipv6@ietf.org>; Thu, 9 Jan 2014 13:48:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 8D20353; Thu, 9 Jan 2014 22:48:25 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmJAXoWAC3D5; Thu, 9 Jan 2014 22:48:23 +0100 (CET)
Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id D723351; Thu, 9 Jan 2014 22:48:22 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04
From: Sander Steffann <sander@steffann.nl>
In-Reply-To: <CAKD1Yr04gCBJsKBoVNGbjS0MV__4px_aspVPkD1+mLGPpdpj4w@mail.gmail.com>
Date: Thu, 09 Jan 2014 22:48:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D19594A-F434-44C8-B02D-67B6FD401A9E@steffann.nl>
References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <CAKD1Yr1XPKibHenLMcNDRnfCht6X8tF2nMq1HgOiQv6eR9m6Yg@mail.gmail.com> <alpine.DEB.2.02.1401081305120.20074@uplift.swm.pp.se> <CAKD1Yr2AtF1CMqFxE1W63tXrS5OsbhJGfktN=sAaZtsBOSVg2Q@mail.gmail.com> <alpine.DEB.2.02.1401090707580.20074@uplift.swm.pp.se> <CAKD1Yr2yjPOWWHBx5dzwhNCT8fx9SEQg1wbPgGJSN3aS5bg5tg@mail.gmail.com> <alpine.DEB.2.02.1401090803040.20074@uplift.swm.pp.se> <CAKD1Yr25XJejF7sdHE2ycpcHNSyq=07+mKeLdj338=-LvsME-Q@mail.gmail.com> <alpine.DEB.2.02.1401090853090.20074@uplift.swm.pp.se> <CAKD1Yr03ZD3dDUpTWXUL_OiE_NYasUmpd9m1Ss6XoU0Qq_NCog@mail.gmail.com> <alpine.DEB.2.02.1401091342250.20074@uplift.swm.pp.se> <CAKD1Yr04gCBJsKBoVNGbjS0MV__4px_aspVPkD1+mLGPpdpj4w@mail.gmail.com>
To: Lorenzo Colittf <lorenzo@google.com>
X-Mailer: Apple Mail (2.1827)
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Andrew Yourtchenko <ayourtch@gmail.com>, 6man WG <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, 09 Jan 2014 21:48:38 -0000

Hi,

Op 9 jan. 2014, om 14:33 heeft Lorenzo Colitti <lorenzo@google.com> het volgende geschreven:

> On Thu, Jan 9, 2014 at 9:44 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> They would be rate-limited, just like any other ND packets on any implementation worth its salt. I think an NS is 72 bytes including ICMPv6 header; if so, then even if you send out 500 of them per second, that's 36 kB/s. What sort of link has a problem carrying 36 kB/s? How many NSes per second can routers send out anyway?
> 
> I don't know, people seem to indicate that there is a problem with multicast pps on wifi links. I haven't seen any hard data on this, it was just my interpretation that this was considered a problem.
> 
> Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485 , hoping that the draft authors will come along with more detailed data (which hopefully they have already presented to justify their use case and which I missed):
> 
> ===
> With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream.
> ===
> 
> Even 1Mbps is still a fair number of ND packets though.

I think the issue is that, while 1Mbps is enough for ND, it is lowering the speed for the whole channel. So in the time that the 72 byte packet is sent at 1Mbps there *could* have been 3888 bytes at 54Mbps. And I have no idea if the speed switch itself takes up any time.

I know that Andrew Yourtchenko has some real life experience with this stuff, so I'll put him in CC in case he has something to add.

Cheers,
Sander