The newest version of m0n0wall has a magic traffic shaper wizard to get users started with bandwidth shaping, which is one of monowall's strongest features. Unfortunately it was pretty difficult for me to understand how to configure it until now. The wizard builds a set of rules that makes it much easier to understand how to properly configure bandwidth shaping.

Bandwidth shaping in its broadest sense assigns a priority to traffic. The higher the priority the more bandwidth is allowed, but not reserved. Low priority traffic will get 100% of the available bandwidth if there is no other traffic. Bandwidth shaping can prevent a  Voice over IP phone call from breaking up when junior decides he has to download a half dozen MP3's. monowall uses the  Dummynet portion of FreeBSD to perform it's bandwidth shaping.

Monowall's Magic traffic shaper installation begins with the following choices:
Set P2P traffic to lowest priority
Share bandwidth evenly on lan

Enter your downstream speed
Enter your upstream speed

Then select install/update. There is a warning that all previous settings will be erased. This can be a good or a bad thing depending on how knowledgeable you are with traffic shaping.

Results

After pressing the install button my installation had 2 pipes 2858 down and 346 up. 8 queues were built, 3 high priority uploads, a bulk and a hated upload, a bulk download, a hated download and a high priority download.

 
50 rules were created assigning traffic to queues, 36 of them dealt with peer to peer traffic. The peer to peer clients addressed by the rules were BitTorrent, DirectConnect, DirectFileExpress, FastTrack, CuteMX, IMest, EDonkey, SongSpy, HotLineConnect, Gnutella, dcc, Napster, Aimster, BuddyShare, Scour, OpenNap and HotComm. I don't use peer to peer, so I don't know whether this list is current or complete. 

Analysis

Pipes are throughput rates, although the pipe isn't assigned to an interface. The magic shaper builds rules only for the wan rates, which is what most people would want by default. If you need to prioritize traffic between subnets you're on your own.

Queues are proportional shares of a pipe. Each queue is assigned a weight value of 1 to 100. Every queue will get some bandwidth if there is traffic waiting for it which means there is no guaranteed QOS. If the VOIP traffic has used up its bandwidth then the mp3's get their turn. This could be minimized by giving VOIP a queue weight of 100 and general traffic queue weights of 1, 2, 3 & 4.

My 5 upload queues had weights of 50,30,15,4 & 1 adding up to 100. This means the highest weighted queue will get 50% of the bandwidth up if all queues are active. If only the 50 and 1 weighted queues are active then the 50 weighted queue will get 50/51 of the bandwidth as long as there is traffic waiting for it.

m0n0wall's wizard also set the mask to "source" on my upload queues and "destination" on my download queues. This configuration gives each source computer an equal share of the queue. Assuming I had 2Mbit allowed for a download queue and 4 computers downloading, each would get 500K of bandwidth. Without this option the packets would pass as a single 2Mbit queue on a first come first serve basis, giving the computer downloading from the fastest source more bandwidth. Masks can also be set on pipes.

The interesting question is how monowall divides the queues. Is it by packet count or time slice? Luckily the source code is available to examine, although examination will have to wait.

Rules assign traffic to a queue based on direction, source and destination address and port, type of service values, packet length and TCP flags. The rules assigned by the monowall Magic Shaper Wizard assign P2P to the hated upload and download queues (weight of 1 and 10 respectively). Small packets less than 100 bytes, DNS queries, AH, ESP and GRE and  are assigned to high priority #1 upload (weight 50). ICMP traffic is assigned to high priority #2, weight 30. TCP Ack packets are assigned to high priority #3, weight 15. Everything else goes to CatchAll weight 4. This setup will result in VPN and DNS traffic having the highest priority followed by ICMP, general traffic, then P2P far behind.

m0n0wall examines the rules in order for each packet and the first rule matching the packet is executed. An unpadded ICMP echo reply would match the small packet rule #37 and be assigned to the high priority #1 queue, processing of the rules would then stop instead of continuing on to the ICMP upload rule #42 and high priority #2 queue. In this case that's good, but if the small packet rule came ahead of the P2P rules then some peer to peer traffic would match the small packet rule giving it a high priority.

What I've learned:

Pipes are throughput rates and not interfaces. The throughput rate should be set to 95% of the total throughput of the connection.

Queues are assigned to a pipe and the weight value of each queue passing traffic determines it's proportional share of that pipe's bandwidth.

Masks subdivide queues and pipes into separate "flows" based on source or destination, each flow having a proportional share. 3 sources using one queue would get 1/3 of the total bandwidth allotted to that queue.

Rules assign traffic to queues. The order of the rules are important since they are processed sequentially. The most specific rules should come first, getting more general further down the list. This prevents traffic from accidentally falling into the wrong queue.

monowall will not guarantee quality of service. Each queue gets its proportianal share of bandwidth, so some VOIP or other high priority traffic could wait while lower priority traffic is passed. m0n0wall's bandwidth shaping will prevent a computer from monopolizing a connection and provide an equitable distribution of bandwidth.

Some references

Using Dummynet for Traffic Shaping on FreeBSD

IPFW(8) Man page

DummyNet(4) Man Pages

My first m0n0wall experiment

My monowall network implementation