On 2016-11-15 22:31, AUBERT Thibaud wrote:
Hi Guys, Ok, QoS might help to control traffic on the internet access side, but it won't help between the source, client on a small remote office/output, and the proxy. It might also be difficult to split this traffic between what is intended to internet or just internal. Example : 1Gb/sec internet link used at 50%, a user on a remote site with a 15 mbits/sec link used at 80% launch a download. There's pretty much no impact on the internet link... but on the second, it add an extra 3mbits/sec that saturate the network. If I add a restriction with a small value for the max size of file, I can hope that user won't bother others people on site too long. But it also mean that every people that use the internet link won't be able to download big file, even if they normally could. I also think to use Delay Pool, but, it will penalize people that do not download big files. If anyone have some XP about individual delay pool, don't hesitate to share, because I'm not sure that it will fit my current needs.
As Amos already wrote, the only viable solution for your case are configured QoS policies on the routers facing limited links to branches. You can't control downstream traffic to branches on HTTP(S) proxy servers alone. I believe many other network protocols (FTP/Bittorrent/POP3/IMAP ...) are used on the limited links to branches.
If Squid generates most of the traffic passing through the slow links, you also has an option to apply QoS policies on operating system level. For example, if Squid is installed on Linux, you can use very flexible HTB queuing discipline [1]. Below is excerpt describing link sharing scenario:
HTB ensures that the amount of service provided to each class is at least the minimum of the amount it requests and the amount assigned to it. When a class requests less than the amount assigned, the remaining (excess) bandwidth is distributed to other classes which request service. Similar methods can be uses for other operating systems. [1] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Garri _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
