Towards Economically Viable Infrastructurebased Overlay Multicast Networks

1
Towards Economically Viable Infrastructure-based
Overlay Multicast Networks

• Varun Khare (vkhare_at_cs.arizona.edu)
• Beichuan Zhang (bzhang_at_cs.arizona.edu)
• Department of Computer Science
• University of Arizona
• Tucson, AZ

2
What is Infrastructure-based OMN?
3
Infrastructure-based OMN

• Objective Build overlay multicast trees to
  minimize infrastructure cost while providing good
  network performance for end users
• Most indicative factors affecting operational
  cost of Infrastructure-based OMN services
• Bandwidth costs
• Reliability and stability of the whole system

4
How ISPs charge for bandwidth?

• SLA between ISP and content provider defines
  charging function
• Charging Function is concave in nature

5
Overlay Multicast Tree Construction

• Constructing data delivery paths for multicast
  groups involve
• Assigning users to servers dominates the ISP
  cost to support group
• Organizing servers into a dissemination tree
  rooted at the source dominates the user delay
  experience

(ROMaN focus)
(OMNI/AMCast focus)
6
User Assignment affects ISP Cost

• Example 1. Assigning users to fewer servers
  reduces ISP cost

7
User Assignment affects ISP Cost

• Example 2. Assigning users to cheap servers
  reduces ISP cost

8
Problem Statement

• Given information about servers in OMN
• ISP charging function ci and
• Available Bandwidth Bi
• Find user distribution ui at each server SRVi for
  N users of multicast group where each user
  consumes b bandwidth, such that Sui N
  ui . b Bi and Sci.(ui . b) ISP cost of
  group is minimized

9
Offline Dynamic Programming Solution

• Optimal solution to distribute N users amongst K
  servers contain optimal solution to distribute i
  users amongst j servers (i N and j K)
• Evaluating (N,K) gives optimal user distribution
• Runtime O(K.N2) and space complexity O(K.N)
• Slow for handling user dynamicsFor any ?N the
  runtime cost is O(K.?N)

10
Online Iterative Greedy Heuristic

• Assign users to server with least marginal ISP
  cost and available bandwidth (Cheapest Available
  Server)
• How to determine which server is marginally
  cheaper?
• Compare marginal ISP costs at intersection
  point
• Not optimal user distribution but reduces runtime
  complexity

11
Examples Online Algorithm

• No intersection exists between SRVA and SRVB
  charging functions

12
Examples Online Algorithm

• User distribution scenarios1. (UA8,
  UB4) OR 2. (UA4, UB8)

13
ROMaN Protocol Entities

• Root server
• Serving source content for the group
• Session server
• Servers facilitating the dissemination of content
  
• Interested Users
• Surfers short session duration
• Viewers longer session duration

14
ROMaN Protocol Challenges

• Challenge
• Maintain Cost Optimization of group in the face
  of user dynamics
• Design Principle
• Root calculates Target User Assignment for
  session servers to maintain cost-efficiency
• Root pre-calculates cheapest server for new users

15
ROMaN Protocol Challenges

• Challenge
• Prior OMN protocols propose users statically join
  Nearest Server and ask server to join groups
• Unable to handle clustering in user population
• Design Principle Dynamic Server Join Policies
• Nearest available Server User joins any nearby
  server for accessing a multicast group
• Cheapest available Server User directed to join
  server with least marginal ISP cost

16
ROMaN Protocol Root Responsibility

• Handle user join requestsRedirect users to
  session servers
• Periodically update Target User Assignment of
  session servers

17
Handle User Join Requests

• User Join requests re-directed to leaf server
  SRVI with least excess users
• All excess users maintained at leaf level
• Joining user treated as surfer and injected at
  leaf level

18
ROMaN Protocol Challenges

• Challenge
• Surfers main cause of change in user distribution
• Handling such change can potentially impact
  network performance of all users

U User
A
Candidate Eviction
3 Users Leave
B
Re-Stitch Tree
U1, U2, U3
C
D
19
ROMaN Protocol Challenges

• Objective to minimize disruption to the overlay
  tree by user dynamics
• Design Principle Progressive User Movement
  Scheme
• Restrict surfers to leaf session servers
• Allow viewers to advance towards the root

20
ROMaN ProtocolSession Server Responsibility

• Maintain Target User Assignment
• Progressive User Movement Scheme
• Facilitate Server join protocol
• HMTP Protocol

21
Progressive User Movement Scheme

• Leaf Servers sources of excess users Non-Leaf
  Servers sinks where user leave causes deficiency

22
Progressive User Movement Scheme

• Deficiency satisfied by transferring users from
  sub-tree
• Step 1. Extract excess users in the sub-tree
• Step 2. Split remaining user requests amongst
  child servers

23
Progressive User Movement Scheme

• User movement implemented through local
  interactions between parent-child session servers
• Users with maximum session duration given
  preference for such user movement

24
Progressive User Movement Scheme

• Only leaf server left with deficiency of
  users(Server C candidate for eviction)

25
HMTP Server Join Protocol

• All session servers potential parents
• Initially Potential Parent root server
• Query Potential Parent
• if bandwidth available then join Potential
  Parentelse retry join at nearest child of
  Potential Parent

26
Simulation and Experiment Setup

• Inter AS level topology data downloaded
  (http//irl.cs.ucla.edu/topology/)
• Servers and Users attached to randomly chosen AS
  locations
• Compare against OMNI and AMCast OMN protocols

27
Simulation and Experiment Setup

• Inter AS level topology data downloaded(http//ir
  l.cs.ucla.edu/topology/)Inter AS path latency
  vary between 150 500ms
• Servers attached to randomly chosen AS locations
• Physical User Locations
• Evenly distributed underneath AS locations
• Realistic Zipf distributionCapture clustering
  and diversity for user population
• OMNI and AMCast are state of art OMN protocols
  used as benchmarks

28
Compare ISP cost of groups
c(r) (a ß . ln r) . r where r bandwidth

• Compare ISP cost of group when servers deployed
  in single ISP
• ROMaN lowers the ISP cost for deploying groups of
  all sizes

29
Compare ISP cost of groups
c(r) (a ß . ln r) . r where r bandwidth
Different Cost Function

• Compare ISP cost of group when servers deployed
  in different ISPs
• ROMaN lowers the ISP cost for deploying groups of
  all sizes

30
ROMaN reduces ISP cost of deploying multicast
groups

• Servers low saturation point Difference in ISP
  cost significant
• Servers high saturation point Difference in ISP
  cost less significant

31
Dynamic Server Join policies improve Scalability
of OMN protocols

• Users distributed realistically at AS locations
• Nearest Server join policy unable to handle
  clustering
• ROMaN protocol produces maximum revenue by 1.
  optimizing ISP cost 2. avoiding any user drop

32
Compare user delay experience

• User Delay Overlay Tree Delay Last-Hop delay
• ROMaN Overlay Tree Delay minimized due to size
  of overlay

33
Compare user delay experience

• ROMaN adjusts overlay size to maintain lower tree
  delay
• OMNI overlay size remains near constant

34
Compare Viewers delay experience
All Users
Viewers
35
Conclusion

• Assigning users to cheapest server reduces ISP
  cost of group
• Reduced overlay size improves network performance
  of users
• Serious viewers rewarded with better network
  performance and stability

36
Thank You!

• Questions? Comments?