TOMA: A Viable Solution for Large-Scale Multicast Service Support

1
TOMA A Viable Solution for Large-Scale Multicast
Service Support

• Li Lao, Jun-Hong Cui, and Mario Gerla
• UCLA and University of Connecticut
• Networking 2005
• Presented by Kyungmin Cho
• 2005/10/19

2
Contents

• One Line Comment
• Motivation
• Problem
• Solution Approach
• Experiments
• Conclusion
• Critique

3
One Line Comment

• This paper presents Two-tier Overlay Multicast
  Architecture (TOMA) to provide scalable and
  efficient multicast support for various group
  communication applications

4
Motivation(1/2)

• IP multicast
• the lack of a scalable inter-domain routing
  protocol
• the state scalability issue with a large number
  of groups
• the lack of support in access control
• the requirement of global deployment of
  multicast-capable IP routers
• the lack of appropriate pricing models
• Application-layer multicast
• generally not scalable to support large multicast
  groups
• relatively low bandwidth efficiency
• heavy control overhead
• hard to have an effective service model for ISP
• difficult to have efficient member access control
• not easy to obtain the knowledge of the group
  bandwidth usage

5
Motivation (2/2)

• Who care about a practical solution for
  large-scale multicast support?
• Network service providers (or higher-tier ISPs) ?
• Internet Service Providers (or lower-tier ISPs) ?
• End users?
• ISPs in the middle want to use limited bandwidth
  purchased from network service providers to
  support as many users as possible

6
Problem

• How to provide scalable, efficient, and practical
  multicast support for various group communication
  applications

7
Solution Approach

• Two-tier Overlay Multicast Architecture (TOMA)
• MSON (Multicast Service Overlay Network) node is
  deployed by MSON provider (ISP)
• end hosts (group members) subscribe to MSON by
  transparently connecting to some special proxies

g1
g0
g3
g0
End hosts
Member proxy
g0
t0
g1
MSON Node
Member proxy
g1
Member proxy
g3
g0
8
Issues

• Efficient management of MSON
• How does an MSON provider efficiently establish
  and manage numerous multicast trees?
• Cluster formation outside MSON
• How should members select and subscribe to
  appropriate member proxies?
• How are efficient clusters formed among end
  users?
• MSON dimensioning
• Where should the overlay proxies be placed?
• How much bandwidth should be reserved on each
  link?
• Pricing
• How to charge the users of MSON?

9
OLAMP for Efficient MSON Management

• Aggregated Tree

DNS Server (Group Registry Server)
t0 (g0, g1)
t1 (g3)
MSON Node
g3
g1
g0
End hosts
g0
Host Proxy of g3
g1
Host Proxy of g0
g1
g3
g0
10
OLAMP for Efficient MSON Management

• Member Join Before selecting a member proxy

TOMA//groupname.xyzmson.com/
IP addresses of member proxies
DNS Server (Group Registry Server)
t0 (g0, g1)
t1 (g3)
MSON Node
g3
g1
g0
End hosts
Host Proxy of g3
g0
g1
Host Proxy of g0
g1
g3
g0
11
OLAMP for Efficient MSON Management

• Member Join After selecting a member proxy

O-JOIN-ACK(g1, t0)
O-JOIN(g1)
t0 (g0, g1)
t1 (g3)
g3
O-GRAFT(t0)
g1
g0
t1
End hosts
g0
t0
g1
host proxy
g1
Group-tree matching
g3
g0
12
OLAMP for Efficient MSON Management

• Member Leave

Group-Tree Matching Table
Tree Groups
t1 g3
X
t0 (g0, g1)
t1 (g3)
host proxy
g1
g0
g3
g0
t1
End hosts
g0
t0
O-LEAVE(g3)
O-LEAVE-ACK(t1)
g1
Leave
O-PRUNE(t1)
g1
g3
g0
13
OLAMP for Efficient MSON Management

• A trade-off between bandwidth waste and
  aggregation
• the more bandwidth we are willing to sacrifice,
  the more groups can share one tree
• Dynamic Group-Tree Matching Algorithm
• average percentage bandwidth overhead for tree t
• bth is a bandwidth overhead threshold
• Algorithm
• if g is not new and the current tree t for group
  g is still appropriate (t can cover g, enough
  bandwidth, and bth is OK), t is used for g
• else, check if any existing tree is appropriate
  for g
• If so, the one with the minimum cost is selected
  (O-SWITCH(g, t, t))
• else, the native tree to is used to cover g

14
Cluster Formation Outside MSON

• Member Proxy Selection
• An end user selects one proxy based on the
  criteria of low latency and low workload
• measure the RTT by sending ping requests
• In the reply, the proxy piggybacks its workload
  information
• the total number of end users
• the total amount of access bandwidth in use
• P2P Multicast in Access Networks
• the member proxy stores the group membership
  information
• end users monitor its peers (delay, available
  bandwidth) and reports this information to its
  member proxy
• the member proxy computes P2P multicast delivery
  trees and disseminates the (parent, children)
  entries to the members
• end users connect with their children and
  transmit data packets via unicast

15
Experiments

• Experiments in NS-2
• compare TOMA with
• (1) NICE, (2) IP multicast, and (3) unicast
• Simulation Settings
• Transit-Stub topologies
• 50 transit domain routers and 500-2,000 stub
  domain routers
• End hosts are attached to stub routers uniformly
  at random
• topology abstracted from real network topology,
  ATT backbone
• 54 routers
• each router has a weight wi, end hosts are
  attached with a probability proportional to wi

16
Experiments

• Multicast Tree Performance
• total number of links in a multicast tree

17
Experiments

• Multicast Tree Performance
• average link stress, average path length

18
Experiments

• Control Overhead

19
Experiments

• Effectiveness of MSON Management Protocol

20
Conclusion

• A Two-tier Overlay Multicast Architecture (TOMA)
• group communication applications
• infrastructure-supported overlays
• facilitate the deployment of multicast server
• MSON as the backbone service domain and P2P
  multicast in the access domains
• efficient resource utilization with reduced
  control overhead
• OLAMP for MSON management
• the control overhead for establishing and
  maintaining multicast tress are significantly
  reduced
• far less forwarding state

21
Critiques

• Strong Points
• address the issue of who is responsible for
  deploying multicast service
• supporting numerous groups having a large number
  of members
• Dynamic group tree matching algorithm
• Weak Points
• messages which is required for a subset of
  members are also delivered to all members through
  network
• fine grained-filtering should be performed at end
  hosts