* Re: [LARTC] RED vs. Tail Drop and docs
2001-12-07 16:57 [LARTC] RED vs. Tail Drop and docs Michael T. Babcock
@ 2001-12-07 17:08 ` Gregory Maxwell
2001-12-07 17:52 ` bert hubert
1 sibling, 0 replies; 3+ messages in thread
From: Gregory Maxwell @ 2001-12-07 17:08 UTC (permalink / raw)
To: lartc
On Fri, Dec 07, 2001 at 11:57:34AM -0500, Michael T. Babcock wrote:
> And for those wondering why I'd care to have RED instead of basic
> SFQ (although GRED might handle this as I'd like it to), see:
>
> http://www.google.com/search?qÊche:3RbzYw9RPU4:www-users.cs.umn.edu/~mhasan/finalpres.ppt+gred+queue&hl=en
>
> Scroll down to about the 1/3 mark or search 'red vs. tail drop'. Its
> a converted powerpoint presentation (from:
> http://www-users.cs.umn.edu/~mhasan/finalpres.ppt)
Also, try a search on SFB (Blue queue). I started writing a kernel qdisc for
SFB, but never finished, partly because it really needs to be integrated
with a class based system to give the needed flexibility (i.e. if it isn't
you will have to choose between the two) and partly because figuring out how
to correctly hook the 'busyness' of the interface.
A further problem is that Linux based shaper boxes are often not directly
connected to the 'slow link', but instead there is a separate router which is
taking in a much faster interface, performing it's own (often tail drop)
queuing, and pushing out on the slow interface. This configuration is the
biggest contributer to traffic control not behaving as expected.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LARTC] RED vs. Tail Drop and docs
2001-12-07 16:57 [LARTC] RED vs. Tail Drop and docs Michael T. Babcock
2001-12-07 17:08 ` Gregory Maxwell
@ 2001-12-07 17:52 ` bert hubert
1 sibling, 0 replies; 3+ messages in thread
From: bert hubert @ 2001-12-07 17:52 UTC (permalink / raw)
To: lartc
On Fri, Dec 07, 2001 at 12:08:25PM -0500, Gregory Maxwell wrote:
Greg, good to see that ou are still alive :-)
> A further problem is that Linux based shaper boxes are often not directly
> connected to the 'slow link', but instead there is a separate router which is
> taking in a much faster interface, performing it's own (often tail drop)
> queuing, and pushing out on the slow interface. This configuration is the
> biggest contributer to traffic control not behaving as expected.
You need to own the queue to shape it, yes, and in order to make this
happen, your linux box must be the slowest device in the chain.
This is why I am thinking of the 'stack' qdisc which would work like this:
___ 10:___
/ / \ \
/ | | \
10:1 10:2 10:3 10:4
<- <- <-
Enqueue()s always happen at the highest class, 10:4 in this case, dequeue()s
happen via 10:1, 10:2, 10:3 and 10:4. This would allow you to 'stack' RED,
SFQ and TBF, for example.
Haven't worked out how this would work in the kernel though. The question is
if we should 'push' or 'pull' - should a dequeue first always try to dequeue
10:4 to 10:3, and then from 10:3 to 10:2 etc etc.
What I really miss by the way is a way to poll devices for their queue
length, so 'downstream' devices would be able to own the queue so to speak.
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
Trilab The Technology People
Netherlabs BV / Rent-a-Nerd.nl - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
^ permalink raw reply [flat|nested] 3+ messages in thread