Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 25 February 2010 08:04 UTC

Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAE228C0DF for <multimob@core3.amsl.com>; Thu, 25 Feb 2010 00:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.025
X-Spam-Level:
X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a34BXlvrst2d for <multimob@core3.amsl.com>; Thu, 25 Feb 2010 00:04:22 -0800 (PST)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 2129328C276 for <multimob@ietf.org>; Thu, 25 Feb 2010 00:04:20 -0800 (PST)
Envelope-to: multimob@ietf.org
Received: from e178129113.adsl.alicedsl.de ([85.178.129.113] helo=[192.168.178.25]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1NkYjt-000Lqy-1R; Thu, 25 Feb 2010 09:06:29 +0100
Message-ID: <4B862F81.3020804@informatik.haw-hamburg.de>
Date: Thu, 25 Feb 2010 09:06:25 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Greg Daley <gdaley@netstarnetworks.com>
References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es> <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> <4B859FBA.6030300@fhtw-berlin.de> <E12CAEE9B45DF740BB60A487FC3B37C6011287C2D4C4@SDCEXCH.netstarnetworks.com>
In-Reply-To: <E12CAEE9B45DF740BB60A487FC3B37C6011287C2D4C4@SDCEXCH.netstarnetworks.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
Cc: "multimob@ietf.org" <multimob@ietf.org>
Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2010 08:04:23 -0000

Hi Greg,

good to hear from you!

The issue you are raising is under debate in "the other" core objective 
of Multimob, the MLD tuning. Actually, Hitoshi Asaeda has proposed to 
use MLD by unicast in his presentation at the last IETF (Hiroshima), I 
believe for the exact same arguments you follow.

In the basic PMIPv6 context, this is not so much an issue, as RFC5213 
restricts downstream links to be point-to-point. In case of 802.11 
wireless access, this would lead to unicast tunnels anyway (possibly GRE 
- see http://tools.ietf.org/html/draft-ietf-netlmm-grekey-option-09).

So in brief: we agree, but the issue seems more related to the MLD 
tuning in wireless domains rather than to PMIP at its current spec.

Cheers,

Thomas

Greg Daley wrote:
> 
> Hi Thomas and Luis, 
> 
>> Hi Luis,
>>
>> thanks again for your critical comments: this is highly appreciated!
>>
>> Please see my answers inline:
>>
>> Luis M. Contreras wrote:
> ...
>>> 3. Following IPv6 address configuration, the MAG SHOULD send an
>>> (early) MLD General Query to the new downstream link as part of
>>> its standard multicast-enabled router operations.
> 
> Forgive me for my long hiatus, and perhaps the scope of the PMIPv6
> system precludes this being an issue.
> 
> Does anyone have an idea of the impact that a downstream multicast
> General Query would have on an 802.11 Network each time a device
> arrives on the cell?
> 
> The message transmitted unacknowledged on one of the rates in the
> BasicRatesSet.  BasicRatesSet defines the common rates all devices
> accessible by an AP must support.
> 
> Past behaviour on Wireless LAN defaults this to be low throughput
> rates, and on  2.4GHz systems, this has typically been either 1Mbps,
> or 2Mbps (or 3Mbps for 5GHz).  This takes potentially 54 times as
> long for transmission of the data component than a comparable packet
> delivered over MAC unicast.
> 
> With General Queries, there is no Robustness value (transmissions
> occur once), so there's a possibility that a downstream multicast 
> could also be lost, and no report received from the Listener.
> 
> Given that there is a MAG which is keeping track of unicast addressing
> and configuration, would it not be appropriate to direct the General Query
> to a unicast address of the arriving device in compliance with S5.1.15 of
> RFC3810?
> 
> This would allow unicast packet delivery at Link-Layer, which incorporates
> higher data rates, and MAC retransmission.
> 
> This may also be useful for other media.
> 
> (You could readily determine if it is better to send a Multicast or 
> multiple unicasts based on the outstanding number of devices which are
> Unicast configured, but not MLD Reporters).  The unicast/multicast
> ratio could be configured on a per-interface basis.
> 
> 
> Sincerely,
> 
> Greg Daley

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °