are there any plans to add voip to wondershaper? alot of us are using
m0no and vonage these days.

das


On Wed, 01 Dec 2004 12:13:54 -0600, Justin Ellison
<justin at techadvise dot com> wrote:
> Hi Chris,
> 
> Firstoff, I wrote the magic shaper with Dinesh's assistance because so
> many people were asking for it, and I wanted to get a project to start
> with to familiarize myself with FreeBSD.  I used the wondershaper script
> for Linux as my starting ground.
> 
> > 1) Why the 3 different "high priority upload" queues?
> 
> WonderShaper has three ;-)  Seriously, that's why I started it that way.
> Each queue has different weights.  So, think of it as mission-critical,
> urgent, and important.  It let's you not classify a packet as bulk, but
> not give it the highest priority.
> 
> > 2) Looking at the "m_Small Pkt Upload" rule, it seems that this would
> > completely include the "m_TCP ACK Upload" rule, since the former appears
> > higher in the list (hence making the separate TCP ACK rule redundant).
> 
> Correct.  The m_Small Pkt Upload rule was added after the m_TCP ACK
> rule, and I missed that one.  I'll fix it in the next version.
> 
> 
> 
> > 3) I did some connection monitoring on a machine running BitTorrent, and I
> > noticed that a good 50% of the connections from it aren't on the standard
> > 6881-6999 port range. Given that I'm not trying to prohibit BitTorrent, but
> > merely prevent it from slowing down other network connections unreasonably,
> > I'm trying to find a reliable way of doing so.
> >
> > If I know the machine that's responsible for the BitTorrent traffic, can I
> > define rules as follows:
> > If                 | Proto | Source | Destination | Target
> > WAN (out) |   *      | Cronus |      *            |  P2P Upload
> > WAN (in)   |   *       |  *          |  Cronus     | P2P Download
> >
> > (sorry, I suck at ascii art, but you get the idea)
> > If I'm on the right track, that *should* mean any traffic into/out of Cronus
> > should go into the lowest priority queue?
> 
> Depends on where the rule is at in the list.  If that rule is placed
> right before the catch-all's, then any web type traffic should get
> higher priority, and anything not classified will get put in the hated
> queues.  Watch out for things like sending/receiving email attachments,
> etc., as those will slow down.
> 
> 
> 
> > Given high priority up/download are mainly for VPN, so let's assume only
> > catch all and hated are in use: if a queue is completely unused, how is
> > traffic distributed?
> >
> > Default magic shaper config for those is as follows:
> > Upstream weights: catch-all (4), hated (1)
> > Downstream weights: catch-all (40), hated (10)
> >
> > So, am I right in saying that given none of the high-priority queues are in
> > use, for every 4 packets of "ordinary" traffic, one packet of "hated"
> > traffic is allowed? If so, that means that 20% of outgoing traffic should be
> > "hated". Is there any mileage in changing this by reducing the priority of
> > the "high priority" queues in favour of increasing the priority of the
> > general queue?
> >
> > i.e. High priority is redefined as weight=50, general has a weight=49, and
> > hated has a weight=1.
> > If my calculations are correct, that should mean that only 2% of outgoing
> > traffic would be P2P.
> 
> It has been *so* long since I worked with the weights (and to be honest,
> Dinesh had to explain it a few times to me), that I'll let someone else
> answer the above.  Be a good review for me :-)
> 
> Justin
> --
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
> 


-- 
yeah i gots me some gmail, yo!