[lug] Local Linux Developer has new Shaping tool, would like feedback! (fwd)

Art Reisman astormchaser2002 at yahoo.com
Tue Feb 4 16:21:26 MST 2003


--- Sean Reifschneider <jafo at tummy.com> wrote:
> >Sorry I have not been active in the local Linux
> User
> >Group. I have developed an innovative open source 
> >bandwidth limiting tool that runs turn key on a
> Linux
> 
> Can you provide some details on what makes this
> "innovative" and why it
> is better than, for example HTB3 traffic shaping?  
I don't think I'll ever compare other solutions as
better or worse than the Linux Bandwidth arbitrator. I
have had discussions with some of the LARTC folks (I
think they are the same as HTB3), and would gladly
reccommend their solution.   The basic differences as
far as I know are:

1) The Linux Bandwidth arbitrator is truely turn key
once the software is loaded. It self configures to the
network ,without trying to group speicifc traffic, by
type of user etc, it will get you from a wide open
network to a beneficial traffic control solution which
favors "business" type users over people doing big
downloads fairly quickly, and without any need for
training (just a black box to plug in). It constantly
and dynamically adjusts itself to the level of your
network and activity without any tuning. 

I tried to emulate the philosophy that a kernel uses
when scheduling processes, this is an abstraction that
we have accepted for our OS. Kernel schedulers may not
be optimal for a particular application but they are
much better than nothing? 


2)The method of slowing traffic with most shaping
tools involves looking at every packet coming in and
then re-arranging them based on priorities, and
possibly flushing packets that come in too heavy at
the expense of others. The arbitrator looks at the
heavy traffic flows and then figures out where the
"request" for that traffic is coming from. It then
slows the requests down. No traffic comes into (or out
of a network) without somebody requestiing it? A
corrorally of this  method should be

   - Less need to drop packets 
   - Less memory and horspower to implement
   - Little or no adminstration and rules for  a
system that is
     "good enough" to get 30 or 40 percent improvement
      in reponse times for users

Does that help? Make sense?

I'd appreciate feedback..
Thanks

Art 
> checked your
> web-site, but it's pretty slim on technical details
> other than that it's
> a "traffic cop".  I'll take HTB3 over a "traffic
> cop" any day.  ;-)

I just wrote up a bit explanation and lost it darn...




> 
> We've been experimenting with HTB3 at tummy.com,
> ltd.'s hosting
> facility, and at the Northern Colorado Internet
> Cooperative for a while
> now and it's pretty sweet.  Basically, it's a shaper
> but only comes into
> effect when you hit an upper limit on bandwidth. 
> Because it's
> heiarchical ("Heirarchical Token Bucket 3"), you can
> group users or
> services in useful ways.
> 
> If a grouping is overcommitted (meaning, it is using
> more bandwidth than
> is available), they will be throttled based on some
> metrics.  If you
> have 1mbps of bandwidth and 3 users committed to
> 512kbps, if 2 of them
> are idle the third can use 1mbps, but as soon as
> another starts using
> bandwidth the 1mbps user is pushed down to make
> room.
> 
> We're actually using it to ensure that critical
> traffic can make it
> through, and limit the impact of a local denial of
> service attack or
> compromise attempts against outside networks.
> 
> Sean
> -- 
>  Maybe I'm a closet claustrophobic.
>                  -- Yosomono on #python
> Sean Reifschneider, Inimitably Superfluous
> <jafo at tummy.com>
> tummy.com, ltd. - Linux Consulting since 1995. 
> Qmail, Python, SysAdmin




More information about the LUG mailing list