[squid-users] Delay Pools or Traffic Shaping per port?!

[Amos Jeffries]

On 4/01/2016 9:42 a.m., Christian Kunkel wrote:
> 
>>>> How many users do you have?
>>>
>>> i wanted to put about 200-500 users on a server. is that possible?
>>
>> Certainly no problem for Squid, and I guess you could assign that number of 
>> separate listening ports for use one per user, but I'll let someone who knows 
>> more about Squid's internals for such an unusual setup comment on that if 
>> needed.
> 
> ok.

Squid is limited to 64 listening ports. That can be extended a little in
exchange for reducing Squid operating speed, but 200-500 is going very
far. This will cause problems with your stated goal of handling Gbps,
Squid will need some fine tuning to get near that speed as it is.

>>
>>>> - are you trying to limit the *inbound* bandwidth to Squid per user, or
>>>> the *outbound* bandwidth from Squid to each user?
>>>
>>> i want to limit the bandwidth. lets say user has 50mbit but i want him only
>>> to use 10mbit.
>>
>> So, that's the outbound bandwidth from Squid to the user, then?  You don't 
>> mind if Squid fetches the requested content faster than that if it can, and 
>> then feeds it to the user no faster than 10Mbps?
> 
> yep. that can work this way.
>>
>> Is this limit true for all users - ie: is there a single bandwidth limit you 
>> want to apply to all users, or are you trying to set different limits for 
>> different users?
> 
> only one limit for every user.
>>
>>>> - what's the primary reason for wanting to restrict the bandwidth per
>>>> user?
>>>
>>> server has not unlimited speed. better control of the server bandwidth.
>>
>> What total bandwidth are you dealing with?
> 1gbit/s (but i guess its a bit less than that. maybe it will peak at 500mbit)
>> What's the server load when it runs into problems?
> have not tested it so far with so many users.
>> How many concurrent user sessions do you have when the problems occur?
> no problems right. cause not enough load.
>> What are the effects of the problems you're having?
>>
>> Is there any reason you can't use authentication to identify different users?
> it does not work with nated ips.

Authentication does.

> it autheticates with ip adress anyway.

That is *not* Authentication. That is IP based authorization (access
control).

> so it will limit the ip to 10mbit but behind that ip there are maybe 10 or more ppl.

With authentication each of these "ppl" has different credentials and
messages using those credentials are used to count the bandwidth shaping
towards each user.

If your system defines a "user" as being one IP address. Then the IP
address is what the traffic needs to be accounted against.

>>
>> What stops users "investigating" the system, and finding out they can get extra 
>> bandwidth by using ports which haven't been assigned to them?
> 
> thats the second problem to deal with. there is some kind of a captive portal with login but it opens the port after user autheticates so actually someone else can use that port. so if you have an idea. i would be really thankful :)
> 

FYI: the only thing that Squid can do that OS level QoS controls cannot
easily do is base its shaping on HTTP message header values (ie the
users proxy-auth credentials).

Since you want to do this shaping "per-user" without authentication
credentials to correctly identify what a single "user" actually is and
are instead basing the definition of "user" as stuff coming from an IP
address (that IP based authorization) - then OS level QoS controls
shaping the traffic based on IP address is the best you are going to
get. Despite the NAT related issues.

The captive portal device is the right place for the bandwidth shaping
to be enacted. It has access to both the original client IP and whatever
authentication details is uses.

Amos