From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] htb/iptables: incoming vs. outgoing shaping?
Date: Sat, 07 Sep 2002 09:32:02 +0000 [thread overview]
Message-ID: <marc-lartc-103139125718486@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103136560008157@msgid-missing>
> But does this really work? I also notices somewhere that you just can shape
> input traffic, and for output you need a special IMQ target for iptables,
> why? And why doesn't it work in that way?
it' the other way around. You can only shape outgoing traffic. You shape
traffic by influencing the queue where the packets wait to be sended. For
incoming packets, there is no queue, so you can't shape incoming traffic.
But, there is a IMQ device. You can put all incoming packets in this virtual
device and this device has a queue. So you can shape incoming traffic. But
this can/will introduce extra delays. There is also a ingress qdisc. This
qdisc contains no queue, but you can attach filter to it. And you can use
policers on this filter. A policer is sort of shaper on a filter : it will
only match the packets at a certain rate. So you can match packets at a
certain rate and throttle incoming traffic. Howerver, this is a one-level
setup so you can't create a hierarchical setup like you can with htb/cbq.
You never provided a ceil parameter when you created the classes. So the
class will never borrow unused bandwidth from each other.
And to be able to shape the traffic, you have to shape at 250 kbit or so. So
YOU are the bottleneck and not your router/modem. You will loose some
bandwidth, but you will be able the shape it. So if shaping is not working,
try to lower the total bandwidth you send/receive.
I suggest reading some docs : lartc.org in general and I have some more info
about shaping on docum.org.
> Furthermore, is this right how I mark the outgoing traffic? should this be
> done in POSTROUTING, or even somewhere else? It's that we've
> PREROUTING,INPUT, FORWARD,OUTPUT and POSTROUTING have in table mangle.
It depends if the traffic is generated locally or forwarded.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2002-09-07 9:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-07 2:25 [LARTC] htb/iptables: incoming vs. outgoing shaping? Christian Parpart
2002-09-07 9:32 ` Stef Coene [this message]
2002-09-11 13:43 ` George J. Jahchan
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=marc-lartc-103139125718486@msgid-missing \
--to=stef.coene@docum.org \
--cc=lartc@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.