Home Routers w/ Decent QoS Performance? 52
danwarne asks: "With VoIP becoming rapidly more popular, quality of service (QoS) settings in home routers are also emerging as a key piece of functionality for the average user. QoS settings, which allows important or time-sensitive network traffic to be prioritized over less important packets, used to only be offered for corporate-level routers. Now, many hardware manufacturers have started including such capabilities in their mainstream routers, some doing it simply by a firmware upgrade without any change to the power of the underlying hardware. The emerging problem is that most home routers don't do a very good job at all with QoS, especially under heavy load (from P2P apps, for example), and home routers don't seem to have what it takes to prioritize sending Voice over IP packets first, leading to glitchy VoIP calls. VoIP operators around the world are facing this problem as they try to turn VoIP into a 'consumer-friendly' plug-and-play service. Does anyone know if someone has done extensive testing on home routers and modem/routers that investigates their ability to deliver QoS? Also, what hardware elements would be required in a router to do QoS reliably?"
QoS has to be supported on the other side... (Score:4, Insightful)
Consider the case of downloading a big file, and trying to do VOIP. The incoming VOIP packets and the incoming download packets hit your ISPs router.
Now, unless the bandwidth between you and your ISP's router is larger than the bandwidth between your ISP's router and the rest of the world, there will be an outstanding queue of packets to be sent from the router to your computer. If the router does not honor the QoS bits of the incoming packets, and send the VOIP packets first, then your VOIP will be choppy, even though your router is sending all outbound VOIP packets out first.
Moreover, even if your ISP supports QoS, if the machine generating those packets does not set the QoS bits correctly, there will be no way for your ISP's router to assign meaningful priorities - so even though you've tweaked your system to set the QoS on outbound packets correctly, if you are talking to Aunt Tillie, and her computer is not setting the QoS bits, then the incoming traffic will not be sorted correctly.
Bandwidth (Score:3, Insightful)
offtpc - run bsd server as firewall (pf settings!) (Score:5, Insightful)
...
OpenBSD would be great to learn on as it will definately push you into the documentation and get you used to some of the conventions used (slices v. partitions, startup scripts, etc.). I'd suggest you use an older or spare computer if you've got extra or can pick one up cheap. You could also just set aside space on those 80 gigs you've got. READ UP ON PARTITIONING, USE OF LARGE DRIVES, ETC. BEFORE YOU START ANYTHING!
Once you get some OpenBSD under your belt, put a box in service at your network connection (right behind you cable/DSL connection?) and learn to setup pf (packet filter - built in). Experiment with AltQ and get yourself a good firewall/NAT in place (junk the Linksys). Not too much trouble and the docs at OpenBSD - pf [openbsd.org] [openbsd.org] are quite good. Here you could experiment with adding a web server or MTA (if you don't have tons of boxen to keep your "real" services in some kind of dedicated DMZ). My home OpenBSD box forwards BitTorrent, Freenet, VNC and SSH to a variety of machines in my house. I also prioitize packets in the following order: 1st to tcp_ack_out, [then] Vonage telephone, ssh_interactive, everything else, freenet, and finally ssh_bulk. Keeps my phone line crisp and prevents freenet from destroying my ssh sessions' latency. You can do this with other products but I've had a good time (and have learned quite a bit) constructing my
Then build youself a FreeBSD box. This should be cake. 5.x should install without a problem for you and you've got access to all the ports you could ever imagine. Your experience with OpenBSD will help you understand some of the differences you'll encounter. Makes a great desktop. OpenBSD will work fine as a desktop machine but I've never done it. Same for NetBSD I suppose. Give it a whirl. I'm sure you'll learn a ton and be quite happy with whatever you decide.
Don't short yourself on learning OpenBSD. It is awesome, security aware and has some wonderful features (need encrypted swap case the feds might knock down your door at any minute? check.). It may just serve all your needs and knowing it is surely going to be useful to either yourself or others in the future. Use it for utility and the ability to sleep at night with your data behind it. (still better go with RSA keys on sshd though). Check out http://undeadly.org/ [undeadly.org] [undeadly.org]
Don't short yourself either on checking out FreeBSD. I moved from Linux to "the beast" some 5 years ago and haven't looked back since. The 4.10 machine I use everyday has been up 168 days as of today. I had at shutdown the machine previous to that due to a scheduled power outage. It sits fully exposed on an unprotected IP and runs user apps, a web server and mail. Not a single problem in years. FreeBSD has certainly served me (and some clients of mine) well.
If you're a system developer or like playing with things at the driver level or experimenting with new code, new systems or want to put your toaster on the network, don't deny yourself a NetBSD 2.x install. Wonderful features at the leading edge. Very capable and I hope to get some more experience with it myself one day. (a NetBSD page [starling.us])
Learn OpenBSD. You won't regret it. [FreeBSD and NetBSD will run pf as well]
Here's the juice: (yes - read the docs and modify for your own setup. The various sections need to be in a certain order too (options, normalization, queueing, translation, filtering)
Re:Commercial Products are Inadequate (Score:4, Insightful)
QOS is most freqently needed on upstream data since downstream has higher speeds. Since most ISP's don't support QOS at all, about the only place you have any control is upstream on the local loop.
Re:Not surprised (Score:3, Insightful)
A friend of mine bought one...
And if that anecdote were typical a huge community wouldn't have grown up around the unit and Linksys would be buried by the support nightmares.
It could be that your friend got a bad unit -OR- maybe hundreds of thousands of people don't realize that their units are crashing all the time. We'll let Occam's Razor decide that one.
Re:You have no idea what you're talking about (Score:4, Insightful)
Yes, I abused the terminology pretty badly, but I notice you didn't correct my explanation. Would it have been clearer if I'd spent an additional paragraph or two defining the words precisely? I doubt it. And I would have had to, because all of the previous conversation was misusing the terminology. Sometimes to communicate effectively you need to go along with minor errors in order to avoid clouding the main point.
As to your specific comments:
First off, you *can't* shape incoming data - you can *police* it, but you can't shape it (because you've already received it.)
But you can shape the future packet stream by dropping or delaying packets and provoking a reaction from the origin server. You could argue that you're not shaping the traffic so much as convincing the origin server to shape it, but what's the point in drawing that distinction?
Shaping refers to altering the traffic flow by delaying packets. You can't delay something you've already received.
That's a rather funny comment. If your job (as a router) is to pass packets along, of *course* you can delay something you've already received. It's usually simpler and nearly as effective (for TCP) to simply drop it, but you could certainly put it on a queue to be delivered a bit later.
Second of all, QoS does not shape or police data at all - it has to do with assigning priority, which the router uses for advanced queuing. Note that you can *use* QoS to shape your data, but not the other way around.
LOL. The sentence fragment you're disputing is: "you can still use QoS to shape incoming data streams." You contracticted that with: "you can *use* QoS to shape your data". I'm not pointing that out to imply that you're saying I was right but to point out that that *is* a useful way of describing the situation, even if it's not perfectly accurate.
Yes, I understand that QoS is really about prioritization of traffic, but unless you are actually trying to describe the distinct phases of processing in a sophisticated router, splitting this hair serves no purpose.
Also, 'reordering' packets has *nothing* to do with shaping or QoS. Reordering has to do with individual TCP streams.
That's one usage of the word. It also applies in other networking contexts.
Do yourself a favour and go get a *real* book on this stuff, you'll look like a lot less of a moron.
Try reading more than a single book on this stuff and you'll find that the terminology isn't as hard and fast as your narrow experience has led you to believe. Further, spend some time trying to explain complex subjects to non-specialists and you'll discover that perfect accuracy in terminology is not at all the same as effective communication.