I''m trying to set up a traffic control on ingress attaching a egress qdisc to the ifb device. The idea is to use a RED algorithm instead of policing the incoming traffic. After trying with tc-red and not obtaining the expected results, I decided to try with something easier, and use htb as bottleneck: ifconfig ifb0 up tc qdisc del dev $dev ingress tc qdisc del dev ifb0 root tc qdisc add dev $dev ingress tc filter add dev $dev parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:\ action mirred egress redirect dev ifb0 (1) tc qdisc add dev ifb0 root handle 1: htb default 1 (2) tc class add dev ifb0 parent 1: classid 1:1 htb burst 0 rate 112kbit Now I generate some traffic: $ scp user@host1:~/reallylargefile . reallylargefile 0% 64KB 12.4KB/s 7:52:29 and I get the expected results, if instead of htb I use something like RED, changing lines (1) and (2) with tc qdisc add dev ifb0 root handle 1: red limit 256000 min 1 max 32000 avpkt 1 burst 1 probability 0.8 bandwidth 512 I don''s see any dropped packets at all. (I know that the values of min, avpkt and burst are extremely low, and that probability is extremely high, but I just tweakeed them hopping to see dropped packets) Did I completely misunderstod the how red works? Thank you.
Hi
i think the problem is red only works when there is congestion
(queue),but the only limit on ingress is speed of kernel (no limit). RED
is not for and cannot limit traffic rate. That is why it wouldn''t work
here, unless combined with something to shape the traffic rate. (tbf or
htb here)
What you might want to do is to shape traffic with htb as you did, and
use red inside htb, not to do tail-drop.
Tbf would be easier for shaping, but i don''t know if combining tbf and
red is possibe. (probably not)
from man tc-red:
bandwidth
This rate is used for calculating the average queue size after
some idle time. Should be set to the bandwidth of your interface.
Does not mean that RED will shape for you! Optional.
Ruben Porras wrote:> I''m trying to set up a traffic control on ingress attaching a
egress qdisc to
> the ifb device. The idea is to use a RED algorithm instead of policing
> the incoming traffic. After trying with tc-red and not obtaining the
> expected results, I decided to try with something easier, and use htb
> as bottleneck:
>
> ifconfig ifb0 up
> tc qdisc del dev $dev ingress
> tc qdisc del dev ifb0 root
>
> tc qdisc add dev $dev ingress
> tc filter add dev $dev parent ffff: protocol ip prio 10 u32 \
> match u32 0 0 flowid 1:\
> action mirred egress redirect dev ifb0
>
>
> (1) tc qdisc add dev ifb0 root handle 1: htb default 1
> (2) tc class add dev ifb0 parent 1: classid 1:1 htb burst 0 rate 112kbit
>
> Now I generate some traffic:
>
> $ scp user@host1:~/reallylargefile .
> reallylargefile 0% 64KB 12.4KB/s 7:52:29
>
> and I get the expected results, if instead of htb I use something like
> RED, changing lines (1) and (2) with
>
> tc qdisc add dev ifb0 root handle 1: red limit 256000 min 1 max 32000
> avpkt 1 burst 1 probability 0.8 bandwidth 512
>
> I don''s see any dropped packets at all. (I know that the values of
min,
> avpkt and burst are extremely low, and that probability is extremely
> high, but I just tweakeed them hopping to see dropped packets)
>
> Did I completely misunderstod the how red works?
>
> Thank you.
i am a newbie here, so if i am completely wrong, then i am sorry.
_____________
Best regards
John Default
On Wed, Mar 28, 2007 at 06:24:10PM +0200, John Default wrote:> Hi > i think the problem is red only works when there is congestion > (queue),but the only limit on ingress is speed of kernel (no limit).I thought also about that, I''ve should have not been discarted the idea so fast.> RED > is not for and cannot limit traffic rate. That is why it wouldn''t work > here, unless combined with something to shape the traffic rate. (tbf or > htb here) > What you might want to do is to shape traffic with htb as you did, and > use red inside htb, not to do tail-drop.That works, I need to look a little if it works as I wanted, but at list I see dropped packets in the red qeue :) Thanks
Ruben Porras wrote:> I''m trying to set up a traffic control on ingress attaching a egress qdisc to > the ifb device. The idea is to use a RED algorithm instead of policing > the incoming traffic. After trying with tc-red and not obtaining the > expected results, I decided to try with something easier, and use htb > as bottleneck: > > ifconfig ifb0 up > tc qdisc del dev $dev ingress > tc qdisc del dev ifb0 root > > tc qdisc add dev $dev ingress > tc filter add dev $dev parent ffff: protocol ip prio 10 u32 \ > match u32 0 0 flowid 1:\ > action mirred egress redirect dev ifb0 > > > (1) tc qdisc add dev ifb0 root handle 1: htb default 1 > (2) tc class add dev ifb0 parent 1: classid 1:1 htb burst 0 rate 112kbit > > Now I generate some traffic: > > $ scp user@host1:~/reallylargefile . > reallylargefile 0% 64KB 12.4KB/s 7:52:29 > > and I get the expected results, if instead of htb I use something like > RED, changing lines (1) and (2) with > > tc qdisc add dev ifb0 root handle 1: red limit 256000 min 1 max 32000 > avpkt 1 burst 1 probability 0.8 bandwidth 512 > > I don''s see any dropped packets at all. (I know that the values of min, > avpkt and burst are extremely low, and that probability is extremely > high, but I just tweakeed them hopping to see dropped packets) > > Did I completely misunderstod the how red works?The bandwidh param of red doesn''t make it rate limit to that, so you still need to use htb to create the bottleneck and have red as a child of an htb class. Andy.
John Default wrote:> Hi > i think the problem is red only works when there is congestion > (queue),but the only limit on ingress is speed of kernel (no limit). RED > is not for and cannot limit traffic rate. That is why it wouldn''t work > here, unless combined with something to shape the traffic rate. (tbf or > htb here) > What you might want to do is to shape traffic with htb as you did, and > use red inside htb, not to do tail-drop. > Tbf would be easier for shaping, but i don''t know if combining tbf and > red is possibe. (probably not)Oops didn''t see this one before I replied. Andy.