Delay Pools

Dear all,

Using Squid 2.0, we want to apply delay pools since we don't have a high-bw
link.
> We have a group C subnet: 194.30.234.xxx.
>
> Aggregate pool (class1) works OK and straightforward for one host, a group
> of hosts or the whole network.
> But, what we need is to define some groups of IP addresses that will match
> the users we want to categorize and assign different burstiness and of
> course rate. I have completely understood the concept of the pools.
> What I miss is how to define the different groups with ACL and how Squid
> will recognise them.
> I made an attempt with two groups in delay_class2 but it failed. Even only
> one group failed in delay_class2.
> This is what I put in squid.conf:
>
> acl etsiot_host src xxx.xx.xxx.200-xxx.xx.xxx.210/255.255.255.255
> delay_class2_access allow etsiot_host
> delay_class2_aggregate_max 25000 (to be able to handle bursts)
> delay_class2_individual_max 5000 -//-
> delay_class2_aggregate_restore 100
> delay_class2_individual_restore 500
>
> This didn't work. I also gave it a try with also defining a class 1 pool
> for the same acl (class1+class2 with acl etsiot_host). In this case it
> used the class 1 settings and ignored the class 2.
> One observation: In the cachemgr, for class 2 settings the current value
> remains blank.
>
> Could you provide an example of how to define two different groups of IP
> hosts with different settings?
> Additionally, since we have two caches, can you help on how to define a
> peer host (the other cache in each case), that should not get affected by
> delay pools?
>
> Many thanks,
> Evaghelos.
>
>
>
> CacheMgr output:
>
> Class 1 Delay Pool Statistics:
> Aggregate: Max: 50000
> Rate: 1000
> Current: 20000
> Class 2 Delay Pool Statistics:
> Aggregate: Disabled.
> Individual: Max: 5000
> Rate: 500
> Current:
>
>
>
>
>
> -----Original Message-----
> From: David Luyer [SMTP:luyer@ucs.uwa.edu.au]
> Sent: Monday, August 31, 1998 11:14 AM
> To: Jordan Mendelson
> Cc: squid-users@ircache.net
> Subject: 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 Oct 19 1998 - 05:47:28 MDT