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. Just a thought ... -- Michael T. Babcock
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 have no clue how you would configure that - is it even possible to ''concat'' classless queues? 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
> I have no clue how you would configure that - is it even possible to > ''concat'' classless queues?Not in the present state of things, I don''t believe so, no. I''d like to be able to do that though ... -- Michael
> 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?
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@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ > >
> 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?Not quite, no. The dropping of packets is based on actual calculations in RED that aren''t available in SFQ. SFQ drops _all_ the packets off the end and doesn''t start doing so before congestion happens -- RED is designed to drop packets before getting overly congested so that the stream speeds stay steady and don''t try to climb above what''s available. -- Michael T. Babcock
On Tue, Dec 04, 2001 at 01:27:02PM -0500, Michael T. Babcock wrote:> > 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? > > Not quite, no. The dropping of packets is based on actual calculations in > RED that aren''t available in SFQ. SFQ drops _all_ the packets off the end > and doesn''t start doing so before congestion happens -- RED is designed to > drop packets before getting overly congested so that the stream speeds stay > steady and don''t try to climb above what''s available.GRED might be what you want, if you can get anybody to explain you how it works. I don''t get it yet. 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
On Thu, Dec 06, 2001 at 05:23:50PM +0100, bert hubert wrote:> GRED might be what you want, if you can get anybody to explain you how it > works. I don''t get it yet.I''m sure I can find documentation on how GRED is _supposed_ to work, but how it is configured in the Linux implementation would be a different issue entirely ;-). -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/
On Thu, Dec 06, 2001 at 11:37:37AM -0500, Michael T. Babcock wrote:> On Thu, Dec 06, 2001 at 05:23:50PM +0100, bert hubert wrote: > > GRED might be what you want, if you can get anybody to explain you how it > > works. I don''t get it yet. > > I''m sure I can find documentation on how GRED is _supposed_ to work, but how > it is configured in the Linux implementation would be a different issue > entirely ;-).GRED was invented for Linux by Jamal Hadi Salim - there is only one GRED. 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