Limiting Bandwidth with Squid (Delay Pools)

Practice

Limiting internet channel bandwidth for different users or computers is not a new topic and has been discussed to death. One of the most common approaches is to use the traffic shaping or rate-limiting capabilities built into the kernel firewalls IPFW or IPTABLES.

Although using a firewall for this task is probably one of the most popular approaches, other solutions exist as well. For example, if you have the Squid caching proxy server installed, you can use it instead.

Why bother with Squid? For instance, you may not be particularly comfortable with IPTABLES or IPFW (for Linux and FreeBSD respectively), you don't want to risk a gateway that's located far away from you (accidentally breaking the firewall config and, as a result, losing the ability to manage it), or you want to tie the bandwidth limit to the logged-in user (for example, when Squid works with authentication for connecting users, and people with different speed-limit rules can access the internet from the same machine).

Note. You should also keep in mind the flip side of the coin - Squid can only control traffic speed for HTTP/S. Everything else that isn't routed through the proxy server will pass through at full speed, or as set by the firewall.

To limit channel speed in Squid, a technology called Delay pools is used. However, by default Squid is built without it, and you will probably need to rebuild the proxy server to enable this option.

Enabling delay-pools

For FreeBSD:

Here I'll assume you have Squid 3.1. For 3.0, use the path "../squid30"

$ cd /usr/ports/www/squid31
$ make config

If the checkbox next to "SQUID_DELAY_POOLS" is not checked, it means the proxy server was built without support for this option. In that case, do the following (after exiting make config without saving):

$ sudo make deinstall
$ sudo make config
(enable SQUID_DELAY_POOLS)
$ sudo make reinstall

For Linux Debian/RHEL:

By default, the Squid installed via apt-get (or yum for RHEL) comes with delay pools support, so in this case there's nothing extra to do.

If you're building Squid from source, though, don't forget to pass the "--enable-delay-pools" flag to ./configure.

Configuring delay pools

To do this we need to open the Squid configuration file: squid.conf. On each OS it lives in its own location:

FreeBSD: /usr/local/etc/squid/squid.conf
Debian: /etc/squid/squid.conf
CentOS/RedHat: /etc/squid/squid.conf

So, let's open this file for editing.

Number of pools

First decide how many pools you're going to configure. For example, one pool for restricted users, one for regular users, and one for management (3 in total).

After that, add this option to the config file:

delay_pools 3

where instead of 3 you specify the number of pools.

Configuring each pool

Now let's define the parameters for each pool. Pools are identified by their number: 1, 2, 3...

First we'll set the pool classes. The thing is, Squid gives us several classes, each with different properties.

For example:

delay_class 1 1
delay_class 2 2
delay_class 3 2

here the first digit in the parameter is the pool number, and the second is the pool class.

Now we specify the ACL that this pool will apply to. We need to create the ACL beforehand using Squid's usual syntax, putting into it a set of subnets, hosts, or users.

For example:

# Management
delay_access 1 allow chiefs

# Regular users
delay_access 2 allow users

# Especially restricted users
delay_access 3 allow minusers

And we specify the parameters for each pool. For example:

# Pool 1 - unlimited speed
delay_parameters 1 -1/-1

# Pool 2 - the combined speed of all users is not limited, but each
# user cannot exceed 1024Kbit/s (128KB/s). Splitting the
# speed limits apart is made possible by class 2 (more on this below).
# In this case, the first 128KB of each connection will be downloaded without any limit
delay_parameters 2 -1/-1 128000/128000

# Pool 3 - total speed for all users - no more than 2048Kbit/s (256KByte/s),
# but each user cannot exceed 512Kbit/s (64KByte/s). Splitting
# the speed limits is made possible by class 2 (more on this below).
# In this case, the first 128KByte for each connection will be downloaded without any limit
delay_parameters 3 256000/128000 64000/128000

As you can see, the parameters are split into pairs. The first number in the pair is the speed limit in Bytes/second (not Bits!), and the second is "the first XX bytes that will be transferred to the user at maximum speed".

Instead of a specific number you can use -1, which means "ignore this parameter".

The number of parameters and their meaning depends on the pool class (more on classes below).

Let's walk through 3 examples, which, I hope, will make the behavior of the parameters a bit clearer:

a) 256000/128000 : Here we limit the speed to 256000 bytes/s (256KByte/s), and the first 128000 bytes (128KByte) of each request will be downloaded at maximum speed - i.e., without any limit.
b) 256000/-1 : Here we limit the speed to 256000 bytes/s (256KByte/s), starting right from the first byte of traffic.
c) -1/-1 : Here we're saying that no limits exist at all for this traffic.

As a result of the example written above, we will have the following:

1) Management browses without any limits;
2) Users are limited to a speed of 1Mbit/s each, with the first 128KByte downloaded at maximum speed;
3) Restricted users: each user is given a limit of 512Kbit/s, while all users combined are limited to a total speed of 2Mbit/s (i.e., together they cannot download faster than 2Mbit/s), and the first 128KByte for each connection will be downloaded without any speed limit.

Pool classes

Squid provides several pool classes that differ in their traffic-limiting capabilities. Let's take a look at them now.

Class 1

Limits the total speed for all hosts belonging to a given ACL. That is, it does not distinguish between individual users - it simply sums up the total bandwidth of all users from the specified ACL and limits all users equally depending on how much of the allocated bandwidth is being consumed.

delay_class 1 1
delay_access allow myacl
delay_parameters 512000/-1

in this example we limit all users from myacl to a combined total of 4Mbit/s (512KB/s).

Class 2

Limits the total speed for all hosts, but also allows limiting individual users separately. That is, "the ACL total is no faster than A, but each user is no faster than B".

delay_class 1 2
delay_access allow myacl
delay_parameters 512000/-1 128000/-1

in this example we limit all myacl users to a combined total of 4Mbit/s (512KB/s), but at the same time, even with a free channel, no individual user will get a speed above 1Mbit/s (128KB/s).

Second example:

acl myacl1 src 192.168.0.0/24
acl myacl2 src 192.168.1.0/24
delay_class 1 2
delay_access allow myacl1 myacl2
delay_parameters 512000/-1 128000/-1

here we limit the speed of myacl1 to a combined total of 4Mbit/s and myacl2 to a combined total of 4Mbit/s. That is, these two ACLs are not limited together as a sum - the rules are applied to each of them separately. Otherwise, everything is the same.

Class 3

Limits the total speed, the speed of each ACL, and of each host. That is, this is class 2 plus a combined limit on all ACLs included in the pool.

acl myacl1 src 192.168.0.0/24
acl myacl2 src 192.168.1.0/24
delay_class 1 3
delay_access allow myacl1 myacl2
delay_parameters 768000/-1 512000/-1 128000/-1

here we limit myacl1 to a speed of 4Mbit/s, myacl2 to a speed of 4Mbit/s, while each individual computer cannot consume more than 1Mbit/s even with a free channel. But on top of that, we also limit myacl1 and myacl2 combined to a speed of 6Mbit/s (that is, the speed of myacl1 + myacl2 cannot exceed a total of 6Mbit/s).

Thus, although we handed out 4Mbit/s to each ACL (which totals 8Mbit/s), we have shown that together they cannot exceed a speed of 6Mbit/s.

Class 4

In addition to class 3, this lets you split the speed for each logged-in user. That is, we can limit:

a) All ACLs
b) + Each ACL
c) + Each computer within each ACL
d) + Each authenticated user

For example:

acl myacl src 192.168.0.0/24
acl authacl proxy_auth user1 user2 user3
delay_class 1 4
delay_access allow myacl authacl
delay_parameters -1/-1 512000/-1 -1/-1 128000/-1

Here:

Total speed is not limited (-1/-1)
The speed for myacl and authacl is limited to 4Mbit/s each (total for all hosts within the ACL)
The speed for each individual computer is not limited
The speed for users user1, user2, and user3 (authacl) is limited to 1Mbit/s each. If the same login is used to log in from multiple computers, the speed is counted as the total across all computers where that user is logged in.

Conclusion

So, in a nutshell, as a quick reference, I've described how to use delay pools in Squid. By the way, there's also a fifth class that I haven't covered. Unfortunately, I don't have time to dig into it (it's even more convoluted and is based on external_acl's and requests grouped by tags).

I want to reiterate the main downside of this method — you can only limit users by HTTP/S traffic. Anything that bypasses Squid is not limited.