Using Dynamic Delay Pools for Bandwidth Management

1
Using Dynamic Delay Pools forBandwidth Management

• Gihan Dias and
• Chamara Gunaratne
• University of Moratuwa

2
System Configuration
Internet
International connections (low-speed)
congestion
hub
Web proxy
site
site
local connections(high-speed)
site
site
3
Initial Conditions

• Approx. 10 sites with 2000 users
• Shared 2 Mb/s international b/w
• Severe congestion
• Browsing the web took too long
• pages often timed out
• web was unusable
• Infeasible to increase bandwidth
• high cost of international links

4
Usage Patterns

• Normal users
• browse the web a page at a time
• low average data rate
• Heavy users
• download files (often multiple)
• multiple browser windows in parallel
• Small proportion of heavy users used much of the
  bandwidth

5
Objectives of Bandwidth Management

• Bandwidth is expensive and limited
• Provide fair access to all users
• Prevent a few users from using a disproportionate
  portion of available resources
• Control how bandwidth is used
• Decided to use Squid cache for b/w management

6
Delay Pools in Squid

• SQUID contains a bandwidth mgmt. system called
  Delay Pools
• Uses the token bucket algorithm
• Downloads up to pool size not limited
• Throughput limited thereafter to restore value

7
Effect of Delay Pools

• Heavy users are limited to data rate set by
  delay pool
• file downloads and media-heavy sites are slow
• Normal users get reasonable response
• not significantly limited
• congestion reduced by limiting heavy users
• Fair

8
Weaknesses in Delay Pools

• Static configuration only
• Cannot change parameters to suit varying load.
• A bandwidth setting small enough to restrict
  users at peak times will restrict utilisation at
  slack times.

9
Modifications to Delay Pools

• Evaluate the current load on the pool
• Change the data rate parameters dynamically
• Parameters vary between the min max depending
  upon load
• However, this does not change the basic design of
  delay pools

10
Dynamic Delay Pools Algorithm
Tokens available in aggregate pool?
Yes
No
User data rate at min value?
User data rate at max value?
Yes
Yes
No
No
User data rate is unchanged
User data rate is increased
User data rate is decreased
11
Multiple Delay Pools

• Multiple distinct user communities exist
• e.g., departments, staff/students
• Each community may be allocated some bandwidth
• Bandwidth usage by one community should not
  affect other communities
• Can be implemented by configuring one delay pool
  per community

12
Optimising Multiple Delay Pools

• Some pools may be under-utilised while others are
  saturated
• Need method of allowing this bandwidth to be used
  by other pools
• Modified Delay pools to transfer capacity from
  lightly-used pools to heavily-used ones
• excess tokens are stored in a buffer
• loaded pools take tokens from buffer

13
Bandwidth Transfer Algorithm
Add tokens to delay pool
Tokens in pool exceed max value?
No
Yes
Add excess tokens to buffer
Excess tokens available in buffer?
Yes
No. of tokens more than buffer size ?
Yes
Get tokens from buffer and top up pool
Set no. of tokens to buffer size
14
Effects of our Modifications

• Interactive users have reasonable access at peak
  hours
• Without delay pools
• gt60 sec (often timeouts)
• With dynamic delay pools
• lt15 sec (almost no timeouts)
• During slack hours, users are able to utilise all
  available bandwidth
• Available resources are optimally used at all
  times

15
Modified SQUID at Work ..
Sustained per-user data rate (after initial burst
of 100kB)
16
Modified SQUID at Work, ctd ..
17
Performance Comparision
18
Thank you!

• Gihan Dias
• gihan_at_cse.mrt.ac.lk
• Chamara Gunaratne
• pgunarat_at_csee.usf.edu