Slashdot Mirror
Home Routers w/ Decent QoS Performance?
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?"
WRT-54G(S) running sveasoft's firmware. Yes, some people question the legality of the distribution method, but at $60 for the router + $20 for the firmware subscription, it's an instant solution. I'm running it on a 1.5Mbps/96Kbps to manage bittorrent, emule, packet8, counter-strike, and websurfing, and it runs great. More important -- it passes the wife test (aka, she doesn't notice that I'm downloading while she's talking).
-- Is "Sig" copyrighted by www.sig.com?
Then install the Sveasoft firmware. The shipping version is free, access to the beta version & support for it is US$20. Some folks dissaprove of this strategy but the FSF has green-lighted it and it does pay for the project.
QoS, VPN (endpoints), SSH, filtering, upped antennae power, it's all there. They've extended the Linksys web interface to handle most of the expanded functioniality and below that there's a real working Open Source Linux with a happy command line.
Sure it's not an old clunker running something else. It's also small, quiet, stable, wireless if you want to take advantage of that. I dunno about you but being able to replace a 24/7 big noisy hot box in my living space with a smaller quieter cooler one is worth the small premium.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
A friend of mine wrote his master thesis about optimizing the usage of asyncrone internet connections (often ADSL connections). He used our dorm as a living experiement, we have 307 people living here, and share one 8196 kbit down / 768 kbit up ADSL connection. All our ports are open and everyone has a puplic ip address (well almost, because we only have a /24).
The results are very very good. The link is actually useable now. SSH connections are quick. people can and does use p2p without trouble. VoIP works most time of the day, but during "rush" hour it is not possible, most likely because we are just too many users for such a small connection. Games might also work at some time during the day, but i dont game so i wouldnt know. I do hear that some people complain that they can not game. The rest is good, SSH, HTML, news, irc/IM and other chats works as well. Try it, and you dont even have to limit your bandwidth.
http://www.adsl-optimizer.dk/ contains his master thesis....
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] 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]
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)
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)
The big issue with QoS is that your ISP also has to support it, or you don't get the benefit of it.
You don't get the full benefit, but you can still use QoS to shape incoming data streams, at the expense of giving up a portion of your inbound bandwidth.
The way this works is that although your ISP will send whatever packet is at the head of the queue, your router can still reorder the incoming packets before delivering them to your computers. That looks, at first glance, like a silly idea, since the router has the data and there is no bottleneck across your 100Mbit LAN, why shouldn't it just deliver what it gets?
By delaying, or even discarding, inbound packets, your router can use TCP's throttling mechanisms to slow the rate at which the origin server sends data. When the origin server doesn't receive acknoledgement that a packet was recieved, it not only retransmits that packet (after a delay), but it also adjusts the window size. This is a critically-important property of TCP. Without it, every connection that crosses a low-bandwidth link would suffer lots of dropped packets and would have lots delays during which even the slow link is idle. That doesn't happen, because TCP automatically "tunes" every connection to a rate at which the traffic flows smoothly.
When your router drops inbound packets of a download that exceeds the amount of bandwidth the router wants that connection to consume, TCP adjusts the data rate downward until not many packets are dropped.
So, if your router "knows" the total incoming bandwidth, and if it can track all of the incoming data streams, it can dynamically choose a target bandwidth rate for each of those streams, and then enforce that rate by discarding packets whenever the stream exceeds its target rate. Linux QoS capabilities also include "random early detection", which randomly chooses to occasionally discard a packet from a stream that is close to its target bandwidth, to keep it from going over even briefly.
The downside of this QoS is that in order to make it work effectively you have to make sure that the ISP rarely queues packets and hardly ever discards them. To do that, you have to configure your router to divvy up an incoming stream that is slightly smaller than you really have, because this sort of "remote control" of the origin servers' data rates is imperfect and you will get occasional "blips" of over-target incoming data.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.