Subject: [Mobopts] Re: [multimob] Bar BOF in Chicago

From: Thomas C Schmidt <[email-masked]>
Date: Tue, 24 Jul 2007 17:31:32 +0200

Hi Wu,

many thanks for your feedback - please see comments inline

------------- snip ------------------------
For the problems which mobile multicast faces

• I think the main problems can be divided into
2 categories, and then we can explain the
problems of multicast caused by mobility
clearer:
– For the User side, 2 main problems:
• Multicast packet loss percentage mainly caused by
handoff)
• packer transmit delay (related Average to the path
length of multicast packet, triangular routing would
make parameter this worse)

------------- snap ------------------------

TS => Yes, agree. Additional disturbances arrive from jitter, as 
discussed in the introduction of the draft.

Another key issue: the address duality problem.

The idea of the PS-draft is - from a fairly general level of abstraction 
- to look behind the scene, i.e., to identify issues and causes in more 
detail.

The reason for this: The PS-draft is meant to serve as comprehensive 
overview and analytical fundament for future designers of mobile 
multicast protocols.

------------- snip ------------------------

For the problems which mobile multicast faces (con.)

– For the Network side, 3 main problems:
• Multicast packet efficiency (use delivery related to the of tunnel)
• Multicast maintenance overhead (related to the design of mobile 
multicast scheme)
• The stability of multicast tree (related the way of updating multicast 
tree after a handoff event)

------------- snap ------------------------

TS => D'accord. Please don't forget convergence speed and robustness of 
the mobile multicast routing schemes.

Fairly central issues derive from deployment: We should closely look at 
  solutions which have a realistic chance for deployment, e.g., by 
staying close to unicast mobility management schemes.

------------- snip ------------------------

For the solutions
• Users always move around within a definite scope, such as within a 
building when they are working
• Hierarchical structure is useful in mobile multicast
– Can shield the local movement from outside
– Can efficiently reduce the change of the main
multicast delivery tree
– Can decrease the multicast protocol overhead related handoff
– It is an important category of mobile multicast
solution and I suggest it be written in solution, the draft

------------- snap ------------------------

TS => Yes, you're right. Actually this approach is taken in draft 
http://www3.tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6 , which 
is mentioned in the solutions section.

Of course, the brief survey over the solution space mainly consists in 
reference pointers ... to keep the document within readable bounds :-)

Best regards & hope to see you in Vancouver

thomas

Wu Qian wrote:
> Hi Behcet, 
> 
> I'm interested in this BOF and write some comments on the 
> draft-irtf-mobopts-mmcastv6-ps-01.txt.
> 
> But I can't go to Chicago this time, and the second author 
> Dr. Deng Hui will attend the bar bof of multimob.
> 
> Best Regards,
> Wu Qian
> CERNET & Network Research Center of Tsinghua University
> Tel: +86-10-62603327, +86-13911189166			 
> [email-masked]
> 2007-07-24
> 
> ----------Original Message----------
> From: Behcet Sarikaya
> Date: 2007-07-14 03:24:33
> To: [email-masked]
> CC: [email-masked]; Jari Arkko
> Subject: [multimob] Bar BOF in Chicago
> 
>> Folks,
>>  At the moment we have a plan to organize a Bar BOF during IETF-69 to be possibly sponsored by us.
>>  To help us organize this event better, it would be nice if you send me and Suresh a note on your possible attendance. 
>>  Also, the meeting will be totally devoted to technical discussions and not to process discussions. If you can make a technical presentation on the problem and/or solution efforts, again, send me and Suresh a note.
>>  See you in Chicago.
>>
>> Behcet
>>
>>
>>
>> _______________________________________________
>> multimob mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/multimob
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/multimob

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

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 25 Jul 2007 09:59:03 -0500

Hi, thomas,

Thanks for your paste and reply,
See below inline.

> overview and analytical fundament for future designers of mobile
The problem statement which you wrote is good, and here what we would like
to suggest is that in the current stage, we may skip source mobility
since the needs are not strong and quite complicated. So if possible,
we may could define
more category like user and network side consideration.

> the mobile multicast routing schemes.
Good suggestion, we cold clarify more in detail related to this

> staying close to unicast mobility management schemes.
This need more discussion on it.

> is mentioned in the solutions section.
we are suggesting more hierachical solution other hmip solution since we
have to consider more deployment realistic.

> reference pointers ... to keep the document within readable bounds :-)
Sure,

btw, more suggestion, shall we consider as well pmip area?

Thanks

-Hui

---

From: Thomas C Schmidt <[email-masked]>
Date: Wed, 25 Jul 2007 17:29:15 +0200

Hi Hui Deng,

thanks for your opinions - please see comments inline

> more category like user and network side consideration.

Thanks, but disagree: source mobility is a quite important part of the 
problem ... and, as I'll try to convince in today's talk, interactive 
multicast applications are important, as well.

Additionally: I don't see a point in adding these categories to the 
problem space. The control signalling interplay, of course, is alway 
between endnodes and routers or in between routers. But this is not 
unique to multicast ... ;)

There are network-related issues with respect to deployment, though.
> btw, more suggestion, shall we consider as well pmip area?

Yes, we can check for and take this up, thanks.

Best regards,

thomas