[multimob] Comments on draft-asaeda-multimob-igmp-mld-optimziation-02

Qin Wu <sunseawq@huawei.com> Sun, 21 March 2010 06:54 UTC

Return-Path: <sunseawq@huawei.com>
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 108013A690B for <multimob@core3.amsl.com>; Sat, 20 Mar 2010 23:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.732
X-Spam-Level: *
X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6]
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 WbWYnEIuVGpj for <multimob@core3.amsl.com>; Sat, 20 Mar 2010 23:54:02 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1420F3A692E for <multimob@ietf.org>; Sat, 20 Mar 2010 23:54:00 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZM00MDWDU9PH@szxga03-in.huawei.com> for multimob@ietf.org; Sun, 21 Mar 2010 14:54:09 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZM00D2GDU98H@szxga03-in.huawei.com> for multimob@ietf.org; Sun, 21 Mar 2010 14:54:09 +0800 (CST)
Received: from jys8033415 ([130.129.24.179]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZM00CU6DU4V6@szxml01-in.huawei.com> for multimob@ietf.org; Sun, 21 Mar 2010 14:54:09 +0800 (CST)
Date: Sat, 20 Mar 2010 23:54:08 -0700
From: Qin Wu <sunseawq@huawei.com>
To: multimob@ietf.org
Message-id: <05af01cac8c3$4f781c50$61b6a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: multipart/alternative; boundary="Boundary_(ID_sIGNfbqKR7pkhdakO4GoKA)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [multimob] Comments on draft-asaeda-multimob-igmp-mld-optimziation-02
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: Sun, 21 Mar 2010 06:54:04 -0000

Hi, all:
I take a quick look at draft-asaeda-multimob-igmp-mld-optimization-02 and am not sure  the Report processing and Query processing in the wireless enviroment can be mandatory. Becos there are lots of ways to do tuning and optimization when using IGMP and MLD in the wireless environment. All these ways or approaches should be chosen according to different network condition, network planning, network type. None of them should be mandatory unless they are really  implemented and tested. Besides this, what is missing in this draft seems to be evaluation of existing IGMP/MLD protocol and demonstration what is the impact of wireless on IGMP/MLD. As regarding these missing part, you can find the right answers in the draft-wu-multimob-igmp-mld-tuning (which is temporarily published in http://www.weebly.com/uploads/3/9/9/4/3994264/draft-wu-multimob-igmp-mld-tuning-00.txt)  
Also I would like to make some comments as follows, for there are still some part of draft-asaeda-multimob-igmp-mld-optimization-02 I don't understand.
------------------------------------------------------------------------------------------------------------------------------------------
In the section 3.1 of draft-asaeda-multimob-igmp-mld-optimization-02., it mentioned:
"
The explicit tracking function reduces the number of solicited membership reports by periodical IGMP/MLD Query......
"
[Qin]: I am wondering whether explicit tracking function relies on IGMP/MLD periodical Query to reduce the number of solicited report?
Only IGMPv3 described in RFC3376 and MLDv2 described in RFC3810 briefly mentioned explicit membership tracking, there are no details on how explicit tracking really works and how this feature is implemented?
So I am wondering whether your approach for explicit tracking is the only choice or implementation specific?
Also in the section 3.1,  it mentioned:
"
Router need additional processing capability and a possible large memory to keep track  of membership status; and therefore the routers usually disable
the function for keeping track of membership status
"
[Qin]: Are you saying Explicit tracking function is the function for keeping track of membership status. If yes, then it is not clear when you are going to choose to disable  this explict tracking function if IGMPv3/MLDv2 query is used? Or do you just mean when IGMPv3/MLDv2 query is used, then the explict track should 
not be used. Is it true? Because in my understanding,IGMPv3/MLDv2 query can coexisit with Explict tracking. What a I missing?

Also in the section 3.1, it mentioned:
"
It is impossible to identify mobile hosts when host have the unspecified address(::) or the same IPv6 link local address in some mobile routing environment.
"
[Qin]: Not sure this issue is specific to wireless or mobile enviroment. Is there any such issue in the wireline network like ethernet shared model?
[Qin]: Not sure how to solve this issue by using IGMP/MLD Query instead of Explicit Tracking? What if the mobile host send passive report with unspecified address as well in response to IGMP/MLD Query?

Still in the section 3.1:
[Qin] The title of this section is "Tracking of memembership status", why use "Tracking of membership status"for the title instead of "Explcit tracking"? Are you saying there are other way for tracking of membership status besides Explicit tracking?
Also still not sure Explict tracking should depends on periodical query to keep track of membership status?
Suppose you are right that Explict tracking relies on periodical query, then why not merge the section 3.1 and 3.2. Becos also Query is talked about in the section 3.2.

In the section 3.2, it mentioned:
"
If a multicast router attached to a wireless link enables an explicit tracking function and unicat IGMP/MLD General Query for each member host, the router may configiure longer [Query Interval] Value, in order to reduce the number of IGMP/MLD General Query messages via multicast. If a multicast does not track the member hosts, the router multicasts IGMP/MLD General Query with shorter [Query Interval].
"
[Qin]: So your conclusion is if unicast Query plus explicit tracking is used, the [Query Interval] value must be set longer, if multicast Query without explicit tracking is used, then the [Query Interval]Value must be set shorter.
So I am wondering how do you get this conclusion? What's your justification to tune [Query Interval] value longer or shorter?
Even you can make such conclusion, I don't believe this tuning method should be mandatory when we use IGMP/MLD in the wireless enviroment.

In the section 3.3, it mentioned:
"
In summary, routers permit that multiple mobile hosts simutaneously use the same IPv4 address, including the 0.0.0.0 souce address, for an IGMPv3 report, or simutanesouly use the same IPv6 link-local routers receive IGMPv3/MLDv2 Reports with duplicate source addresses or all zero or the unspecified address, they should disable the explicit tracking fuction.
"
[Qin]: Not sure the only choice is to disable Explicit tracking, e.g., If only a few mobiles hosts use the duplicated source address or all zeros or the unspecified address, the router can choose to send Group specific query or unicast query to collect the remaining membership status of these mobile hosts. What am I missing? 
So it is not convincible to get such conclusion described in the section 3.2?

In the section 3.4
[Qin]: I agree IGMPv3/MLDv2 with Exclude filter mode support increases the tree maintenance cos to the multicast router on the routing path. But it does not
become a reason to exclude using IGMPv3/MLDv2 with Exlclude filter mode in the wireless enviroment?  So I think IGMPv3/MLDv2 and lightweight IGMPv3/MLDv2 are both best candidate protocol for tuning optimization in wireless envrionment, What am I missing?

In the section 3.5:
[Qin]: Not sure talking about Timer, Counter and their default values  is worth a whole section. Becos lots of facts comes from existing IGMP/MLD protocols.
Also lots of values for the interval lack justification. E.g.,
in the section 3.5, it mentions
"
While the default [Robust variable]value defined in IGMPv3 and MLDv2 is "2", the [Robust Variable] Value annouced by Queirer should not be "0" and should not be "1". This document proposes that [Robust variable]Value should not be bigger than 2
"
[Qin]: Is it too implimentation specific? What's the justification for this?
Also it mentioned:
"
The [Sartup Query Interval] should be 1/4 of [Query  Interval]. this document recommend the use of the shortened value such as 1 second.
"
[Qin]: Why?

 Regards!
-Qin