[squid-dev] [PREVIEW] Response delay pools

[Eduard Bagdasaryan]

This new feature is useful for specific response(s) bandwidth limiting.
AFAIK, there are situations when doing this is hardly possible
(or impossible) by means of netfilter/iptables operating with
TCP/IP packets and IP addresses information for filtering. In other
words, sometimes it is problematic to 'extract' a single response from
TCP/IP data flow at system level. For example, a single Squid-to-client
TCP connection can transmit multiple responses (persistent connections,
pipelining or HTTP/2 connection multiplexing) or be encrypted
(HTTPS proxy mode).


HTH,
Eduard.


On 09.01.2017 09:33, Amos Jeffries wrote:
> On 24/12/2016 9:26 p.m., Eduard Bagdasaryan wrote:
>> Hello,
>>
>> This patch introduces a new "response_delay_pools" feature.
>> The feature restricts Squid-to-client bandwidth and applies to both
>> cache hits and misses.
>>
>> When Squid starts delivering the final HTTP response to a client, Squid
>> checks response_delay_pool_access rules (supporting fast ACLs only), in
>> the order they were declared. The first rule with a matching ACL wins.
>> If (and only if) an "allow" rule won, Squid assigns the response to the
>> corresponding named delay pool.
>>
>> If a response is assigned to a delay pool, the response becomes subject
>> to the configured bucket and aggregate bandwidth limits of that pool,
>> similar to the current "class 2" server-side delay pools, but with a
>> brand new, dedicated "individual" filled bucket assigned to the
>> matched response.
>>
>> The new feature serves the same purpose as the existing client-side
>> pools: both features limit Squid-to-client bandwidth. Their common
>> interface was placed into a new base BandwidthBucket class.  The
>> difference is that client-side pools do not aggregate clients and always
>> use one bucket per client IP. It is possible that a response becomes a
>> subject of both these pools. In such situations only matched response
>> delay pool will be used for Squid-to-client speed limiting.
>>
>> The accurate SMP support (with the aggregate bucket shared among
>> workers) is outside this patch scope. In SMP configurations,
>> Squid should automatically divide the aggregate_speed_limit and
>> max_aggregate_size values among the configured number of Squid
>> workers.
>>
>> I have not synced with last v5 yet: this patch applies to v4 r14793.
>> To speed up the process and initiate the discussion I am posting with
>> "preview" flag and meanwhile start merging with the current v5 version.
>>
> Thanks. Sorry I didn't get a chance to look at it yet. That should now
> happen in the next few days.
>
> Can you please add to the above an explanation of why this is being
> added instead of improving ways to send TOS/NFMARK to feed the system
> QoS bandwidth controls. We really should not be re-inventing QoS in
> Squid (for about the third time AFAICT).
>
> Amos
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev