From: Andrew Beverley <andy@andybev.com>
To: "Grégoire Leroy" <gregoire.leroy@hyperthese.net>
Cc: Antoine Souques <corum@via.ecp.fr>,
Julien Vehent <julien@linuxwall.info>,
netfilter@vger.kernel.org, Amos Jeffries <squid3@treenet.co.nz>
Subject: Re: Fair queuing with htb
Date: Sat, 25 Dec 2010 22:46:42 +0000 [thread overview]
Message-ID: <1293317202.1617.5.camel@andybev> (raw)
In-Reply-To: <201012250452.01340.gregoire.leroy@hyperthese.net>
On Sat, 2010-12-25 at 04:51 +0100, Grégoire Leroy wrote:
> Le Saturday 25 December 2010 03:35:12, Antoine Souques a écrit :
> > > I've attached a graph which explains what are the marked packets.
> >
> > Your design is wrong. You mark the upload traffic, when the main http
> > traffic is the download traffic. That is why your QoS seems ineffective
>
> In this case I have probably misunderstood the goal of the tcp_outgoing_mark
> squid directive. Andrew, in what purpose is it developped ?
>
tcp_outgoing_mark will mark packets going from squid to the webserver.
If you want to mark packets going from squid to your client then you
need to use clientside_mark instead.
> >
> > > The general goal is to do a QoS based on user ip. If I had no proxy, it
> > > would be easy. However, since I've a proxy, my firewall sees the proxy
> > > ip, not the users IP.
> >
> > Where is your firewall ? Between the proxy and the webserver, or the
> > otherside ?
> >
>
> Yes it is
>
> > In the first case, you can only mark the upload traffic (it's to late
> > for the download traffic). You should use the conntrack module to mark a
> > connection, and so, you will be able to mark the download traffic
>
> I thank it was the goal of the tcp_outgoing_mark squid directive (authored by
> Andrew).
>
If you're going to mark packets on the other side of Squid, then you'll
probably need to move the interface that your HTB qdisc is attached to.
> > Moreover, I don't understand why you don't have access to your user
> > addresses. You use mark, so your firewall and your proxy are running on
> > the same box. So, when the download traffic leaves your proxy/firewall,
> > the destination adsress is the user address. tc is called when a packet
> > is send to the network, or when a packet arrive. So you can do IP based
> > QoS.
>
> The problem is if I limit the traffic between the proxy and users, then he
> won't any difference between the data downloaded from internet and the data
> which was in cache in squid.
>
> I want to limit the rate only for non-cached data, so it seems relevant to
> apply QoS between proxy server and internet.
>
In which case you want qos_flows, as Amos has already pointed out.
Andy
next prev parent reply other threads:[~2010-12-25 22:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-23 1:26 Fair queuing with htb Grégoire Leroy
2010-12-23 6:01 ` Julien Vehent
2010-12-23 12:30 ` Grégoire Leroy
2010-12-25 0:09 ` Andrew Beverley
2010-12-25 1:08 ` Grégoire Leroy
2010-12-25 2:41 ` Antoine Souques
[not found] ` <4D155860.6090507@via.ecp.fr>
2010-12-25 3:51 ` Grégoire Leroy
2010-12-25 12:29 ` Amos Jeffries
2010-12-25 20:40 ` Grégoire Leroy
2010-12-25 22:46 ` Andrew Beverley [this message]
2011-01-10 11:55 ` Grégoire Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1293317202.1617.5.camel@andybev \
--to=andy@andybev.com \
--cc=corum@via.ecp.fr \
--cc=gregoire.leroy@hyperthese.net \
--cc=julien@linuxwall.info \
--cc=netfilter@vger.kernel.org \
--cc=squid3@treenet.co.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox