Subject: Re: [multimob] Summary from multimob session @ IETF71

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 Mar 2008 08:48:49 -0700 (PDT)

Thomas we are looking forward to reading your draft and then let's discuss it on the list.

Regards,

Behcet

----- Original Message ----
From: Thomas C. Schmidt <[email-masked]>
To: Suresh Krishnan <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; [email-masked]
Sent: Saturday, March 22, 2008 6:08:01 AM
Subject: Re: [multimob] Summary from multimob session @ IETF71

Hi Suresh,

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

Happy Easter

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

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

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

Dave Thaler mentions his presentation about source mobility in multcast

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

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

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

Dave agrees and  wants to have the costs predictable.

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

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.

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

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

<END OF MEETING, OUT OF TIME>

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 27 Mar 2008 12:27:46 +0900 (JST)

Hi,

> assumption that it will be there

Right. The direction has not fixed, while the LW-MLDv2 spec might
become an experimental RFC.

> tracking does. Explicit tracking is foreseen as an option in MLDv2.

LW-MLDv2 does not aim to minimize join/leave latency. The main aim of
this protocol is to reduce the protocol and implementation
complexities by eliminating (usually) unneeded functions.

> management will required protocol implementation, e.g., as an MLD 

Thomas, could you explain more about what this comment means?

Thanks,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 27 Mar 2008 12:15:07 +0100

Hi Hitoshi,

> complexities by eliminating (usually) unneeded functions.
Yes, this we tried to clarify ... as you weren't there and the 
discussion somehow brought up the wrong context.

> Thomas, could you explain more about what this comment means?
This is mechanism is a (subscription-) proxy function used at relays 
already today. A multicast relay maintains a group subscription without 
forwarding traffic, e.g., down a wireless link to assist a fast 
forwarding in case a listener for that group arrives on the link / in 
the domain.

This mechanism is described in the section "5.2.4 MLD Extensions" of the 
problem statement
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

and a protocol realization in the form of an MLD extension is given in 
section "4.5 Router attendance control in MLD" of the M-HMIPv6 draft

http://tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6

Could I make things clearer, now?

Best regards,

thomas
-- 

° Prof. Dr. Thomas C. Schmidt
° HAW Hamburg, Dept. Informatik
° University of Applied Sciences
° Berliner Tor 7, D 20099 Hamburg
° Germany, Fon: +49-40-42875-8157
° http://www.informatik.haw-hamburg.de/~schmidt
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob