Subject: [multimob] Thoughts on PMIP Optimized Routing

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 29 Mar 2011 16:56:53 +0200

Hi all,

after the presentations and discussions today, the following thoughts 
came up.

  1. Scenarios for tunnel convergence problem

Tunnel convergence is an issue of heavily used multicast reception. This 
only occurs for major events (e.g., sports on IPTV), or in flashcrowds, 
both scenarios cannot be serviced today (by unicast). For such 
situations, it may be realistic to assume that operators (somehow) pull 
the particular content into their network and deploy local multicast 
routing for scalability reasons. This is actually the cheapest and 
easiest. (There may be "political" reasons to act differently, though.) 
It may also be that some local social community group service is 
established within operator domains (with MNs acting as sources and 
receivers).

Assuming this scenario, we need to provide

   * Coexistence of home/remote content retrieval (e.g., by the base 
solution) and access from local multicast routing. Thus a MAG would need 
to distinguish (preconfigured) local group subscriptions from non-local 
content.

   * Account for the scenario of Sri that an MN may move between PMIP 
domains, but stay with its LMA. This means that content that has been 
locally accessible at the previous MAG can only be retrieved via home 
its remote LMA at the new MAG.

  2. State of the current proposals from the perspective of the above 
scenarios

   (a) M-tunnels to (unassociated) LMAs (Hitoschi) - aside from the 
other issues discussed today, this approach does seam to just 
"distribute load" over different LMAs and tunnels without addressing the 
specific scenario.

   (b) Dedicated Multicast Tunnelrouter/"M-LMA" (Juan-Carlos) - this 
approach has the inverse scaling problem (avalanche) in the major event 
setting, i.e., the "M-LMA" needs to replicate data streams to all MAGs. 
So it sort of threatens the devil by being the beelzebub. In addition, 
it introduces the unpleasant asymmetry in routing Matthias mentioned in 
a previous mail.

  (c) Local mcast routing (Seil) - this approach lacks incorporation of 
home/remote content, as well as Sri's scenario.

As a conclusion, my impression is that we don't have a striking proposal 
on the table yet. We should concentrate more an the key scenarios in 
PMIP deployment (maybe Sri can help ?), and on characteristic use cases 
for real scaling problems.

Cheers,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 30 Mar 2011 21:41:05 +0200

Hi Thomas, some comments below:

2011/3/29 Thomas C. Schmidt <[email-masked]>

> Hi all,
>
> after the presentations and discussions today, the following thoughts came
> up.
>
> only occurs for major events (e.g., sports on IPTV), or in flashcrowds, both
> scenarios cannot be serviced today (by unicast). For such situations, it may
> be realistic to assume that operators (somehow) pull the particular content
> into their network and deploy local multicast routing for scalability
> reasons. This is actually the cheapest and easiest. (There may be
> "political" reasons to act differently, though.) It may also be that some
> local social community group service is established within operator domains
> (with MNs acting as sources and receivers).

Luis>> The traffic is commonly placed close to the user in streaming
scenarios, based on unicast delivery. In this situation it makes sense to
deploy content locally, because a lot of resources are saved along the
network. However, we are talking here of multicast, where only one flow for
a major event is sent from the Home Network to the LMA in the border of the
Visited Network. There is no better scalability than this. Internally, in
the Visited Network, both the LMA and the MR are connected to the same
number of MAGs, so not very much scalability advantage can be foreseen for
local routing (of course, it depends on the topology).
Operationally, to pull local content for certain events does not seem an
easy task. It forces the Home network operator firstly to determine what
kind of events are worthy to be deployed on local routing fashion, and what
other not; secondly, to place locally in multiple Visited network the
content (maybe a different content per Visited network), maybe in some
timeframes of the day (e.g. football match duration), etc, etc. Only to save
one multicast flow per content. I really don't see the benefit.

> solution) and access from local multicast routing. Thus a MAG would need to
> distinguish (preconfigured) local group subscriptions from non-local
> content.

Luis>> This is not possible with current functionality on MAG as MLD proxy.
It is only possible to define one upstream interface, so the operator would
be forced to permanently choose between local or remote multicast for all
kind of traffic.

> locally accessible at the previous MAG can only be retrieved via home its
> remote LMA at the new MAG.

Luis>> This seems to not be affordable with other solution distinct to the
M-LMA approach. How is the multicast traffic delivered from pMAG to nMAG via
the LMA? Is it sent on unicast flows, one per MN attached to nMAG? Is it
sent tunneled from pMAG to LMA?. In that case, is it pMAG multicast router
to accept subscriptions coming from LMA? Please, compare this with the
starightforward delivery of the multicast content from a common M-LMA placed
in the border of both PMIPv6 domains. No strange mechanisms are needed to
maintain multicast service for the MN changing the PMIPv6 domain.

>  (a) M-tunnels to (unassociated) LMAs (Hitoschi) - aside from the other
> issues discussed today, this approach does seam to just "distribute load"
> over different LMAs and tunnels without addressing the specific scenario.
>
>  (b) Dedicated Multicast Tunnelrouter/"M-LMA" (Juan-Carlos) - this approach
> has the inverse scaling problem (avalanche) in the major event setting,
> i.e., the "M-LMA" needs to replicate data streams to all MAGs. So it sort of
> threatens the devil by being the beelzebub. In addition, it introduces the
> unpleasant asymmetry in routing Matthias mentioned in a previous mail.

Luis>> The M-LMA only sends one copy per connected MAG. In the major event
setting, with a lot of viewers subscribed to the same content, the M-LMA
approach is more efficient than the base solution (as described in the
comparison there included). Furthermore, the service is offered without
complex interaction with the Visited network provider.

> Best regards,

Luis

---

From: seil jeon <[email-masked]>
Date: Thu, 31 Mar 2011 10:37:44 +0900

Hi Luis,

Please see below "Seil"

2011/3/31 Luis M. Contreras <[email-masked]>

> one multicast flow per content. I really don't see the benefit.

"Seil" => You don't see the benefit. why? ISPs are now making a pitch for
building and getting their own contents from public broadcasters, cable
broadcasters, ... so on. Obiviously, this is inevitable trend to achieve
competiveness from other ISPs. That will be getting serious more than
now. And as I presented in my slot, this concept is reflected at MBMS
architecture of 3GPP SAE. Only appropriate manner needs to be handled
between home and visited network. About that, the draft will be updated.

  In M-LMA, how about local contents?

> be forced to permanently choose between local or remote multicast for all

 "Seil" => Yes, it's possible. Only one upstream interface is available but
"per single MLD proxy instance". So, the choice will not be forced to
operators.

> maintain multicast service for the MN changing the PMIPv6 domain.

 "Seil" => Actually, M-LMA should not be said "LMA" as pointed out in the
meeting because there's no PMIP action with a MAG and no information related
to MNs. And I wonder only one M-LMA is enough to connect with MAGs in
visited domain because M-LMA must be managed by certain operator.

>> setting, i.e., the "M-LMA" needs to replicate data streams to all MAGs. So
>> it sort of threatens the devil by being the beelzebub. In addition, it
>> introduces the unpleasant asymmetry in routing Matthias mentioned in a
>> previous mail.
>
>

 "Seil" => In terms of "traffic distribution", hitoshi's approach is better
than M-LMA. And local routing is the best among them.

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

Seil Jeon

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 31 Mar 2011 23:03:01 +0200

Hi Seil,

>   In M-LMA, how about local contents?

Luis>> It is just my personal view in this interesting and necessary debate
opened byThomas. I would like to distinguish two concepts: remote content
distributed locally, and local content distributed locally. In the first
case, I don't see the benefit. I think that the simplest way to deliver the
service is through M-LMA. In the second case, I agree that it seems more
optimal to use direct routing. But, in my opinion, the direct routing can
not be consider as the main solution, but an ocassional optimization
scenario in case the content is local to the visited domain (probably the
most common is that a MN usually will demand contents from its Home Network,
because the user maintains a service contract its Home Operator). I think it
is the same idea than in the unicast case regarding the routing
optimization: it is an optimization case for a more general solution (which
I believe it is the M-LMA approach).

>> Luis>> This is not possible with current functionality on MAG as MLD
>> proxy. It is only possible to define one upstream interface, so the operator
>> would be forced to permanently choose between local or remote multicast for
>> all kind of traffic.
>>
>

Luis>> I don't think so. According to base solution, the MN is associated to
an MLD proxy instance as a function of the LMA it is bound to. That is, the
association to an MLD instance is previous to the MLD Report processing. So,
the MAG doesn't know the required content (local or remote) before
associating the MN to a proxy instance. As consequence, the operator is
forced to choose between using an MLD proxy pointing to the M-LMA or another
one pointing to local MR for all kind of traffic, and for all the MNs
associated to the same LMA.

> visited domain because M-LMA must be managed by certain operator.

Luis>> I'm not totally agree with this (it is my personal opinion). I think
that establishing a tunnel following PMIPv6 procedures can be considered a
PMIP action. Furthermore, all other stuff related with security,
authentication, heartbeat, load balancing, etc, etc, defined in PMIPv6 can
be applicable in an straightforward manner. It is true that there is no
information per MN, but the protocol procedures of PMIPv6 are wider than
this.

Regarding the number of M-LMAs per visited domain, I consider possible that
different Home providers connect to a common Visited Network, each of them
managing its own M-LMA, and sharing (or not) the MAGs placed in the Visited
network.

> than M-LMA. And local routing is the best among them.

Luis>> I need to study this to provide a comparison.

Thanks all for this enriching discussion,

best regards,

Luis