From: "Vladimir B. Savkin" <master@sectorb.msk.ru>
To: jamal <hadi@cyberus.ca>
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [RFC/PATCH] IMQ port to 2.6
Date: Mon, 26 Jan 2004 16:55:45 +0300 [thread overview]
Message-ID: <20040126135545.GA19497@usr.lcm.msu.ru> (raw)
In-Reply-To: <1075124312.1732.292.camel@jzny.localdomain>
On Mon, Jan 26, 2004 at 08:38:33AM -0500, jamal wrote:
> On Mon, 2004-01-26 at 04:32, Vladimir B. Savkin wrote:
>
> > On Sun, Jan 25, 2004 at 10:09:48PM -0500, jamal wrote:
> [..]
> > > shape). I have not seen anything in favor of shaping; i could be wrong
> > > (so if you know of something or have experimented pass the data).
> >
> > Yes, I have experimented. Shaping works much better:
> > much less packets dropped, much better donwload rates for clients.
> >
>
> I cant say i doubt you, but your word alone is insufficient data ;->
You can see for youself. Police users' traffic to half of the normal rate
and here them scream :) Then change policing to shaping using wrr
(or htb class for each user), and sfq on the leafs, and users are happy.
> The important point is the eventual effective throughput and fairness
> amongst the flows. Whether it is induced by an increased RTT from
> shaping or a single packet retransmit on some misbehaving flows because
> of policing is less important. i.e it is not evil for packets to
> be dropped.
> When you analyse something like this you should look at the aggregate
> throughput instead of a single client with better downloads (probably at
> the expense of another poor client download).
Well, I use wrr + sfq exactly for fairness. No such thing can be
achieved with policing only.
>
> > I want to shape traffic that comes from upstream to clients connected
> > via PPTP.
>
> So if i understand correctly and was to draw this:
> you have clients on the left side coming in through ethx and that need
> to be tunneled to some pppoe/pptp before going out ethy on the right
> hand side. The right handside represents "upstream" in your terminology.
> Is this correct? I hate it when people ask me for a diagram for
> something that looks obvious;-> but bear with me and supply me with a
> diagram if i didnt understand you.
Here it is:
+---------+ +-ppp0- ... - client0
| +-eth1-<+-ppp1- ... - client1
Internet ----- eth0-+ router | . . . . . . . .
| +-eth2-< . . . . . .
+---------+ +-pppN- ... - clientN
Traffic flows from internet to clients.
The ethX names are for example only, my setup is more complex actually,
but that complexity is not related to IMQ or traffic shaping.
Clients use PPTP or PPPoE to connect to router.
See, there's no single interface I can attach qdisc to, if I want
to put all clients into the same qdisc.
>
> >
> > Here is a part of my scripts:
> >
> > DEVICE=imq0
> > /sbin/tc qidisc add dev $DEVICE root handle 10: htb r2q 1 default 100
> > /sbin/tc class add dev $DEVICE parent 10:0 classid 10:1 est 1sec 8sec htb \
> > rate 10Mbit burst 400k
> > /sbin/tc class add dev $DEVICE parent 10:1 classid 10:2 est 1sec 8sec htb \
> > rate 180kbps ceil 180kbps burst 3000
> > # default class for users
> > /sbin/tc class add dev $DEVICE parent 10:2 classid 10:101 est 1sec 8sec htb \
> > rate 20kbps burst 1k ceil 50kbps cburst 1k
> > /sbin/tc qdisc add dev $DEVICE parent 10:101 wrr \
> > dest ip 128 1 wmode1=1 wmode2=1
> > /sbin/tc filter add dev $DEVICE protocol ip parent 10:0 \
> > prio 100 handle 1 fw flowid 10:101
> > # more classes to follow ...
> >
>
> So why not have the above attached to ethy? Why does it have to be done
> at some other device?
>
> >
> > The limit 50kbps is artificial, so there's no bottleneck in
> > connection from upstream to this router. I cannot allocate all
> > the channel bandwidth to clients for some political reasons.
> > Then, I mark packets I want to go to this default user class with mark "1",
> > like this:
> >
> > iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \
> > -j IMQ --todev 0 # traffic from internet to clients
> > iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \
> > -j MARK --set-mark 1 # default class
>
>
> Why do you need the redirect to IMQ?
> If you can selectively mark packets here (or at any other netfilter
> hook) you could use the fwmark classifier to attach to different
> 10:x classes on the ethy interface. I feel i am missing something.
>
> > So, I shape traffic destined to clients, and I use "wrr" to
> > divide bandwidth fairly. I cannot attach qdisc to an egress device
> > because there's no single one, each client has its own ppp interface.
> >
>
> I mean the ethy interface not the ppp* interfaces. Mark the packets;
> use fwmark classifier.
>
> > Well, I could move this shaping upstream, but what if upstream router was
> > some dumb cisco with no "wrr" qdisc?
>
> You dont have to.
> Give me the diagram.
>
> cheers,
> jamal
>
~
:wq
With best regards,
Vladimir Savkin.
next prev parent reply other threads:[~2004-01-26 13:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-25 15:24 [RFC/PATCH] IMQ port to 2.6 Marcel Sebek
2004-01-25 16:44 ` Tomas Szepe
2004-01-25 19:22 ` jamal
2004-01-25 20:21 ` Vladimir B. Savkin
2004-01-25 23:45 ` jamal
2004-01-26 0:11 ` Vladimir B. Savkin
2004-01-26 3:09 ` jamal
2004-01-26 9:32 ` Vladimir B. Savkin
2004-01-26 13:38 ` jamal
2004-01-26 13:55 ` Vladimir B. Savkin [this message]
2004-01-26 14:29 ` jamal
2004-01-26 17:41 ` Vladimir B. Savkin
2004-01-27 3:25 ` jamal
2004-01-31 18:52 ` Vladimir B. Savkin
2004-01-31 20:26 ` jamal
2004-01-31 20:53 ` Vladimir B. Savkin
2004-01-31 21:25 ` jamal
2004-01-31 21:32 ` Vladimir B. Savkin
2004-01-31 21:49 ` jamal
2004-01-31 21:58 ` Vladimir B. Savkin
2004-01-31 22:26 ` jamal
2004-04-11 19:32 ` (Long) ANNOUNCE: IMQ replacement WAS(Re: " jamal
2004-01-26 15:24 ` Tomas Szepe
2004-01-27 3:14 ` jamal
2004-01-27 11:59 ` Tomas Szepe
2004-01-31 17:02 ` jamal
2004-01-25 19:25 ` David S. Miller
2004-01-25 20:23 ` Patrick McHardy
2004-01-25 21:55 ` David S. Miller
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=20040126135545.GA19497@usr.lcm.msu.ru \
--to=master@sectorb.msk.ru \
--cc=hadi@cyberus.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
/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;
as well as URLs for NNTP newsgroup(s).