Re: Delay Pools

> How to limit Squid's total bandwidth to 512 Kbps

# should already be defined
acl all src 0.0.0.0/0.0.0.0
delay_class1_access all
delay_class1_aggregate_max 64000 # 1 second "buffer" of 64kbytes
delay_class1_aggregate_restore 64000 # 512 kbits == 64 kbytes per second

The 1 second buffer is because you have implied you just want a limit, and
don't want it to be able to respond to a burst. If you want it to be able
to respond to a burst, increase the aggregate_max to a larger value, and
traffic bursts will be handled.

> How to limit a single connection to 128 Kbps

I assume by connection you mean client host. Define an acl for the client
host you wish to restrict and do as above.

Or if you want to restrict such that any client host can only do 128kbps,
then you come into using the class2 and class3 delay access. I have tried
to document them well in squid.conf, I hope you can understand what it is
saying there.

> I am assuming this is what delay pools is for. If there is something else
> which they can be used for, please give an example (and add it to the FAQ :)

Well the idea came from a WA university who wanted to restrict student traffic
costs (without affecting staff traffic, and still getting cache and local
peering hits at full speed). There was some early-squid-1.0 code by the
central network services at Murdoch University (Western Australia), which
I then developed (at the University of Western Australia) into a much more
complex patch for squid-1.0 called "DELAY_HACK". I then tried to code it
in a much cleaner style and with slightly more generic options than I
personally needed, and called this "DELAY_POOLS".

It allows you to limit traffic per client, with various features;
  * can specify peer hosts which aren't affected by delay pools, ie, local
    peering
  * delay behaviour is selected by ACLs (low and high priority traffic,
    staff vs students or student vs authenticated student or so on, or
    simply modem users get a 56kbps maximum pulled down for them at any
    time)
  * each class of users has a number of "pools", a pool has an amount
    coming into it in a second and a maximum amount it can grow to. when
    it reaches zero, objects reads are deferred until one of the object's
    clients has some traffic allowance.
  * class 1 - contains a single unified pool
  * class 2 - contains one unified pool and 254 pools for each host on an
              8-bit network (IPv4 class c).
  * class 3 - contains 254 pools for subnets in a 16-bit network, and
              individual pools for most mosts on these networks (network
              255 and hosts 0 and 255 are not permitted) (IPv4 class b).
  * each set of pools can be configured individually or disabled, eg,
    you might only want to use the aggregate and per-host pool of class 3,
    and not the per-network one.

There has been very little testing done on the 1.2beta24 DELAY_POOLS.
DELAY_HACK w/1.1.15 is much more tested, however contains a few known
caveats which are fixed by the 1.2beta24 code and is much less generic.

The place where I use this patch runs a modified 1.1.15-based cache
and will do so for quite some time. I would like to hear of people using
the 1.2beta24 DELAY_POOLS (I got a significant number of requests so I
decided to do the patch, but I don't know how many of those people are
actually using it now) who can verify it behaves as intended.

David.
Received on Mon Aug 31 1998 - 01:14:43 MDT