Distributed Admission Control for Heterogeneous Multicast with Bandwidth Guarantees

1
Distributed Admission Control for
Heterogeneous Multicast with Bandwidth Guarantees

• Sudeept BhatnagarBadri Nath
• Dataman Lab, Rutgers University
• sbhatnag, badri_at_cs.rutgers.edu

Arup Acharya IBM T.J.Watson Research
Center arup_at_us.ibm.com
2
Admission Control

• Admit a request only if enough resources
  available
• Bandwidth guarantees gt zero-false-positives
• Link state estimation using probes is not a
  solution
• Cannot guarantee zero-false-positives
• Keep network core simple
• We focus on admission control for heterogeneous
  multicast
• Different users, different needs

3
Example

Source
5
5
5

• Receiver 1 has reserved 5 units
• Receiver 2 requests 7 units

Reserve 7 units
Receiver 1
Receiver 2
4
Example

Source
7
7
5
7
Expected reservation tree after the request has
been processed
Receiver 1
Receiver 2
5
Possible Solution -RSVP

Source
7

• Send resv message
• Routers on its path take admission decision

7
5
7

• Problems
• Per-flow state even if data plane could be made
  stateless
• Periodic refresh messages to be processed at core

Resv 7 units
Receiver 1
Receiver 2
6
Possible Solution Bandwidth Broker

5

• Request redirected to BB
• BB takes decision and updates state (if required)

5
Bandwidth Broker
5

• PROBLEMS
• Link failure leads to service unavailability
• Single point of failure

Reserve 7 units
Receiver 1
Receiver 2
7
Our Aim

5
Edge router takes the admission decision for
entire path

• AIM
• No central information repository
• Eliminate decision making process at core
• Edge-to-edge solution
• Core router involvement be dependent on data plane

5
5
Resv Message
Receiver 1
Receiver 2
8
Two Requirements

• Edge router needs to know the available bandwidth
  on each link
• Distributed resource management
• Enhancement of our Infocom 2003 work
• Determining how much to reserve on each link
• Accounting for existing reservations

9
Distributed Resource Management
10
Key Problem - Concurrency

Edge Router Core Router
Request for 8 units
R1
10 units

• Solution
• Partition the link bandwidth among edge routers

R2
Request for 3 units

• Concurrency is no more an issue

11
How to Partition?

80 traffic
R1
R1s Share ? 50 ?

• Equal Shares?
• gtUnder-utilization
• Solution
• Partition the bandwidth fairly

10 units
R2

• Traffic patterns change over time
• Solution
• Adapt dynamically to current traffic

20 traffic
12
Key Idea

• Edge routers operate as an Overlay Token Ring
• A token circulates in the ring in a
  pre-determined order

Token Contents Aggregate traffic estimate (E)
Token
13
Link Partitioning Example
R1
R2
1000 units
R3
Token
R4
E 194205320125 844
Scenario
The token has just left R4
Unused 32.47
14
Link Partitioning Example

Token
R1
R2
1000 units
R3
R4
E 844 194 210 860
Scenario The token arrives at R1. Current
Estimate 210 Share min(194, 210) / 860
Unused 19.9
15
Features

• Adapts to traffic patterns
• One token cycle delay
• Fault-Tolerant
• Node failure does not make service unavailable
• Timeout based token regeneration gt No human
  intervention
• Minimal storage requirement
• 3 variables per link

16
Link Partitioning Problem

New Link Share 1000min(205,255)/910
225.27 R2 might have already allocated more than
225.27 units from its share in last cycle !
R1
Token
R2
1000 units
R3
R4
E 860 205 255 910
Scenario The token arrives at R2. Current
Traffic 255 Share min(205, 255) / 910
17
Solution

• Set a flag in the token to freeze the current
  allocation
• Fair partitioning gt maximum utilization
• At time of freezing the partitioning is almost
  fair
• Actual allocation at the time of freezing is
  expected to be large

18
Simulation Result

Link Capacity 20000 units Requests arrival
Poisson Each request for 1 unit Flow duration
exponentially distributed with mean 500 sec
19
Possible Uses

• Bandwidth guaranteed admission control
• 2-tier statistical admission control architecture
• Edge router measures traffic locally
• Unaffected by transient bursts from other edge
  routers
• Bandwidth guarantees with service differentiation
  at edge routers
• Simple FIFO core routers

20
Determining Bandwidth Requirements
21
How much to reserve?

Source
5
5
How much to reserve on which link?
5
Reserve 7 units
Receiver 1
Receiver 2
22
Simple Solution

• Source edge router stores the entire group
  reservation tree
• For each group rooted at itself
• If data plane is stateless gt stateless multicast
  QoS
• Distributed Bandwidth Broker for both unicast and
  multicast
• What if data plane requires rate information at
  forwarding interface?
• Use it to reduce storage requirement at edge

23
Core Routers Store Forwarding State

Source
E2
E1
5
E3
C2
C1
5
C3
5
-E5 creates Reserve(G,7) packet and forwards it
upstream
E5
E4
Resv 7 units
Receiver 1
Receiver 2
24
Intra-domain Signaling

Source
E2
E1
5
E3
Reserve(G,7) Packet C3?E5 7 units
C2
C1
5
C3
5
-E5 creates Reserve(G,7) packet and forwards it
upstream -C3 adds (C3?E5 7 units) to
Reserve(G,7) packet
E5
E4
Resv 7 units
Receiver 1
Receiver 2
25
Reserve Packet Update

Source
E2
E1
5
E3
Reserve(G,7) Packet C3?E5 7 units C1?C3 2
units
C2
C1
5
C3
5
-E5 creates Reserve(G,7) packet and forwards it
upstream -Core routers add additional required
bandwidth
E5
E4
Resv 7 units
Receiver 1
Receiver 2
26
Reserve Packet Update

Source
E2
E1
5
E3
Reserve(G,7) Packet C3?E5 7 units C1?C3 2
units
C2
C1
5
C3
5
-E1 knows the required bandwidth and takes
admission decision
E5
E4
Resv 7 units
Receiver 1
Receiver 2
27
Join Confirmation

Source
E2
E1
5
E3
C2
C1
5
Join-confirm(G,7)
C3
5
E5
E4
-E1 sends confirmation to E5 Join-Confirm(Reserve
(G,7))
Receiver 1
Receiver 2
28
Rate Update

Source
E2
E1
5
E3
C2
C1
5
Rate-Update(G,7)

• E5 send Rate-Update(G,7) along the path given in
  Join-Confirm
• Core routers update their forwarding rate
• E1 echoes back Rate-Update packet to E5

C3
5
E5
E4
Resv 7 units
Receiver 1
Receiver 2
29
Miscellaneous

• Need to handle concurrent join/leave requests
  originating from different routers
• Cache active reservation tree until Rate-Update
  packet is echoed back
• No refresh message processing in core
• Soft-state maintained inherently by multicast
  data plane
• Robustness to core node failure using bandwidth
  dependency matrix
• Concept developed in a follow-up work

30
Summary

• Dynamic bandwidth partitioning
• Overlay-based distributed admission control for
  heterogeneous multicast
• Scalability inherently linked to the multicast
  data plane
• Entirely core-stateless multicast QoS possible
• Current Work
• Simplified data plane for multicast
• Performance Bounds
• Bandwidth guarantees using edge-based service
  differentiation

31
Thank You! Questions?