Subject: [Mobopts] Re:simulation of draft-zhang-mipshop-multicast-dma-00.txt

From: "[email-masked]" <[email-masked]>
Date: Wed, 22 Jun 2005 09:49:45 +0800

Dear Thomas,

Thanks for your detailed concerns. I'm Bing-Yi Zhang, one of authors.
See our reply below inline.

> > * If - after a handover - the local Multicast router (MSA) is not
> > already part of the delivery tree, you advise the procedure:
> > " ... the MSA communicates with the previous DMA of
> > MN. If the previous DMA selects a new DMA, the MSA of current
> > subnet works as new DMA, and it creates and maintains an entry
> > for this MN in the MSA list of this MSA."
> > That means the MSA has to subscribe to Multicast group(s) of MN
> > subsequent to negotiations with DMA, i.e. a remote subscription, which
> > is retarded by some prior protocol overhead. So, as the overall result,
> > one would expect a handover performance slower than the immediate remote
> > subscription.
> > Re: Only if the MN's DMA need be switched to the current local MSA, the 
current MSA has to do a multicast group subscription. However, the DMA switch 
is not so often within an acceptable roaming distance. We believe that the 
frequent "immediate MSA multicast remote subscription" is unbearable and much 
slower. Our approach reduces the frequent remote subscription and multicast 
tree restructuring by introducing the concept of DMA. 
> > 
> [...]
> > Re: Thanks for your reference. But we believe our approach is quite 
different from these two draft as you mentioned. First, in our draft the DMA 
is dynamic and different MN in the same subnet may select different DMA. So the 
load of one DMA can be lightened and not a performance bottleneck. Second, our 
approach can avoid the long multicast tunnels frequently between Multicast 
Agent and MN, and also reduce a lot of multicast tunnels between Multicast 
Agent and MNs.
> > 
> How is the decision-making process between MNs, MSAs and DMAs on
> handover and load balancing supposed to proceed?
> 

[Zhang] Re: The decision-making process between MNs, MSAs aand DMAs on handover 
is not complicated. 
On arriving at a new subnet, MN will do regular MLD reports to its current 
local MSA and tell it the previous MSA address as well. (1) If the current MSA 
has joined in the required multicast tree, then the current MSA will switch at 
once as the MN's new DMA and notify the MN's previous DMA to clear the status 
and history recording. (2) If the current MSA is not in the required multicast 
tree, the current MSA will communicate with the MN's previous DMA to decide 
whether needs to do DMA switching. The decision-making algorithm on the 
previous DMA could be simple or precise. A simplest example is that, if the 
maximum of the roaming subnet numbers maintained by the DMA is reached, then do 
DMA switching; otherwise still be the current DMA. 

> The question on 'how frequent a MN leaves acceptable roaming distances'
> depends on MN's mobility within network topology. Also it is our believe
> that setting up a local/regional tunnel tends to be much faster than a
> multicast remote subscription. Do you have any additonal data
> (simulations, measurements, ...), which quantify your premises?
> 

[Zhang] Re: Glad to know you have the same view on the multicast remote 
subscription. We did some simulations before submitting the draft. See the 
attached doc. Now if our approach attracts enough attention within IETF, we'd 
like to to do more simulations and measurements. 

> > Thanks again. We hope to have a chance to discuss with all IETF experts 
interested in MIP6 multicast. This is a very significant topic for NGI.
> 
> Yes, maybe we can have discussions this more detailed in Paris!
> 

[Zhang] Re: Thank you for your invitation. We'd like to do that. We hope the 
Chairmen of [MOPOPTS] or [MIPSHOP] can arrange some time to let us do 
presentation at the Paris 63#IETF meeting.

Best Regards,
Bing-Yi Zhang & Hong-Ke Zhang

　　　　　　　　张冰怡
　　　　　　　　

　　　　　　　　HKzhang
　　　　　　　　[email-masked]
　　　　　　　　　　2005-06-22
_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 22 Jun 2005 09:37:07 +0800

Dear Thomas,

Best Regards,

　　　　　　
　　　　　　　　HKzhang