Successful VOIP Over DSL, Part 4: Traffic Shaping

My experience has been that the QoS mechanisms covered previously don’t provide a complete solution to the need for assured bandwidth when using VOIP over DSL. When the connection to the ISP becomes saturated for any reason VOIP traffic can be delayed which is always a problem. When managed QoS was combined with “traffic shaping” our VOIP phone service became much more reliable. This has proven to be true even on a very busy connection to my ISP.

Like the QoS mechanisms covered previously, traffic shaping is an edge process that occurs in your router. Traffic shaping is actually a process of reserving bandwidth specifically for selected applications. That bandwidth will not be used for other forms of internet access. As before, this tends to be most critical with outbound traffic where available bandwidth is most limited. It’s also true with inbound traffic, but this tends to be less of an issue.

By the time I was ready to put my Asterisk server into production I had shifted to using m0n0wall as my router. m0n0wall is simply outstanding. It’s a router based upon FreeBSD and using a PHP based GUI that’s accessed as a web site.

It’s available for a variety of hardware platforms including:

• Generic PC
• Soekris Net 4501 single board embedded computer
• Soekris Net 4801 single board embedded computer
• PC Engines Wrap series of single board embedded computers
• PC Engines Alix series of single board embedded computers

I decided to use a Soekris Net4801 as the host platform for my m0n0wall. This is a small system based upon a National Semiconductor Geode 266 MHz CPU. It boots from a CF card and stores the router configuration on a USB key.

The Net4801 has three on-board Ethernet ports. These are typically used as; WAN, LAN and DMZ.

By default the traffic shaping feature on m0n0wall is disabled. Before going about its setup you need to know for certain what your actual upload and download speeds will be. To measure your internet access speeds use a reliable series of speed test tools such as those found at Broadband Reports. It’s also a good idea to take measurements at various times of day to see if there is any significant variability.

The online documentation for the traffic shaper is a little thin but can be found here.

Traffic Shaper Theory:

The available bandwidth is forcibly divided into “pipes.” Traffic may be buffered into a pipe by one of a series of “queues.” Finally, “Rules” define what kind of traffic is directed into which queue or pipe.

Confused?

Don’t be.

It looks something like this.

Pipes

The theory behind traffic shaping is fairly simple. You will create several “pipes” which are essentially separate paths through the router. Each pipe is assigned a certain slice of the available bandwidth. In my case I have two pipes for outbound traffic and one for inbound traffic.

Queues

In addition to the pipes you also establish queues within the router. Queues let you assign varying priorities to different types of traffic. Each queue can be directed to a specific pipe and assigned a “weight.”

Rules

Traffic shaper rules are created to direct traffic based upon the properties you select. A rule can direct all traffic from a specific source or destination IP address, or in my case IP range, into a particular queue & pipe. Selectivity can also be based upon port, protocol, network interface, etc.

It’s also worth noting that this is the menu in m0n0wall where you can direct traffic based upon TOS tags. So the basic mechanism of DiffServ QoS is actually a facet of the traffic shaper. This gives a lot of flexibility which may be enough of a reason to go the extra cost of m0n0wall over a lower priced consumer router.

Magic Shaper

If all this seems a little much to understand you’re in luck. m0n0wall provides an automatic setup tool called “Magic Shaper.” You only need to tell it the measured connection speeds. This function will establish all the required pipes and queues.

My World Of Imperfection

My installation still has the dregs of the magic shaper process in a couple of ways. There is a “hated” outbound priority #5 that I don’t use. Since it is assigned only 1% of the available bandwidth I just left it in place. There’s also a low priority download queue that goes unused.

Both of these are aspects of the magic shaper process that are part of a strategy for handling P2P programs. I don’t use any P2P file sharing programs so this goes unused. The queue is directed at the sole download pipe so it’s presence does not cost me any loss of download speed. The two higher priority queues access the same pipe and can fully saturate it when required.

Local Asterisk & Hosted PBX

My office may be a little unusual in that I have my own Asterisk server (several actually) and I rely upon an externally hosted IP-PBX. I also have a number of SIP hard phones and ATAs around the office and house.

Given the number of VOIP devices and services I found the easiest way to direct VOIP traffic to the high priority outbound pipe was on the basis of IP address. I let each SIP device gets its IP address from the routers DHCP server. I then use MAC reservations to set all those IP addresses into 192.168.1.128 and higher. The traffic shaper rule for VOIP outbound traffic specifies that this address range connects to the high priority outbound pipe.

This arrangement also makes it very easy for me to add VOIP devices under test and know that they fit into my bandwidth management scheme. As long as they have IP address in the upper range call quality is assured.

The only circumstance that isn’t well handled by the arrangement is when I use a soft phone on my desktop. Since the desktop PC is in the lower IP address range it’s traffic is not treated the same as the VOIP devices. Happily, I don’t need to do this very often. Plus it’s kind of gratifying to think that my VOIP traffic get priority even over Skype, which I use only reluctantly.

CIDR Notation

Within m0n0wall dealing with things like IP address ranges uses CIDR notation. This was not something that I was familiar with previously. I posted a inquiry to the m0n0wall user list which met with a great response from one of the project’s lead developers. He posted some provisional documentation here.

It is also possible to assign priorities based upon ports & protocols. I’ve done this in the past but I have no need of this any longer.

VLANs

There is a lot of VOIP oriented information available online regarding virtual LANs, a.k.a. VLANs. VLANs are a means of separating network traffic over the same wire as if there were physically separate networks.

Each VLAN is treated as a separate segment on the LAN, even thought the traffic is all on one wire. With the traffic virtually separate there is then a means of establishing varying priorities for VOIP traffic by giving preference to traffic on the VOIP specific segment. This requires a router capable of VLAN functionality and some depth of knowledge in its configuration.

Much of the recent attention paid to VLANs in the VOIP space has been highlighting the fact that VLANs should not be considered a security mechanism. This is a little contrary to the common practice.

• Isolation vs. Integration by Dustin D. Trammell
• Telecom junkies Podcast, VoIP Hacking 2: The VLAN Hop
• VoIP Hopping: A Method of Testing VoIP security or Voice VLANs by Jason Ostrom, John Kindervag at Security Focus
  

In my office I’ve managed to avoid the complexity of using VLANs. I am of the opinion that such solutions are more appropriate for enterprise installations than SOHO circumstances.

An Alternative: pfsense

While I’ve been using m0n0wall you might also consider pfsense. m0n0wall is intended for small format hardware like the Soekris boards and it’s author has been very careful to avoid code bloat resulting for adding a myriad of features. pfsense is based on m0n0wall but has a larger feature set and targets more capable hardware.

Another Alternative: Astlinux

Astlinux is another interesting alternative. Astlinux is a full Linux & Asterisk distro build from the ground up for small form factor hardware. It runs happily on a Soekris Net 4801, booting from a CF card and storing the system config and voicemail on a USB key. Astlinux includes a built-in routing capability based upon iptables. Thus using Astlinux your phone server can actually be your router. The built-in router includes QoS and traffic shaping.

Some time ago I wrote an article describing building an Astlinux server using a Net4801. While a little dated now that article can be found here.

Summary

As stated at the outset this series of articles describes my home office setup where every call placed or taken is handled over IP. It’s not uncommon for me to have three simultaneous calls on the go (one on the home line, two in the office) and occasionally four or five.

By using G.729a when possible, combining QoS and traffic shaping I no longer have any trouble with call quality due to non-VOIP network activity. I can upload files via FTP or send and receive email while making calls without any problems at all.

The fifth and final part of this series will address some considerations given to power when migrating to a wholly VOIP home office.