Re: [LARTC] SFQ buckets/extensions

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
From: "Michael T. Babcock" <mbabcock@fibrespeed.net>
To: <lartc@mailman.ds9a.nl>
Sent: Friday, June 07, 2002 4:18 PM
Subject: RE: [LARTC] SFQ buckets/extensions


> > In a long term always droping from the largest subqueue
> > gives you equal subqueues.
>
> And, of course, one could have it drop them using a RED-like algorithm
> to make the sessions stabilize themselves better.

If you are dealing with a responsive session (like TCP) that is...

> > what they have) is better. May be doing it like the cbq with average
> > packet size can gave us better results.
>
> Calculating average packet size on the fly isn't that hard either.
>
> > All started with the so called Download Accelerators,
> > which do paralel gets and make TCP behave bad.
> > In normal case TCP adjusts fast and does not create backlogs.
> > But when you have to change it's bandwidth , you have to create
> > a backlog to slow it down. It then clears fast.
>
> I actually usually download pieces of the same file from multiple
> mirrors if its truly large and want it fast :-).  Ranged downloads make
> that quite possible ... The only way to equalize bandwidth "fairly" in
> these scenarios still seems to be to implement the hierarchial approach
> of hashing against destination IP (the user receiving the packets) and
> then having sub-queues to those queues based on ports and to drop
> packets (based on RED?) in each of these sub-queues (because they're
> closer to the actual TCP sessions involved).
>

Why not implementing the sfb (stochastic fair Blue)? From the papers I read,
the algorithm with the double buffered moving hash extension, seemed like a
better alternative for the FRED, Stochastic fair RED and SFQ.

> > People wanted options to tune hashsize/limits/depths and
> > the most wanted (needed) was the option to select hash type.
> > SRC/DST Port hash is in TODO now.
>
> And I'm glad it exists for testing at least.
> --
> Michael T. Babcock
> CTO, FibreSpeed Ltd.
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux