Re: [multimob] Revised MLD/IGMP Tuning drafts

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Tue, 02 November 2010 09:42 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 C7ED03A68CF for <multimob@core3.amsl.com>; Tue, 2 Nov 2010 02:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.096
X-Spam-Level:
X-Spam-Status: No, score=-99.096 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, USER_IN_WHITELIST=-100]
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 dMQGDqfAHnyE for <multimob@core3.amsl.com>; Tue, 2 Nov 2010 02:42:02 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 206A23A6949 for <multimob@ietf.org>; Tue, 2 Nov 2010 02:41:50 -0700 (PDT)
Received: from localhost (wifi-139-222.sfc.wide.ad.jp [203.178.139.222]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E42D3278086; Tue, 2 Nov 2010 18:41:46 +0900 (JST)
Date: Tue, 02 Nov 2010 18:41:46 +0900
Message-Id: <20101102.184146.26972078.asaeda@sfc.wide.ad.jp>
To: Dirk.von-Hugo@telekom.de
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <643B0A1D1A13AB498304E0BBC802784802BB3DBA@S4DE8PSAAQC.mitte.t-com.de>
References: <326815.19541.qm@web111404.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC802784802BB3DBA@S4DE8PSAAQC.mitte.t-com.de>
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] Revised MLD/IGMP Tuning drafts
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: Tue, 02 Nov 2010 09:42:04 -0000

Hi Dirk,

> Qin and Hui give a detailed introduction in wireless and mobile
> multicast isues which could be shortened a bit (BTW also fixed
> access bandwidth e.g. DSL in general is asymmetric - however for
> wireless it could also be a hybrid connection with e.g. broadcast
> e.g. DVB downlink and individual unicast e.g. WLAN uplink). 
> I am not sure whether we need a comparison in detail between
> MLD/IGMP versions as only IGMPv3/MLDv2 is mentioned in the charter.

The draft aims to propose IGMP/MLD optimization by tuning timers or
other values.
Therefore, IMO, it is better that such detail description would be
included in other draft, e.g., the requirement draft, not in the
optimization draft, if needed.

> Both drafts propose to use Explicit Tracking which can considerably
> reduce message traffic and speed up leave latency thus saving
> resources on both network and terminal side.

The spec of the explicit tracking function has been proposed in the
following draft;
http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-01

> Whereas Hitoshi and Yogo propose specific figures for Timers and
> Counters (unfortunately without a reference to measurements
> verifying the optimization gain),

Right. Since I think describing the simulation scenarios may be out of
scope of the I-D, I've not included in the I-D.
I hope I could refer our paper in the revised draft.

> Qin and Hui propose an adaptive
> Timer increase which seems to be more elegant - but doesn't this
> require a protocol change?
> 'Switching between Unicast and Multicast Queries' is implicitly also
> proposed by Hitoshi and Yogo ...

Unicast general query is allowed in RFC3376 and 3810, and hence we had
proposed the use of unicast query for mobility since -00 version of
our optimization draft published on July 2009.
http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-optimization-00

However, I believe changing the destination address of general query
and changind the query interval "according to the network or node
condition" require protocol change. They are beyond the standard spec.

Since IMO it is a protocol change, the discussion about unicast vs.
multicast general query with different query intervals has been
discussed in the following "protocol extension" draft.
http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-mobility-extensions-04
It is not in the current charter, but if you are interested in, please
take a look at it.

> My overall suggestion is that merging both documents could provide a
> complete solution to be adopted by the WG.

At this moment I'm sorry but I cannot find any reason to merge the
draft.

Regards,
--
Hitoshi Asaeda