[multimob] Some comments on draft-asaeda-multimob-igmp-mld-optimization-02

Liu Hui <liuhui47967@huawei.com> Tue, 23 March 2010 11:32 UTC

Return-Path: <liuhui47967@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 98B503A67A6 for <multimob@core3.amsl.com>; Tue, 23 Mar 2010 04:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.235
X-Spam-Level: ***
X-Spam-Status: No, score=3.235 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 6a1CJIwlqa3v for <multimob@core3.amsl.com>; Tue, 23 Mar 2010 04:32:29 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2F0F33A6359 for <multimob@ietf.org>; Tue, 23 Mar 2010 04:32:29 -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 <0KZQ009TMG2DPD@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 23 Mar 2010 19:32:37 +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 <0KZQ002H5G2DB3@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 23 Mar 2010 19:32:37 +0800 (CST)
Received: from l47967b ([10.111.12.118]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZQ00DVRG2CMU@szxml06-in.huawei.com> for multimob@ietf.org; Tue, 23 Mar 2010 19:32:36 +0800 (CST)
Date: Tue, 23 Mar 2010 19:32:36 +0800
From: Liu Hui <liuhui47967@huawei.com>
To: 'Hitoshi Asaeda' <asaeda@sfc.wide.ad.jp>, 'Stig Venaas' <stig@venaas.com>
Message-id: <00ce01caca7c$89c00a20$760c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="GB18030"
Content-transfer-encoding: quoted-printable
Thread-index: AcrKfIlg8QY3J1/OT42lSvkMCGQ65g==
Cc: 'multimob' <multimob@ietf.org>
Subject: [multimob] Some comments on draft-asaeda-multimob-igmp-mld-optimization-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: Tue, 23 Mar 2010 11:32:30 -0000

Dear Authors,

I have a review of your draft and have some comments on it.

1. The use of unicast query (sec 3.1).  It is suggested that unicast query is better than multicast query for battery saving purpose. But if unicast Query is used instead of multicast Query, when the number of the valid receiver is large, to track each member, numerous unicast Queries will be generated (instead only 1 Query in multicast case). This might not be an efficient use of the link resources.

2. Disable the explicit tracking (sec 3.3).  "When routers receive IGMPv3/MLDv2 Reports with duplicate source addresses or the all-zero or the unspecified address, they should disable the explicit tracking function (described in Section 3.1) even if it has been enabled." Does it mean disabling the ET only for these reports or disabling the function as a whole? From the description it seems that ET function is disabled as a whole, but personally I suppose the original meaning might be disable for these special reports because it's more reasonable. I suggested more specific description is given here.

3. Report with duplicate source addresses (sec 3.3):  How a router determines whether the reports of the duplicate address are from the different hosts or from the same host? As we know, the network might generate duplicate packets due to mis-transmission. If the reports are from the same host, it might be inappropriate to disable ET for it.

4. The processing of unspecified MLDv2 report (3.3 and 3.1): There are three places discussing unspecified MLDv2 report where inconsistencies might appear. E.g. "an MLDv2 Report sent with the unspecified address is also discarded by the router, because of the security consideration." (3.3)  requires the report to be discarded, while "when routers receive IGMPv3/MLDv2 Reports with duplicate source addresses or the all-zero or the unspecified address, they should disable the explicit tracking function (described in Section 3.1) even if it has been enabled" required it to be processed, and "It is impossible to identify mobile hosts when hosts have the unspecified address (::) or the same IPv6 link-local address in some mobile routing environment" (3.1 ) requires the Queries to be preserved for it.  Please make a check for them and make consistent description.  Besides, let router discard the unspecified MLDv2 report generally change the protocol behavior, I suggest caution should be taken when making this requirements (especially required by the word "must").

5. Tuning of timer interval and counter.  I suggest if the values are defined, they should be based on the field data. Currently there is no mobile and wireless multicast network running, it is difficult to make the estimation.  

And personally pure parameter adjustment (such as tuning only value of the timer or counter) should not be elevated as an independent work, because as we know, almost all the protocols (including 2236 and 3376 and etc.) have parameters such as timer and counter whose default value and scope are prescribed.  They are not processed as an independent memo.  And one most important reason is: tuning merely for parameters should not be a protocol tuning issue, but should be an engineering issue.  Normally the parameters are configured by the operator during running of their practical networks.

Finally, I suggest you to read a draft we just contributed to the group:

 http://www.ietf.org/id/draft-wu-multimob-igmp-mld-tuning-00.txt

I think it addresses the same issue and to meet the same requirements as your work, but with different approaches.  You are welcome to provide your comments on it,

Best Regards,
Liu Hui