How do sfq and tbf interact when packets need to be dropped? Example: two flows are entering the linux router, flow A is 1 mbit and flow B is 3 mbits (total = 4). We use tbf to limit outgoing bandwidth to 2 mbits (further downstream there is a bottleneck). If we just used tbf, it would be dropping 50% of all packets - ie, flow A would see about 500K of it''s traffic getting through and flow B would see about 1.5mbits getting through. This isn''t "fair" - flow A should not have any of its packets dropped and flow B should be limited to 1 mbit. So we add sfq. What''s not clear to me is if this will accomplish what I want. If the tbf algorithm occurs before sfq, tbf will drop 50% of all packets. After that, sfq will have no effect. If the sfq algorithm is performed first, then all 4 mbits of the resulting traffic is sent to tbf, then tbf will drop packets from both flows. It would seem that there needs to be some interaction between the algorithms - tbf needs to signal to sqf that more packets can be sent. But the packet dropping should occur in sqf (where fairness is understood) not in tbf. So question: will it work as I want or is a new qdisk needed? note: I actually have hundreds of flows, so I don''t want to classify them manually. I also don''t want hard allocations of bandwidth. If there is only flow B, 2 mbits of it should be allowed to pass. Thanks. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
TBF and SFQ can''t be used together. The changes to make TBF classful kept the limit inside TBF for compatibility. This means TBF calculates how much bytes are in the leaf qdisc and drops if the limit is exceeded. This is stupid for two reasons: 1. The limit is checked in the leaf qdisc (default: bfifo) anyways, this is enough for backward compatibility. Turning the inner qdisc into a pfifo gives you two limits, N bytes from the TBF and M packets from the pfifo. 2. With SFQ it is not possible for TBF to know how much bytes are in the queue because SFQ may return NET_XMIT_CN, meaning that this or another packet has been dropped. The result is that either the limit is not kept (underestimate) or worse, the qdisc stops accepting packets at some point (overestimate). So to use TBF+SFQ you need the attached (untested) patch which removes limit checking from TBF and relies on the inner qdisc to do the right thing. For you main question: Yes it will work as you expect. SFQ provides fairness for single flows and TBF limits the total output rate. Best regards, Patrick Jon Zeeff wrote:> > How do sfq and tbf interact when packets need to be dropped? > > > Example: > > two flows are entering the linux router, flow A is 1 mbit and flow B > is 3 mbits (total = 4). We use tbf to limit outgoing bandwidth to 2 > mbits (further downstream there is a bottleneck). > > If we just used tbf, it would be dropping 50% of all packets - ie, > flow A would see about 500K > of it''s traffic getting through and flow B would see about 1.5mbits > getting through. > > This isn''t "fair" - flow A should not have any of its packets dropped > and flow B should be > limited to 1 mbit. So we add sfq. > > What''s not clear to me is if this will accomplish what I want. If the > tbf algorithm occurs before > sfq, tbf will drop 50% of all packets. After that, sfq will have no > effect. If the sfq algorithm > is performed first, then all 4 mbits of the resulting traffic is sent > to tbf, then tbf will drop > packets from both flows. > > It would seem that there needs to be some interaction between the > algorithms - tbf needs to > signal to sqf that more packets can be sent. But the packet dropping > should occur in sqf (where fairness is understood) not in tbf. > > So question: will it work as I want or is a new qdisk needed? > > note: I actually have hundreds of flows, so I don''t want to classify > them manually. I also don''t > want hard allocations of bandwidth. If there is only flow B, 2 mbits > of it should be allowed to pass. > Thanks. > > >
I''ve set up bridging between two interfaces and this gives me a new "br0". When I apply qdiscs to it, what am I controlling - traffic out of eth1 or traffic headed out eth2? Should I not be using br0 and refer to eth1 and eth2? _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> I''ve set up bridging between two interfaces and this gives me a new > "br0". When I apply qdiscs to it, what am I controlling - traffic out of > eth1 or traffic headed out eth2? > > Should I not be using br0 and refer to eth1 and eth2?yes, this is true. Use eth1 and eth2 not br0. -- Damjan Georgievski jabberID: damjan@bagra.net.mk _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Witaj Jon, W Twoim liście datowanym 26 listopada 2003 (20:51:29) można przeczytać: JZ> I''ve set up bridging between two interfaces and this gives me a new JZ> "br0". When I apply qdiscs to it, what am I controlling - traffic out of JZ> eth1 or traffic headed out eth2? JZ> Should I not be using br0 and refer to eth1 and eth2? just use eth1 and eth2 to control traffic not a virtual br0 device. JZ> _______________________________________________ JZ> LARTC mailing list / LARTC@mailman.ds9a.nl JZ> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Pozdrowienia, Robert _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/