Re: [squid-users] Squid delay pool question

mikewest09 wrote:
> Hi All,
>
> Thanks Amos and Chris for your time and help, I have few more questions so I
> will appreciate it so much if you can please take a look at them
>
> A. As a start to avoid confusion here are some facts regarding our server
> and users
> - All of our users connect to our proxy (SQUID) through an application. This
> desktop application contains built-in (User name / password) for
> authenticating each of our users to use our SQUID proxy (installed on our
> server) AND also contains the IP of our server (which have SQUId installed
> on it)
>
> - Our users come from many different locations around the world and many of
> them (most of them actually) don't have 'static Ip's so I can't setup
> specific range of IP's
>
> - We have more than 100,000 registered users (beside those whom will
> register in the future) from different locations around the world. Of course
> not all of them will login together at a specific moment, but many of them
> can be on the server at the same moment and this was one of the major
> reasons why we need to regulate SQUID traffic usage
>
> B. Even though I have read info about classes 1,2,3,4 I can't understand up
> to this moment which will be better for us? So based on the info I just
> provided in A, do you have any recommendations especially when taking in
> consideration the amount of users we have

Depends on what you consider the most stable detail. username or IP.

Given that you said most users are on dynamic IPs I'd go with username.
class 4. With all fields except the user one set to -1/-1

>
> C. delay_parameters 1 -1/-1 1310720/15728640

>>>> isn't -1/-1 is for unlimited access? i mean can you please explain this
>>>> rule so I can understand its limitations?

"unlimited" here means only "unlimited by Squid" the external network
settings still apply.

If you think of it like a geographic hierarchy it makes more sense.

  class 1: for limiting the entire network HTTP bandwidth.

  class 2: for limiting individual machines
                + maybe entire network.

  class 3: for limiting individual machines
                + subgroups of machines
                + maybe entire network.

  class 4: for limiting on login usernames
                + maybe individual machines
                + maybe subgroups of machines
                + maybe entire network.

  class 5: for advanced custom controls.

Lets take a small office LAN as the theoretical situation:

  With class 1 the office can have a 10Mbps pipe and a policy of
allowing only 2Mbps for web browsing traffic "aggregate" (8Mbps
dedicated to the phones or external services etc).

Effects: any single office PC can reach 2Mbps alone, or four can each
simultaneously do 256Kbps. The 2Mbps is parceled equally between all.

With class 2 they can take their 2Mbps traffic policy "aggregate" and
add a condition that no one office machine can use more than 256Kbps at
once "individual".

Effects: running 3 or less PC at once will leave some hundreds of Kbpps
"wasted" empty, even as each PC can runs at their peak 256Kbps. Five or
more PCs will start to degrade each others experience as the 2Mbps is
parceled equally between all at 200Kbps each.

With class 3 they can have two offices next to each other who are
allowed 1Mbps each. So one machine in office A can use 1Mbps by itself
"individual" while two others in office B are at 500Kbps sharing the
other 1Mbps "network". The total bandwidth stays within the overall pipe
limit "aggregate".

For you with class 2 I set non-individual caps as unlimited. Which means
that Squid trusts the underlying network to get the pipe limits and
sharing right. Squid will try to use as much bandwidth as needed to
supply the current clients.

Looks liek class 4 might be better for you, in which case the aggregate,
network, and individual fields would be unlimited and only the username
one set to the 10Mbps/15MB values.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.15