2002/08/15 Using Dynamic Delay Pools for Bandwidth Management Gihan Dias and Chamara Gunaratne University of Moratuwa

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

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

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

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

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 Delay Pool Bytes in from outside Bytes out to user/users Delay Pools in Squid

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

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.

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

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

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

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

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

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

Modified SQUID at Work.. Sustained per-user data rate (after initial burst of 100kB)

Modified SQUID at Work, ctd..

Performance Comparision

Thank you! Gihan Dias Chamara Gunaratne