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

[Qin Wu <[e-mail]>]

Hi, Hotoshi:
Thank for you quick answer.
----- Original Message ----- 
From: "Hitoshi Asaeda" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, March 21, 2010 12:52 AM
Subject: Re: [multimob] Comments on draft-asaeda-multimob-igmp-mld-optimziation-02


>> I take a quick look at
> 
> I think you should not take a "very quick" look. :)
> There are many misunderstandings in your questions and comments.
[Qin]: Sorry, I actually go through your draft very carefully. There do have some confusion not becos my comments which you need
to take a look at. Also I found mininal changes happen in your new version draft.
> Please read followings.
> 
>> 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.
> 
> IGMP/MLD are query and report type protocols.
> This condition is not changed in any link in their basic spec.

[Qin] In that why you specify them. Becos everything in wireless network is same as one in the wireline network.
Actually you miss the complicated conditions in the wireless enviroment including different link types, that's why 
we should choose different characteristics of IGMP/MLD to deal with different network conditions by tuning 
IGMP/MLD protocol behavior.

>> 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) 
> 
> Thank you, but I cannot find any right answer...

[Qin]: Because IGMP/MLD is 
mainly designed for ethernet network type. Specificiation for the other type of network like wireless network is missing. Therefore what I suggest here is before we go to deeper how to tune IGMP/MLD to adapt to wireless enviroment,
we should first analyze the existing IGMP/MLD protocol and Impact of wireless on IGMP/MLD. This
is what we are doing  in draft-wu-multimob-igmp-mld-tuning.
Unless you intend to ignore it, you will not miss them in our draft. :-) Anyway, Let's see what other people think as well.

>> 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?
> 
> I cannot understand your question, but expricit tracking is the
> standard function defined in rfc3376 and 3810.
[Qin]:I question is although RFC3376 and 3810 support explicit tracking, but they don't specify how explicit tracking works.
In other words, you assume explcit tracking is  performed by sending periodical Query. The original text in your draft is:
"
   The explicit tracking function reduces the number of solicited
   membership reports by periodical IGMP/MLD Query, and finally the
   total number of transmitted IGMP/MLD messages can be drastically
   reduced. 
"
So I am difficult to understnad where RFC3376 and RFC3810 specify this. What am I missing?

>> 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?
> 
> In Sect.3.1;
> "The explicit tracking function reduces the number of solicited
> membership reports by periodical IGMP/MLD Query, and finally the
> total number of transmitted IGMP/MLD messages can be drastically
> reduced."

[Qin]: you didn't answer my question metioned above. What I am asking is
when or in which network condition you are going to choose to disable this explicit tracking if IGMPv3/MLDv2 is used?
This is what you are missing in your part which I really want to know.

>> Or do you just mean when IGMPv3/MLDv2 query is used, then the
>> explict track should 
>> not be used. Is it true?
> 
> This draft does not say such thing. 

[Qin]: Okay.

>> Because in my understanding,IGMPv3/MLDv2 query can coexisit with
>> Explict tracking. What a I missing?
> 
> Your problem would be solved after you study rfc3376 and 3810, and
> read this draft.

[Qin] What I am really saying here your description 
"
"
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
"
"
cause people to misunderstand that when IMGPv3/MLDv2 is used, taking processing capability and memory into account, the router will often choose to disable explicit tracking..

>> 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?
> 
> No. It is the attention in the explicit tracking function.
> Sect.3.1 is describing "Tracking of Membership Status".

[Qin]: Not sure you are answering my question,:-).
I am still confused. I am wondering whether this case applies for wireline network like ethernet shared model or IPv6 fixed network?
If yes, not sure you should specify this here. Becos it will be a common issue not only to wireless enviroment and wireline enviroment.

>> [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?
> 
> No "passive report" exists in the standard.
[Qin]: yes, but I think you can not solve this issue by sending IGMP/MLD Query and asking mobile host to send passive report with unspecified address.
Therefore it seems both explicit tracking and IGMP/MLD Query can not solve this common issue.
> Anyway, this section says;
> "routers still need to maintain downstream
> membership status by sending IGMPv3/MLDv2 query messages due to the
> following reasons."
> Query to hosts using unspecified address is the corresponding case.

[Qin]: It seems the router can not identify the hosts with unspecified address, therefore the router should send Query to all the hosts including the host with specified address and the hosts with unspecified address. But if the host with unspecified address ackowledges by sending the report with unspecified address, it will result in that the router still can not identify the hosts with unspecified address, what am I missing?

>> 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?
> 
> For me, there is no difference; so I don't mind either.:)
> If the WG member agrees to change the section title, I'm happy to
> follow the decision.

[Qin]: Really, but it really matter which may cause confusion when reading this section.:-)

>> Also still not sure Explict tracking should depends on periodical
>> query to keep track of membership status?
> 
> What "should depends" means?

[Qin]: See above. I am very doubt the explicit tracking is performed by sending periodical query.

>> 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.
> 
> I cannot understand this comment, too...

[Qin]: What I am saying here you seems to assume the explcit tracking is one special case for IGMP/MLD Query.

>> 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.
> 
> I don't say any "must" in this section.
> So, there is no mandatory thing here.
> This section only show the possible scenario that the corresponding
> timer can be shorter in the described condition.

[Qin] But the problem is you restructure this draft into Query processing section and Report processing section,
it truelly indicates you want to mandate the contents in these section. Unfortuntely there are different optimization approaches 
according to different netrwork conditions.

>> 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?
> 
> Group specific query is not used for such purpose. Please read
> rfc3376/3810.
> Yes, mixing unicast and multicast queries in some condition may be
> good. I've been thinking such condition, but this optimization may
> require protocol change. So, it would be discussed in my extension
> draft, not this draft.

[Qin]: I disagree with you  on these. All these optimizations approaches are not protocol changes
but behavior tuning or parameter tuning. Also it seems what you said contradicts with what
you specifies in your draft. In your draft, you also mentioned several protocol changes you thought it was but it isn't,
e.g., use unicast Query with longer Query interval plus Explicit Tracking
e.g., Discard MLD report with unspecified address
e.g., Shutdown Explicit tracking when the router receives the reports with duplicated address.
e.g., Multicast Query with shorter Query interval without Explicit Tracking.

>> 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?
> 
> Again this draft does not mandate to prohibit exclude operations.
> This draft only explains the condition. Excluding the exclude mode
> operation is implementors'/operators' decision.

[Qin]: Okay, but another problem is you seems to eliminate using ASM mode 
when using IGMPv3/MLDv2 in the wireless environment? Actually it is not necessary.
Maybe in the other network conditions, the ASM mode can be used to optimize operation.

>> 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?
> 
> These values would be possiblly studied by simulation or mathematical
> study in near future.

[Qin]: Since it is not been verified, it seems they are just personal experience, why this should be specifed here?

>> 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?
> 
> To support smooth handover for new;y coming-up link, such as PMIPv6's
> MAG-MN's link.

[Qin]: You seems to misunderstand what I am asking, what I am meaning is you need to justify this by some experiment data, 
maybe from papers.

> Regards,
> --
> Hitoshi Asaeda
>