[squid-users] Traffic prioritizing

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/01/2015 3:44 a.m., Dr. Lars Hanke wrote:
> Hi Eliezer:
> 
>> There are couple aspects to the issue. The options are: - TOS
>> marking of specific connections - TPROXY(leaving the src IP the
>> same) - delay_pools
>> 
>> If you have a shaping setup in place or device that is capable
>> of traffic shaping based on TOS marking you can take a look at
>> this option.
> 
> TOS marking essentially will mark the GET/POST requests, right?
> However, the size/number of these requests does not correlate well
> with the download bandwidth. 100 AJAX requests may be much less
> than a single GET for some PDF.

The TOS marking is *set* when the request starts. But it remains in
use until the transaction finishes and the next begins. QoS policy
should be able to do things like associate incoming packets on the
connection to the assigned flow.

> 
> Setting up a TPROXY configuration might be interesting, since my
> current transparent proxy appears to have issues with some special
> devices.
> 
> However, it all boils down to limit the outgoing bandwidth. Of
> course I could police incoming packets, but when they arrive the
> bandwidth is wasted already. If dropped, the server will resend and
> eat my bandwidth again.
> 
> So my idea was that Squid should have all data required about
> streams any may be the most suitable instance to take action, e.g.
> delay ACK and new requests. delay_pools in general look like the
> right choice, but I could not see a function similar to HTB or
> HFSC, which both would do the trick.

Squid knows only what is at the HTTP level and some IP:port etc
details that TCP provides. All of the overheads are unknown to Squid.

The delay pools in Squid are a mix of both HTB and HFSC. The
delay_pool_access directive does HFSC-like selection of what pool to
apply each transaction to. Then the pool bandwidth is managed with HTB
algorithm using delay_parameters and a fixed 1 second refresh cycle,
and applied only to the HTTP reply messages. Thus only a *speed*
limiter, they slow download traffic but do not quota control it nor
account for uploads.

> 
> So it could be that I think too complicated, or that I miss
> something, or that there is simply no solution, yet.
> 
> If the latter is true, I'll try experimenting with the TOS
> solution. Joined with outgoing ACK throtteling it might work.
> 

I realy do think that is better, as it manages both request and reply
packets. More importantly its applied to the actual *packets* instead
of just the reply/download payload segments.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUt6xCAAoJELJo5wb/XPRj10QH/i4oc83HAvtx2/r3zVlU5TW5
Pjh9T5hmiZnVh+wyfYFpJplyi5n1u0MrW12WyUOltDo/Wfyn4Ae/ZaqV9tG50uaY
VPaQCGTpHhXvWS51tc9CUWlmfzkBGbqgQo8Re3gLpi++GjrgCyts4m0hzu/7/mhA
frv0UEY7/3+JEe7jevWJ5w25VRORPvfaVWRwDYNtuKWTZZFxRA8qt0EQWc9cYuSS
inSgOFvxvVvNOc1RKPmeud2RSFt/zGPoUZtzCSFDNabCLKYuzK33v60nd4EgX4cm
3/WXYlJhUjXvNCThNZjZca2eTrPT3lbBWTd265j9pi43AosBf9Cnrw+vHwB2iSw=
=FuaY
-----END PGP SIGNATURE-----