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

From: Qin Wu <[email-masked]>
Date: Sat, 20 Mar 2010 23:54:08 -0700

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

---

From: Qin Wu <[email-masked]>
Date: Sun, 21 Mar 2010 08:01:23 -0700

Hi, Hotoshi:
Thank for you quick answer.
----- Original Message ----- 
From: "Hitoshi Asaeda" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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:
>> "
>> [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?
> 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?

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

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

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

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

---

From: Qin Wu <[email-masked]>
Date: Sun, 21 Mar 2010 12:21:08 -0700

Hi, Hitoshi:
Not sure your mail is dropped or delayed. :-)Please see my reply inline.
----- Original Message ----- 
From: "Hitoshi Asaeda" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 21, 2010 9:01 AM
Subject: Re: [multimob] Comments on draft-asaeda-multimob-igmp-mld-optimziation-02

> It seems my mail is dropped in this ML..
> 
>> [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 
> It is not bad describing link specific tuning.
> I can add some statements or specific values for specific link if
> it's beneficial.

[Qin]: I think it is beneficial and You can find the answer in our draft
 (temporialy published inhttp://www.weebly.com/uploads/3/9/9/4/3994264/draft-wu-multimob-igmp-mld-tuning-00.txt).

>> [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:
> 
> No I don't assume explcit tracking is performed by sending periodical
> Query. I said even with explicit tracking, query is needed.

[Qin]: But that is not what you say in your draft. What you said in the draft is explicit
tracking is performed by sending periodical Query. That's the problem. Whether or not
fixed, it all depends on you.

> See above.
>> when or in which network condition you are going to choose to
>> disable this explicit tracking if IGMPv3/MLDv2 is used?
> Read sect.3.1, especially from the paragraph from "On the other hand"
> in page.6.
> Again, if link specific condition relates to this function, I can
> coordinate it.

[Qin]: Yes, that is why I am really concerning about it. 
That is why I ask you clarify in which network condition you disable explicit tracking.
Unfortutely it is not clear in the your current draft.

>> Router need additional processing capability and a possible large
>> memory to keep track  of membership status; and therefore the
>> routers usually disable
>> 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..
> 
> Routers often disable explicit tracking. It is true. But in some
> condition or some senarios, it is useful. It is trade-off. I describe
> it.

[Qin]: True, it is better to point out this trade-off in your draft with additonal text.

>> 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.
> 
> It is not wireless specific. The explicit tracking cannot work
> properly when host uses unspecified address. That's all.

[Qin]: Okay. 
Since it is not wireless specific, why it is worth being specified in this WG?

>> [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.
> Again, no passive report in the standard.

[Qin]: The passive report is just the response to the router sent from the host when the host receives IGMP/MLD Query.
It is not new but existing message in the standard.

>> [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?
> 
> "acknowledge by sending the report with unspecified address"?
> Such additional flow or state does not solve anything, because in any
> case, query-responce is the basic function. 

[Qin]: Yes, that is the problem you have in your drafts. That is to say, even 
Query-Response is used in this case, the router still can not identify the host 
with unspecfied address.

>Again, explicit tracking
> does not eliminate "query-response".

[Qin]: That's my point. Thank for your clarifying this.

> I don't think so. Ask others.
> 
> Read above.
 
>> [Qin]: What I am saying here you seems to assume the explcit
>> tracking is one special case for IGMP/MLD Query.
> 
> No. Again, explicit tracking does not stop "query-response".
> 
>> [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 
> Tuning value may be different from link types, but query-report is
> basic function of IGMP/MLD in any link type.

[Qin]: I have no doubt for this. I would like to emphasize the function of IGMP/MLD  is same,
but behavior may a little bit different, that's why we need to specify how to tuning
IGMP/MLD behavior in the wireless enviroment. Denying for this, it does not worth
developing any work on this.

>> you specifies in your draft. In your draft, you also mentioned
>> several protocol changes you thought it was but it isn't,
> 
> I don't think so. Ok, let's follow...
> 
> Both are defined in rfc3376/3810.

[Qin]: Okay, but you change the protocol behavior like what I suggest to use Unicast Query with Multicast Query or use Group specific Query.

> Defined in rfc3810.

[Qin]: Since it has already been specified in rfc3810, why repeat to define such behavior again?

> I don't say "shutdown explicit tracking".

[Qin]: Okay, using disable instead. Also it is new operation.
 
> This is configurable.

[Qin]: It also means you should disable Explicit Tracking when using Multicast Query. It is new operation for the router.

> There is no such description.
> ASM is implemented with exclude (*,G) operation.
> 
>> [Qin]: Since it is not been verified, it seems they are just
>> personal experience, why this should be specifed here? 
> 
> There were comments in the last meeting that this consideration was
> very important.

[Qin] Important but lack verifying these results. Otherwise, it is just subjective experience.

>> [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.
> 
> It is very trivial. Read the archive of multimob ML.
> And maybe Thomas's PMIP multicast support draft mentions this?

[Qin]: Not convining for this results e.g., 1/4 of [Query Interval] or 1 second for [Starup] Qery Interval].
Also Thomas' PMIP multicast support draft didn't mention to use 1/4 of [Query Interval] or 1 second as [Starup] Qery Interval].
What am I missing?

---

From: Stig Venaas <[email-masked]>
Date: Wed, 24 Mar 2010 15:51:58 -0700

> Hi, Hitoshi:
[...]
> Also Thomas' PMIP multicast support draft didn't mention to use 1/4 of [Query Interval] or 1 second as [Starup] Qery Interval].

At least I think it is obvious that a short startup interval is
important for PMIP. For PMIP a new PtP interface comes up on the MAG
when a new MN arrives. As soon as the MLD Proxy is configured to do MLD
on that interface, you want it to quickly send general queries to as
quickly as possible to learn the new MNs memberships.

Stig

>> Regards,
>> --
>> Hitoshi Asaeda
>>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Mar 2010 18:33:08 -0700

Hi,
Thank for your reply.
----- Original Message ----- 
From: "Stig Venaas" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Hitoshi Asaeda" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 24, 2010 3:51 PM
Subject: Re: [multimob] Comments on draft-asaeda-multimob-igmp-mld-optimziation-02

> quickly as possible to learn the new MNs memberships.

[Qin]: Yes, I agree the shorter startup interval is a good choice, but not convincing 
how much shorter we can have.If  there are some implentation results or analysis
,that will be good.