[index] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]
Traffic Shaping with pf+altq (29-Sep-2004)
After a few days of experimenting and making a few "real" calls over the voicepulse VoIP service I was finding that most of the time the call quality was great but from time to time the quality was unacceptable. This was all being done over my home DSL (6mbps down, 512kbps up) which, while fast, was also hosting an IRC server, fairly active web server, and a variety of other services. I decided that it was time to rebuild the openbsd box which had cooked itself a while back and implement traffic shaping in order to prioritize my VoIP traffic.
We ran off to Fry's and I picked up the cheapest AMD motherboard/cpu combo I could find and a new power supply. I harvested 1GB of ram I had in another dead box and the end results became my new Asterisk box. This freed up the Optiplex Celeron 300 that had been doing asterisk duty to become my new firewall. I installed OpenBSD 3.5 and got to work re-inventing my pf.conf which I'd lost when the old box died. I ended up with this: pf.conf.
In theory it doesn't make sense that you could successfully do reciept-side inbound traffic shaping but I've found that in practice it works remarkably well. I set up a bunch of simultaneous scp file transfers (both directions) and found that my interactive ssh and voip traffic was largely unaffected. It really works amazingly well. In implementing this I also learned that ssh has a great feature where it voluntarily flags non-interactive (scp and sftp) traffic as lower-priority. altq can make use of these flags and only boost the priority of actual interactive ssh traffic leaving scp traffic in a lower priority queue.
I set up only a few queues -- a bulk for served web traffic and scps, a default queue for all unrecognized traffic, and then priority queues for interactive ssh, voip, dns, and IP glue traffic. Since I'm a total stats junkie, I also hooked it up to cricket for graphing:
This is my outbound traffic. You can see the green "bulk" queue of served web traffic that peaks from time to time. You can also see the flat cyan "VoIP" queue that's flat for a while and then drops off at 12:00. That's drdink who stayed connected to a MeetMe() conference extension on my asterisk box and went to bed. Shows how little bandwidth a single voice channel (ulaw codec) takes if nobody's saying anything.
On the whole, I couldn't be happier with the performance of pf+altq. I know that FreeBSD 5.3 will have production support for it, but I didn't want to risk any issues with the relative immaturity of FreeBSD's support so I went with OpenBSD. In theory, there's no reason why you couldn't do this in FreeBSD too.
Important note: Linux kernel versions 2.6.8 and 2.6.8-1 appear to be afflicted by some crippling bugs which cause it to emit malformed fragmented tcp traffic. Users on hosts which are running these versions of Linux (or whose traffic passes through a Linux router using this version of the kernel) will have extreme difficulties receiving traffic which has passed through a scrubbing firewall. The symptoms are very similar to the more common MTU negotiation failure where tiny packets will survive but large packets will fall on the floor. You'll see the Linux box be able to establish the connection fine, and even pass insignificant traffic, but once the real stuff starts it will die.
The "scrub in all" directive in my linked pf.conf will trigger this bug for Linux users using those versions of the kernel. You should be aware of this and either disable scrubbing or (better) advising linux users to either use a stable 2.4 version of the Linux kernel or upgrade to 2.6.9 or higher.
Sadly, if you are a poor Linux user using 2.6.8, you can't read this page to learn why you can't read this page. Sorry.
Lameness with AT&T Wireless
As I'd mentioned earlier, one of my main goals was to do multi-target ringing when people called me. The "nugget" extension on my asterisk box simultaneously rings my desk and my mobile phone so callers do not need to know where I am to call me. This is great, but in practice I found that the voicemail on my AT&T mobile was interfering. The timing of that call is very unpredictable and I am having to drop to the asterisk voicemail after only 15 seconds to guard against the AT&T wireless voicemail system picking up.
So today I called AT&T to see if it was possible to disable voicemail on my mobile line. It took me two or three customer service reps before I found one that understood what I was asking. I think "opt out of voicemail" is the key phrase I had to use. Sadly, AT&T's handling of this request doesn't fix my dilemma. Now if my mobile rings through with no answer, AT&T's voicemail system picks up and asks the caller to enter the 10 digit number of the person for whom they wish to leave a message. It's like it drops the caller right at the base level of the voicemail system. I'm too demoralized to call back and see if there's a further option which will prevent their voicemail system from picking up at all. I do intend to leave it this way because I hated having voicemail on my mobile anyway. I'm all for simplifying and it's a pain in the ass to have to check for voicemail in three or four different places all with different commands and pin codes.
What's next?
I received my Cisco 7960 phone, but the power cable won't arrive until tomorrow. Today it sits, dark, on my desk and taunts me. I want to be playing with it. Also, my TDM400P from Digium won't ship until 4-Oct, so that experimenting has been postponed.
© Copyright 1995-2008 David McNett. All Rights Reserved.
