yes I do. I oversight the sfq_drop call in enqueue ;-) devik On Fri, 7 Dec 2001, Don Cohen wrote: > > After an off-list discussion I think Martin now agrees with me that > sfq will not let one large flow deny service to all others. > It's actually the other way around, ensuring service to the small ones > even at the expense of the large ones. > > > From: Martin Devera <devik@xxxxxx> > > > > IMHO the RED would be useful here. SFQ limits total packet count > > to 128 packets. So that one flow can simply fill whole SFQ leaving > > small space for other flows. > > I'm able to simulate it using one host generating huge UDP flow. > > All others flow goes away :( > > > > devik > > > > On Mon, 3 Dec 2001, Don Cohen wrote: > > > > > > > > > On Tue, Nov 27, 2001 at 11:53:10AM -0500, Michael T. Babcock wrote: > > > > > I've asked this before, but does anyone feel technically inclined > > > > > enough to try swapping in a RED queue for the per-bucket queuing done > > > > > by SFQ? If SFQ builds a series of 'sessions' to be given fair use of > > > > > available bandwidth, using RED to slow down those that are building up > > > > > too fast would smooth things out. > > > > > > I don't think this is necessary. As it is now, when you enqueue a > > > packet in a full SFQ queue it drops from the tail of the longest > > > subqueue. If you have substantial competition for the link then > > > your subqueue won't be allowed to grow very long to begin with. > > > The random variation in demand from other flows will have the effect > > > of jittering the maximum length of your subqueue, which is pretty > > > similar to what you experience with RED, isn't it? > > _______________________________________________ > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ > >
