By Aaron Weiss

February 03, 2009

If your Wi-Fi network sees both VoIP and BitTorrent (or similar) activity, it will benefit from QoS. We walk you through the ins and outs of setting it up on your router using Tomato firmware.

Related Articles

• Ask the Wi-Fi Guru, Episode XI
• How to: Monitor Bandwidth with Tomato Firmware
• Introduction to Tomato Firmware
• Sauce Up Your Router with Tomato

Chances are that your wireless router is a very busy intersection. Picture those photos of crowded city streets jam-packed with cars, trucks, and busses all trying to squeeze through a narrow road. Now imagine your router as an overwhelmed traffic cop standing in the middle of it all, blowing her whistle trying to keep order.

If you’re using Tomato firmware on your router, you can help reign in the chaos using QoS, or Quality of Service. Your typical network pushes around several different types of traffic. There is Web browsing (HTTP), for example, but there may also be gaming, and VoIP, and FTP, and P2P data, such as BitTorrent. But not all traffic is created equal—some things, including gaming and VoIP, need minimum delays, whereas file transfers do not require the same priority.

“Priority” is what QoS is all about—creating a fast lane, a slow lane, and possibly additional lanes in between for your network traffic. This way, a torrent download does not slow Web browsing to a crawl, for example.

In and out

Traffic flows in two directions—into your network from the Internet and out to the Internet from your network. The router, of course, sits at the intersection. QoS is really only effective on outgoing traffic—that is, data from your network headed to the Internet. That’s ok, because this is the traffic you need to manage to keep your network from getting bogged down.

Although Tomato does provide settings for managing incoming traffic, you cannot really expect reliable results from incoming QoS. The rate of inbound traffic is controlled by your ISP and there isn’t much the router can do to change that. While outbound QoS can delay outgoing packets to conform to your rules, incoming QoS can only throw away (not delay) incoming data, which produces erratic and inefficient results.

Divide and conquer

Before we look at creating a QoS configuration in Tomato, it is helpful to understand the two basic principles involved: classification and prioritization.

Classification requires identifying particular kinds of network traffic and assigning them to a priority class. For example, you probably want to identify Web (HTTP) traffic and assign it to a high priority class. This way, Web browsing will take precedence over lower-priority traffic.

You don’t need to classify every conceivable type of traffic. Rather, you will classify the most notable types of traffic that you expect to use in your network, and all unclassified traffic will be assigned to a default priority class.

Once your classification rules have been setup, the next step is to define prioritization rules. Each class of traffic carries with it two factors: priority and bandwidth.

Class priority defines how (outgoing) traffic will be expedited or slowed by the router. Suppose you classify VoIP traffic in the highest priority ranking. Whenever such traffic is sent from your network, this router will essentially delay any traffic assigned to a lower priority so that VoIP gets through first.

Class bandwidth defines how much available (outgoing) bandwidth traffic assigned to that class may use. For example, you might classify FTP traffic as having a low priority and also a maximum of 50% available bandwidth. This would mean that even if FTP traffic were the only traffic at a given moment, it still could not consume more than 50% of outgoing bandwidth.

Priority and bandwidth are independent factors—you could assign all priority classes with 100% bandwidth if you prefer. This would not mean that all traffic would use all bandwidth, but that any traffic type could use the maximum available bandwidth should there not be any higher-ranked traffic moving through.

Classification in Tomato

In Tomato, you configure class priorities through the QoS/Basic Settings menu, and classifications through QoS/Classification. You can configure both in either order, but if you are new to QoS then starting with classification may be preferable.

The outbound classification rules as seen here represent a simple network environment. The first rule identifies typical Web traffic. Tomato can use a variety of matching factors to define a type of traffic.

Here, basic Web traffic is described as TCP traffic with a destination (outgoing) port of 80 or 443 (for HTTPS), and with a size under 512KB (meaning it is not a large file transfer). Traffic that meets these criteria is assigned to the “High” class.

The second WWW rule catches Web traffic that is likely to be a large file transfer (over 512KB). This traffic is assigned to the “Low” class, on the thinking that this traffic is not as delay-sensitive as Web browsing.

Similar logic is used here to create a rule for DNS lookups, which you want to happen without delay (except bulk lookups, which are demoted to “Lowest” class).

In this basic configuration, most other traffic (TCP between ports 1024-65535) is assigned to the “Lowest” class. Remember—this does not mean that all unspecified traffic is “slow”—it simply means that WWW and DNS traffic will take priority when they are present.

Tomato provides several kinds of rules for defining a traffic class:

• Address-based—by IP (source or destination) or MAC (source only). Use this rule to identify a particular machine inside your network (by IP or MAC address) or a destination machine on the Internet. Remember that “source” is inside your network and “destination” outside.
• Protocol-based—TCP and/or UDP or choose from among a list of other (relatively uncommon) network protocols. Protocols can be further constrained by source or destination port.
• P2P-based—You can use IPP2P, an engine for identifying particular kinds of P2P traffic. Note that IPP2P identification may not work for encrypted P2P traffic.
• Layer 7 filter-based—also known as L7, this is a sophisticated engine for identifying a wide range of traffic types. You will see a long list of traffic sources available under the L7 filter. Like IPP2P, P2P traffic like BitTorrent may not be correctly identified when encryption is in use.

Creating a classification using only address or protocol-based rules requires much less processing power, whereas L7 uses the most. Adding too many L7-based rules can cause a router to crash, reset, or become bogged down—ideally, try to use protocol and port-based rules wherever possible.

When choosing a class, Tomato offers ten levels, plus “disabled” (which will leave such traffic unclassified). The higher the class you choose, the higher priority will be given to traffic assigned to this class. “Highest” is, as its name suggests, the highest priority class. “Lowest” is the 5^th class level, but is not actually the very bottom class. These would be the classes named “A” through “E” with “A” being one rank lower than “Lowest” and “E” being the very lowest of all.

For most scenarios using all ten classes is probably overkill—you can probably get by using “Highest” to “Lowest” and ignoring “A” through “E.”

Now that you’ve created a basic set of rules assigning certain types of traffic to classes, we can define how the classes themselves behave.

Prioritization in Tomato

Discrimination is normally bad, but in the network world it can be good. We will use the settings in QoS/Basic Settings to discriminate against certain kinds of traffic and advocate for others.

The very first checkbox will activate or inactivate the whole QoS engine. You will want this enabled, of course.

Second, you can tell Tomato to give priority to certain packets that are used in network negotiation. Most users will want to leave SYN, FIN, and RST unchecked. There is some debate over whether ACK packets should receive priority. These so-called “acknowledgment” packets will pile up when using a connection-intensive protocol, such as BitTorrent, leading some to suggest that heavy torrent users should not prioritize ACK packets. The counterargument is that delayed or lost ACK packets will result in data retransmission, causing an even greater flood of network resources. Short answer: most people should leave ACK prioritization enabled, but heavy torrent users might experiment with the disabled setting.

Similarly, prioritizing ICMP packets will improve response to ping requests.

If you check “Re-classify all packets when changing settings,” then a change to QoS rules will trigger re-analysis of ongoing traffic. You should probably check this if you change QoS rules while traffic is in progress.

Setting the “Default class” to “Low” is often preferable to building rules for lots of traffic types. Use this setting to assume most traffic is not high-priority, and use the rules in the classification settings to define high-priority exceptions.

This is a particularly good strategy for BitTorrent users. It is notoriously difficult to create accurate rules for torrent traffic. Instead, creating no rule at all will cause torrents to default to the “low” class.

You cannot change the ranking of classes—traffic in the “Highest” class will always receive priority over traffic in the “Medium” class, for example. But you can change how much bandwidth is available to each class, using the “Outbound Rate/Limit” rules.

First you need to know the maximum outgoing bandwidth of your Internet connection. Unfortunately the router cannot figure this out on its own, and you can’t rely on what your ISP has advertised. Instead, you should run a speed test and measure your own connection’s upload performance. In fact, run the test several times. Ideally, if your upload speed is relatively consistent, enter a figure about 90% of this speed into the “Max bandwidth” field.

If your upload speed varies by much, you will need to be conservative and use 90% of your lowest score. If you enter too high a max bandwidth than your connection can deliver, you could wind up flooding the connection and bogging down all network activity.

Based upon this maximum upload speed, you can now define minimum and maximum limits for each class. For instance, in this example any traffic assigned to the highest class will always use at least 80% of the available upload bandwidth, all the way up to 100% (if available).

On the other hand, traffic in the “Lowest” class will never use more than 95% of upload bandwidth, and might use as low as 2% if no more is available.

You will need to tweak these numbers for your own network. Assuming you choose not to use any classes from “A” through “E,” we can ignore those settings. Further, you might want to raise the minimum of the highest and/or high classes—try bumping 80% to 90% minimum for highest, for example. And you might want to lower the maximums for the lowest class—perhaps 80% or 70% for that traffic that you wish to never consume too much bandwidth.

QoS in pictures

Finally, Tomato offers two views of your network activity as filtered through QoS: View Graphs and View Details.

QoS graphs display two pie-charts—one counting the number of network connections grouped by classification, the other showing bandwidth usage grouped by classification.

Both graphs are updated in real-time, so you can see how changing network activity is reflected by your QoS rules.

Clicking on View Details instead displays a complete list of all active network connections, including protocol, source and destination addresses and ports, and classification. This can be useful to see how your classification rules are behaving, and whether traffic is being assigned to the class to which you think it should be. If not, your classification rule may need tweaking.

Do you need QoS?

QoS is not always the best solution—sometimes you’re better off leaving it disabled altogether. The average network user may find QoS to be more trouble than it’s worth. QoS is most valuable when your network usage includes both time-sensitive activity and bandwidth-intensive activity. In other words, a network which sees both VoIP and BitTorrent activity will benefit from QoS, otherwise the torrent traffic could overwhelm voice packets.