Re: [squid-users] Bandwith limit after reaching accumlated CAP

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 23 Jul 2014 17:06:33 +1200

On 23/07/2014 6:55 a.m., sebapiovano wrote:
> Hi
>
> Correct me if I wrong but I understand DELAY POOL is used to set bandwith
> limit when a current trafic is bigger than the parameter configured in the
> DELAY PARAMETER command.
>
> For instance if I'm downloading a 1MB file and the delay parameter is set to
> 10 KB, then the bandwith will be limited at that speed only until I finish
> with the download and then it will be reestablished the defult bandwith.

The delays from a pool should be applied to all traffic from the client
IP provided the transaction details match the delay_access rules for
that pool.

>
> What I need is to set a bandwith limit not only applied to a file but to all
> after reaching an accumulate threshold.
>
> I.e. I want to have 1MB of bandwith for all kind of traffic, and when I
> reach an trheshold of 1GB then limit the bandwith to 256K. This is similar
> to the Data Services offered by the mobile celular companies in their data
> plans.
>
> Is there any way to configure squid in that way? or is there any plug in I
> can use for?

Quota followed by bandwidth limiting? Squid was never designed for that.
Delay pools is straight bandwidth cap limiting. Quota control helpers
are quota-only basically.

You could code up a quota helper that monitors when the user and tag's
their requests once the quota is exceeded instead of denying them - then
delay pool based on the tag existence. You will still face problems that
users an run up large bandwidth usage at full speed before quote which
causes an excess.

However, operating system QoS tools offer *far* better and more reliable
traffic control than Squid delay pools or quota control ACLs.

Squid can be configured to provide TOS/DSCP/DiffServ (or on Linux
netfilter MARK) values for the operating sytem rules to utilize with the
tcp_outgoing_* or qos_flows directives.

Amos
Received on Wed Jul 23 2014 - 05:06:56 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 24 2014 - 12:00:05 MDT