Monday, May 4, 2009

How to Effectively Use Your Bandwidth

This blog tries to help you use your ISP bandwidth wisely! You might be the system administrator of a company who always wanted to limit your fellow workers from downloading the media files, limiting the access of streaming videos which are available in YouTube and wanted to share adequate bandwidth to your SMTP and HTTP Servers. This blog is for those persons.

To Readers: All those starting with # are run by root user and ;'s are comments inside the configuration files

We are going to use the delay_pools TAG in squid.
Before going straight into the configuration, I would like to write some theory.

What exactly are delay pools?

They are simply pools which make a delayed response.
They are essentially bandwidth buckets!
Some of you might have quizzically raised your eyebrows when you read buckets, I know! I too was very much confused about this bucket concept! But I think I can clarify the whole concept for you!

Imagine bandwidth bucket has a normal plastic bucket used to storing water! Instead of water these buckets store bandwidth! Initially it will be full! Initially means when no one is using your bandwidth. When a user requests a page, he will get the respone only if theres enough bandwidth available from the bucket he is using. Bucket actually stores traffic! Bandwidth is expressed in terms of how much data is available in one second, like 1Mb/s (1Mbps)
Traffic is expressed in terms of total data, like 1MB.

Size of bucket determines how much bandwidth is available to a client(s). If a bucket starts out full, a client can take as much traffic as it needs until the bucket becomes empty. Client then recieves bucket allotment at the 'fill rate'. (I will tell about the fill rate later, just remember that word in mind).

There are three types of delay pools.

Class 1 => Single aggregate bucket (Totally shared among the members of the bucket)

Class 2 => To understand it better, assume its applied to Class C networks.
Theres one bucket for each network and 256 individual buckets for each ips of every network. Size of individual bucket cannot exceed the network bucket!

Class 3 => One aggregate bucket, 256 network buckets, 65536 individual buckets. (Class B networks)

Now into configuration,

Firstly we need to define how many delay pools we are doing to declare.

delay_pools 2
This means that we have two delay pools.

delay_class 1 3
This means that the first pool is a class 3 pool (Class B networks)

delay_class 2 1
This means that the second pool is a class 1 pool (Single aggregate bucket)

For each pool we should have a delay_class line.

Now we need to define each pools parameters, like the capacity of each pool and fill rate.

delay_parameters 1 7000/15000 3000/4000 1000/2000
this is delay pool parameters for the pool 1
Pool 1 was a class 3 pool. Class 3 pool has 3 buckets, one aggregate bucket, one for 256 networks and one for 65536 individual ips!

delay_parameters 2 2000/8000
The second pool of type class 1. Class 1 has only one aggregate bucket!

Now whats this 2000/8000?
Each bucket is recognized by its rate/size
Here 8000 means that the maximum capacity of the bucket!
And it refills at the rate of 2000 bytes/second
This means that if the bucket is empty, it takes 4 seconds for the bucket to get full if no clients are accessing it!

If you find a declaration like this,
delay_paramters 2 -1/-1
This means theres no limitation to the bucket!

Now lets take an example.

Our ISP connection is 12Mbps and we want our machines to have a maximum of 4 Mbps at peak time.
The rest we dedicate for SMTP or other production servers. We are going to define only one delay pool of class 1

What is actually 12Mbps?

1Mbps = 1 Megabits per second => 1/8 Megabytes per second (8 bits = 1 byte)
1/8 Megabytes per second => 1/8 * 1024 Kilobytes per second => 128Kilobytes per second => 128KBps
so 1 Mbps => 128 KBps
so 12 Mbps => 128 * 12 = 1536 KBps => 1.5 MBps
To sum up
so 12 Mbps = 12/8 MBps => 1.5 MBps

So with this ISP connection we can download a 6 MB file in 4 seconds!

So here the maximum bandwidth available to machines must be 4 Mbps only! (4Mbps ~ 0.5 MBps ~ 512 KBps)

delay_pools 1
delay_class 1 1
delay_parameters 1 524288/1048576

524288 => 524288/1024 KB => 512 KB => 512/1024 MB => 0.5 MB => 0.5*8 => 4Mb

1048576 => 1048576/1024 KB => 1024 KB => 1 MB

Initially the bucket will be full (1 MB traffic). Now a client makes a request to download a 5 MB file.
It will get the maximum speed(12 Mbps) until it downloads 1 MB, but after that it gets only 0.5 MBps
For 1 MB, it takes 1 second as full bucket is available at first. As the bucket drains, it fills at the rate of 0.5 MBps only.
So 0.5 MBps will only be available after 1 MB has been downloaded!
So the file will get downloaded in 9 seconds. (This is all in theory :P)

There another TAG associated with delay_pools.
delay_initial_bucket_level => this parametes expects a value in percentage(%)
This parameter specifies how much bandwidth is put in each bucket when squid service starts.
By default, the value will be 50%, which means that in the previous example, the client will
download at full speed till the download reaches 0.5 MB

eg:

acl throttled src 10.0.0.1-10.0.0.50
delay_pools 1
delay_class 1 1
delay_parameters 1 524288/1048576
delay_access 1 allow throttled

Note: delay_access is very similar to http_access. It determines which delay pool a request falls into!

Hope this was useful for you!

No comments: