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
--