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 Pool Bytes out to user/users Bytes in from outside 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 No Tokens available in aggregate pool? Yes User data rate at min value? Yes Yes User data rate at max value? No No User data rate is decreased User data rate is unchanged User data rate is increased

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: >60 sec (often timeouts) • With dynamic delay pools: <15 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. 90 80 70 60 50 Time (s) 40 30 20 10 0 1 2 3 4 5 6 7 8 9 Unmodified Squid without delay pools Unmodified Squid with delay pools Modified Squid with dynamic delay pools Performance Comparision

18. Thank you! Gihan Dias gihan@cse.mrt.ac.lk Chamara Gunaratne pgunarat@csee.usf.edu