Subject: [multimob] Summary from multimob session @ IETF71

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Mar 2008 19:18:41 -0400

Hi Folks,
   Here is the summary from the multimob session we had at IETF71. I was 
too involved in the discussions to take very good notes but I think the 
essence of the discussions is covered.

Cheers
Suresh
Behcet presented his overview slides about draft-sarikaya-multimob-ps

Marshall Eubanks mentioned that light weight MLD may or may not be standardized or implemented. We should not base multimob work on the assumption that it will be there

Dave Thaler mentions his presentation about source mobility in multcast 

Frank Xia about draft-xia-multimob-hybrid-00

Dave points out you can already subscribe to a multicast stream without using MIPv6 and the application on the MN will choose.

Dave wants to know who makes the choice about taking the direct or the home tunneled path. The stack on the MN or the Application?

Frank mentions that when the application joins the multicast group on the home interface the stack can switch to the local interface.

Bharat wants to know how the MN knows that the multicast service is available locally

Bill Atwood talks about charging on the AR (for local streams) being different from that on the home network. He thinks that the decision for this should be in the hands of the end user

Dave agrees and  wants to have the costs predictable.

Dave wants to define optimality (what we are trying to optimize)

Bill has issues with picking paths without user involvement 

Christophe Janneteau wants the user involved but not necessarily the application

Frank Xia about FMIP multicast draft

Dave wants to quantify the advantages, since the propogation from the NAR to the common point might be pretty close.

He also wants to know about the tunnel management interference between unicast and multicast tunnels.

Thomas presented his slides about Proxy architectures for mobile multicast receivers (no draft)

Dave wants to see a topology

Frank asks about whether the PAR or NAR must be the proxy agent in case of FMIP

Suresh mentions define "what"(the functionality) but not "where"(physical node)

Dave wants a definition of proxy agent

Bill wants to stress that the functionality is colocated but not inside.

Dave thinks that the proxy definition still not clear.

Suresh wondering if this proxy is an unicast/mcast proxy? 

Thomas thinks feeding mcast to proxy is not our(multimob's)job 

Dave mentions the proxy is useful only for unicast-multicast and multicast-unicast topologies but not for native multicast topologies

Dave does not think protocol extensions are required and he thinks that the switching per client basis not per mc group basis

Thomas wants to build a toolbox for future work

<END OF MEETING, OUT OF TIME>

_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 22 Mar 2008 12:08:01 +0100

Hi Suresh,

thanks for the minutes, here a couple supplements to fill the gaps 
(marked with "====>":

Happy Easter

thomas
-------------------------------------- snip ----------------------------

Marshall Eubanks mentioned that light weight MLD may or may not be 
standardized or implemented. We should not base multimob work on the 
assumption that it will be there

====> Thomas points out that light weight MLD actually does not address 
primary multicast issues such as leave latency, but that explicit 
tracking does. Explicit tracking is foreseen as an option in MLDv2.

====> Thomas refers to the problem statement 
(http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps), where this 
is included as reference 68.

Dave points out you can already subscribe to a multicast stream without 
using MIPv6 and the application on the MN will choose.

Dave wants to know who makes the choice about taking the direct or the 
home tunneled path. The stack on the MN or the Application?

Frank mentions that when the application joins the multicast group on 
the home interface the stack can switch to the local interface.

Bharat wants to know how the MN knows that the multicast service is 
available locally

Bill Atwood talks about charging on the AR (for local streams) being 
different from that on the home network. He thinks that the decision for 
this should be in the hands of the end user

====> Bill points out the potential problem that multiple reception of 
the same stream may lead to multiple charging of the end user.

====> Bill and Dave raise the question about where - in a mobile 
environment - the point of authentication is expected to reside.

Christophe Janneteau wants the user involved but not necessarily the 
application

Dave wants to quantify the advantages, since the propogation from the 
NAR to the common point might be pretty close.

He also wants to know about the tunnel management interference between 
unicast and multicast tunnels.

Thomas presented his slides about Proxy architectures for mobile 
multicast receivers (no draft)

Frank asks about whether the PAR or NAR must be the proxy agent in case 
of FMIP

Suresh mentions define "what"(the functionality) but not 
"where"(physical node)

====> Thomas characterizes the proxy definition as a stable, not moving 
box located in the "vicinity" of the wireless environment / mobile receiver.

====> Dave proposes the terminological distinction "Gateway" versus "Relay".

Dave mentions the proxy is useful only for unicast-multicast and 
multicast-unicast topologies but not for native multicast topologies

====> Dave states that a mobility anchor point (such as an HMIPv6 MAP) 
is automatically located on the path from listener to source, i.e., is 
an on-tree router.

Dave does not think protocol extensions are required and he thinks that 
the switching per client basis not per mc group basis

====> Thomas points out that different multicast streams (per group) may 
   be subject to different QoS or cost conditions. A per stream 
switching may thus be desirable.

====> Christophe agrees.

====> Thomas points out that an important multicast proxy function  may 
be a pro-active/on-hold subscription (without traffic forwarding). While 
operators configure such "listener proxies" manually today, an automated 
management will required protocol implementation, e.g., as an MLD 
extension.

Thomas wants to build a toolbox for future work
====> to prevent basic mechanisms from being re-invented over and over 
again.

Suresh Krishnan wrote:
> ------------------------------------------------------------------------
>