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

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Thu, 25 February 2010 08:54 UTC

Return-Path: <asaeda@sfc.wide.ad.jp>
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 2C28228C0D7 for <multimob@core3.amsl.com>; Thu, 25 Feb 2010 00:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.904
X-Spam-Level:
X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
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 eQsMCDzs5Tlg for <multimob@core3.amsl.com>; Thu, 25 Feb 2010 00:54:45 -0800 (PST)
Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 55FAC3A8666 for <multimob@ietf.org>; Thu, 25 Feb 2010 00:54:45 -0800 (PST)
Received: from localhost (dhcp-143-189.sfc.wide.ad.jp [203.178.143.189]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id D65B913D06CA; Thu, 25 Feb 2010 17:56:53 +0900 (JST)
Date: Thu, 25 Feb 2010 17:56:53 +0900
Message-Id: <20100225.175653.108627834.asaeda@sfc.wide.ad.jp>
To: gdaley@netstarnetworks.com
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <E12CAEE9B45DF740BB60A487FC3B37C6011287C2D4C4@SDCEXCH.netstarnetworks.com>
References: <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> <4B859FBA.6030300@fhtw-berlin.de> <E12CAEE9B45DF740BB60A487FC3B37C6011287C2D4C4@SDCEXCH.netstarnetworks.com>
X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: 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:54:46 -0000

Hi Greg,

> 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?

I think your question is related to my IGMP/MLD optimization draft.
Please take a look at;
http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-optimization-01

> 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.

As you said it is difficult for coordinating the timing of general
query because each wireless link MAC has its different signaling
mechanism.
Unicast query discussed in the above draft is not perfect for every
condition.

Our draft aims to clarify the issues for mobile multicast and
describe the considerable way of tuning protocol timers and behavior.

I've been revising the draft. (I hope I finish it before this cut-off
date)
If you have comments, please tell me. Your input would be valuable.

Regards,
--
Hitoshi Asaeda