Re: [squid-users] delay pools status

On 22/03/2014 4:31 a.m., Beto Moreno wrote:
> Hi, thanks Amos for always share your knowledge.
>
> "No there is 500KB/sec allocated to client response (download) traffic on
> "first-come basis.
>
> "This is effectively the same configuration as kernel routing QoS
> "controls allowing the Squid process to access 500KB/s of traffic inbound
> "for servers and unlimited upload traffic to servers.
>
> Here squid decide what we can share to each connection, the first
> machine get full bucket, if other machine arrive squid decide what he
> can receive from the bucket and continue the same to others users?
> Until they eat all the bucket and fill again the bucket to share?

There is two things here:
 1) the delay pool bucket size
 2) the I/O buffer free space

500KB is larger than the maximum buffer size. The delay pool bucket gets
more data only once every second.

So what happens is with only one machine, the client buffer gets to fill
its buffer several times over several reads until 500KB pool bucket is
empty.
The next second there are two machines, and each gets to fill its buffer
in turn until the delay pool bucket is empty.

Problem: So long as the delay pool is larger than the client buffer size
there will be some (unbalanced) sharing of the buffer. If the client
buffer is smaller than the delay pool you may see unpredictable
situations where one client gets all the traffic for a few seconds then
switches to another. With many clients some may get all the bandwidth
and others none at all.
 This pool type relies heavily on clients having traditional browser
behaviour. Whee a page was donloaded once then some time later another
page, etc. With big gaps of no traffic by each client.

>
> example 2:
>
> delay_pool_count 1
> delay_class 1 3
> delay_parameters 1 500000/562500 -1/-1 4000/4000
> delay_initial_bucket_level 100
>
> Start will full bucket, here we have one bucket of 500kb/s burst
> 562kb/s for all my clients but each on my clients will get <=
> 32kb/s(max 32kb/s) from their single bucket?

Remembering the sequence of sharing above. With this class-3 pool type
each client is only allowed to read up to 4000 bytes from the shared
pool when it fills its buffer. With a maximum of 4000 bytes total each
second if it tries to read a few bytes several times.
 The total traffic by all clients gets to 500000 Bytes in one second
then reads are stopped until the global pool bucket refills. ie if 125
clients all read their 4000 bytes each in one second the 126th client is
not permitted to read.

This mostly resolves the balancing problem described above. Relating to
QoS this pool is effectively the same as QoS controls on the
client->Squid connections controlling how much traffic got delivered to
each client by Squid (downloads by client).
 But still pools is slightly worse than proper QoS as it does not cover
requests/uploads, TCP packet overheads, and large response headers can
cause buckets to go negative.

>
> About the QoS, is what I'm trying to manage, but I had been testing
> squid delay-pools and they help in some manner controlling users
> appetite.

Yes. Any type of control helps in some manner. Squid delay pools are
just old technology with some strange limits (like not covering uploads
or TCP overheads). They do not work as well as newer QoS technology
which had more knowledge and experience behind the design.

>
> QoS trying to see how to integrate with squid, because once squid
> start controlling inbound is came of difficult to me because 80/443
> are only seen by single client(squid), QoS won't see my lan
> connections to those ports which are who eat my bandwidth, but working
> on.

qos_flows directive in squid.conf can tag traffic by type so you can
control HIT/MISS with different rules if you want on the client<->squid
connections.

tcp_outgoing_tos / tcp_outgoing_mark directives tag traffic on the
squid<->server connections according to ACL matches.

As I understand it you setup QoS rules based on MARK or TOS to do the
bandwidth allocation you would be doing with delay pools class and
parameters directives. Then you setup squid.conf to tag the traffic into
the QoS pool types the same as you would have done with delay_pool_access.

Amos
Received on Sat Mar 22 2014 - 02:38:47 MDT