Slashdot Mirror
Can Any Router Guarantee Bandwidth For VoIP?
cartman94501 writes "My wife and I use Vonage for Voice over IP at home, mainly for work-related phone calls so we don't have to give out our home number to clients and colleagues. Most of the time it works fine, but when I'm using BitTorrent or other high-bandwidth applications (purely for legal and non-copyright-violating purposes, of course), the call quality gets choppy. I have used my Linksys (not a WRT54G, so 'upgrading' it to Linux probably won't work) router's QoS feature to assign high priority to the MAC address of the Vonage box, low priority to the BitTorrent box, and medium quality to everything else, which helps a little, but not enough.
Is there a router out there that would allow me to reserve, say, 75-90kbps of bandwidth off the top for VoIP and never, ever allow any application to use that, regardless of whether there's a VoIP call going on at the moment or not?" (More below)
cartman 94501 continues: "That would solve my problem, but I fear I'd have to build a Linux box and learn all sorts of esoteric commands to really make that work. Are you aware of a commercially-available router that would allow me to accomplish this goal with some sort of ease? While I'm not prepared to pay four figures, I'm certainly not naïve enough to expect such a device to be available in the $50-100 range of your garden-variety wireless router. Wireless would be ideal, but if I could patch it in between my existing wireless router and the cable modem, and turn off QoS entirely on the existing router, that would work, too."
and a WRT54GL cost me $100 (NZD) so i'm assuming it's $60-70 USD and with DD-WRT will do what you want and more.
www.ipcop.org
www.endian.com
www.smoothwall.org
Full-featured firewalls, will run on old crappy hardware you got laying around the garage. All you need is two NICs. Viola. QoS no problemo.
Just disrupt the deflector shield with a tachyon burst.
I use a Dlink appliance that works well, requires zero configuration and is placed in between the router and the modem - Voip Internet Accelerator Intelligent Packet Priority Engine Manufacturer Part Number: DI-102 Never had a single problem over more than a year of use.
Interesting exploration of the issues here: http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx
Suppose your upload speed is 150Kbps. A single bittorrent packet is 15,000 bits, so it takes a tenth of a second. If there is a bittorrent packet in the router when the VOIP packet arrives, the VOIP packet still has to wait for the bittorrent packet to finish, which means waiting up to a tenth of a second. Even though the VOIP packet always gets priority over other waiting packets, it will often arrive when the router is otherwise engaged, and therefore likely to endure a tenth of a second delay, which is probably noticable. I suppose reducing the MTU might be a help.
While limiting bandwidth might help, VOIP applications are much more sensitive to ping than BitTorrent, so even if you save bandwidth just for the vonage box, you will still need to customize packet priority. My D-Link gaming router has some ability to do it, but if you want real QoS stuff, a linux firewall box is the way to go.
I have the Sunrocket "widget" (Linksys voip adapter) plugged directly into my dsl modem, and my router plugged into the widget. The widget is supposed to give its own data priority, but I've never seen any evidence of that.
But if all you care about is keeping BT from using the last XX amount of bandwidth, just dial your max upload and download speeds down in the BT client.
Between the modem and the router. Hook the phone into the adapter as usual.
The adapter is what guarantees bandwidth for your phone.
So don't keep us in suspense submitter, which model do you have?
You can load software on more than just the WRT54G.
DD-wrt works on quite a few devices:
http://www.dd-wrt.com/wiki/index.php/Supported_Devices
Used Linksys APs are fairly cheap and available. I bought a used WRT54GS V2.1 last weekend for $30. Loaded DD-wrt on it this afternoon.
Beta sux! Join the Slashcott! http://hardware.slashdot.org/comments.pl?sid=4760465&cid=46173047
Purchase a WRT54GL (not any other WRT54G, unless you know what you're doing) and install the Tomato firmware on it. Not DD-WRT, not OpenWRT or any of the others. Tomato has better QoS and Traffic shaping functionality than most commercial firewalls I run.
Short answer, not really.
Longer answer, any circuit where you don't have a predictable amount of bandwidth will be hell to build any QoS with. Pretty well any home user connection will be in this class. Most of the cheap consumer devices that claim to do this are relying on tricks that won't work in a heap of cases or worse are snake oil.
No device is going to be able to do a good job without a heap of background information on what your connection is an how it behaves, things like when the buffers for outbound traffic on the other end of your DSL line kick in and behave etc.
If you want to learn a whole bunch of esoteric commands and a bit about networking you should be just fine building something to do it with a Linux box =)
Alternatively you might get a 95% successful solution if you buy a consumer device and shape the internet facing interface down to a speed that you hope your circuit will never drop below.
I am a lawyer and this constitutes legal advice and I shall indemnify you against any losses arising from taking it.
QOS should work if you set it up properly.
No, it shouldn't. QoS only works on egress. You can't do any meaningful ingress QoS. All you can do is stop packets from coming past the router. That doesn't address the real problem which is that the ISP link is maxed out. In fact, if you start dropping TCP data that's in a lower priority queue than your UDP voice, it will cause even further issues as the sender will retransmit those lost TCP packets.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
What such routers are doing is only "outbound packet DSCP marking". In English this means that once you configure such routers, only the packets that you send out to the Internet will be marked to exibit the behaviour you desire; however... and this is a BIG however, the fact of the matter is that:
1) Whilst you have marked some packets high, medium and low pririty, your ISP and every other Telco/ISP on the Internet may completely ignore those markings (preferences) of yours.
2) In fact, some of them may "remark" all your packets back to the same level, effectively disabling QoS.
3) Most routers mark packets outbound, and little emphasis is placed on inbound marking. This is because by the time the packet gets to you, unless YOUR router is saturated the packet will get through with low latency.
In order for QoS to work effectively the following things must be in place:
1) Every single network device along your network path must support QoS. This is NOT the case with 99% of the Internet. Not because the routers aren't capable of such, but rather because the ISPs disable this function for customer marked traffic.
2) Even if every network device from your home PC, router, to your ISP, the 6 telcos in the middle of the Internet cloud and your destination website in China supported QoS, chances are they would not all agree on what each marking would mean, and therfore they would interpret them incorrectly (from your perspective).
3) QoS only comes into effect when a network point is saturated, during all other times of bandwidth being available, QoS has next to no effect.
Further,
VoIP is UDP based, and is highly sensitive to latency. The Internet is a place where latency is highly unpredictable and the more network hops (the further geographically) your packets have to travel, the higher the end to end latency will be; as such, VoIP is likely to remain a low quality voice transport for a while. Contrastly, your analogue telephone line, when you make a call from US to China, actually reserves an entire set of *dedicated* DS1 (64Kbits/sec) analogue pipes from one end to the other. In other words, there is zero sharing; hence the guarantee and high quality.
Perhaps one day, when all the major Telcos and ISPs have more pipe than they know what to do with, long distance VoIP will come close in quality to analogue phones... until then it's a complete crap shoot. You might get amazing quality to some locations on some days, at certain times 99/100 times, and to other locations 80/100 times the VoIP call is utterly useless.
In resume, you can tweak your home router all you want. It might help slightly since your router would become a saturated network point due to you using bitorrent simultaneously; however, the other 8+ hops to get to "China" are completely out of your control.
My recommendation is that if you have a say 1Mbit Up/Down pipe for broadband internet; that before you make your VoIP call, that you throttle your bittorent software (in the software itself) to use only 850Kbits up/down. VoIP protocols can suck up anywhere between 8Kbit/sec (highly compressed) to 110 Kbits/sec (uncompressed). So by leaving 150Kbits for VoIP, there's a good chance the VoIP and torrents can co-exist peacefully.
Cheers, ADeptus
No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
There are a few ISPs that have blocked VOIP, mostly (ex-) monopoly telcos in various countries that want to charge you by the minute for voice. But most ISPs, and especially non-telco ISPs, don't care, because voice doesn't use that much bandwidth (especially if you're using compression.) BitTorrent's a different game - it's using something in excess of 1/3 of the bandwidth on the internet, so there are reasons for some ISPs to care about it other than just greed and spite :-)
The real problem is that ISPs don't put VOIP on high priority, and applications like BitTorrent, ftp, and to some extent http want to suck down all the bandwidth they can get and fill up any network queues they can to keep the data flowing. ISP backbones are fat enough that it doesn't matter that they don't prioritize VOIP, but the link from their last switch or router to your house is a finite size, and BitTorrent can not only crowd out the downstream link, but can queue up enough packets that your VOIP traffic needs to wait a while for its packets to get through, and the gaps kill your audio quality.
Also, the most critical thing for your router to control is prioritizing VOIP packets on the upstream, but apparently that wasn't enough to keep the article poster's calls working well.
don't know if you were serious or trolling anyway...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I also use the Tomato firmware on a WRT54G, and I have exactly the kind of setup the OP describes. I don't even remember what kind of QoS came with the default firmware, but I never had any kind of luck with it, nor with DD-WRT. Tomato has been great so far.
Tomato actually offers fairly sophisticated QoS rules. You can set priorities by MAC address, IP address, port, etc. You can even set bandwidth caps for specific protocols/ports; so, for example, you can set the first 512KB of data transferred over port 80 to "Highest" priority, while anything after that drops back down to "Lowest" -- the effect being that regular ol' Web surfing gets a little kick in the pants, but extended transfers are given less priority. The latest release even added the ability to prioritize small packets (ACK, SYN, etc.)
What's more, Tomato also offers really neat graphing of your traffic. You can actually see, in near real time, what percentage of your outbound traffic falls under which priority category, with a nice pie graph. This is especially helpful when you want to double check that your rules are actually working (and you didn't make a typo when you were entering in a Mac address, for example).
One thing to remember when you're setting up QoS on a router like this, though, is that you need to reserve a certain amount of upstream bandwidth just to manage to QoS overhead. So, say you have 384KB/sec upstream bandwidth. You'll probably want to tell the router to reserve 40KB/sec or so for QoS. YES, that means your maximum upstream bandwidth will in effect be lower than what your provider advertised; call it the cost of doing business with QoS.
I have no empirical measurements to offer. All I know is that with the original, official WRT54G firmware and also DD-WRT I saw virtually no difference whatsoever when QoS was enabled. My outbound voice quality on my VoIP line was very choppy, particularly (but not limited to) when I was doing BitTorrent. With Tomato, on the other hand, there seems to be a marked improvement. I can actually hear the difference when I check and uncheck the "enable QoS" checkbox.
Breakfast served all day!
I've installed many VOIP systems in small to medium sized companies, and back when I first started doing it I learned a valuable lesson:
Your router can only control what it sees.
Seems obvious, but let's consider the implications.... Your router cannot do anything of meaning about incoming data. By the time your router sees it, it's already traversed your cable or DSL line and the damage has been done. Something like bittorent is throwing a ton of incoming bandwidth at you, and there's not much a consumer grade router can do about it.
The way I approach it is to use a small, but fully functional Cisco router at the client side, and work with a mom & pop ISP who will also throw some QoS on their router for that link. I won't accept a job installing a VOIP system for a client who isn't willing to go that route.
You have to give the *incoming* VOIP priority over the incoming torrent traffic, and for good results, this must be done at the ISP, before it has already clogged up your personal "last mile" link.
If you want to run bittorrent and VOIP on the same connection, you need a *real* router, and a cooperative ISP.
Torrents kill VOIP. The method I outlined is the only way, after several years of trying every idea and product out there, that actually produces reliably stable results.
The problem I have ran into time and time again is the WRT54G just doesn't have enough CPU power and RAM to handle the mess torrents make. Throw VOIP into the mix everything comes to a stand still.
I used pfSense but several distros as supported by some micro pc manufactures.
http://www.pfsense.org/index.php?option=com_content&task=view&id=44&Itemid=50
I'm currently running a NetGate device with a 500MHz AMD Geode processor and 256MB of RAM. $200 is a little bit on the pricey side, but it is tiny and fanless.
I work as a techie for a company that makes some of those business-level priced routers.
Obviously, you don't have any control of the prioritization of the packets after they've been sent upstream to your ISP; if ISPs were let you do that, it would allow everyone to mark all of their traffic as high priority voice packets, and all prioritization would go out the window. The best you can do is to make sure your outgoing voice packets are prioritized over other outgoing traffic.
It is possible to influence the speed of incoming packets using TCP windowing. When devices establish a TCP connection over the net, they gradually increase the number of packets they send before waiting for a response from the receiver. This is the TCP window size. As long as there are no dropped packets, you normally want the devices at each end to use a large window size so more data is transmitted before the sender stops to wait for an acknowledgment. Some QoS-geared routers
(like the ones made by the company I work for) can be made to voluntarily limit the TCP window size of incoming data, so the device at the far end will pause more frequently to wait for acknowledgment. This has the effect of slowing incoming TCP traffic. Since voice packets are transmitted as UDP, this can help make more bandwidth available for them. Bittorrent traffic is transmitted TCP, so this kind of traffic limiting may help in this situation.
KTHXBYE
Yeah, basic VIA board, under clock the cpu and remove its fan, thumb stick booting Monowall.
Never get any issues with that, and the cpu (even heavily under-clocked) never passes 5% usage.
...
What most people don't understand about TCP (and therefore bittorrent etc) and Cable Modems could fill a book.
The thing most people don't understand about cable modem is that it has virtually no buffer for outbound traffic (e.g. the traffic you do control) so subsequently it is almost a given that you will overrun the transmit buffer on your cable modem doing the simplest of things. This in turn will destroy all your throughput because...
The thing most people don't understand about TCP is that it accelerates linearly and falls back exponentially. So whenever you drop an acknowledgment frame (outgoing) then your incoming data session tends to stumble to a near halt. (that is each successful frame you send increases the transmit window by one frame, but each failure cuts the transmit window in half, and most failures cause at least two drops.)
This can be seen when you use a "near by" internet speed test (a la speakeasy) and you see the speedometer surge and fall like someone revving their engine. But each "fall" is actually a bunch of trash hitting your system and then getting discarded as the stream colapses back on itself.
Now for a cable modem provider, they have no interest in throttling data coming to you to your downstream cap. That would be expensive and would just clog up the memory in their routers. your downstream limit is really implemented as an aggregate of your upstream capabilities and how their time division multiplexer is configured to cascade into statistical multiplexing. (See Comcast's "speed boost" as an example of free-wheeling and only cutting back if it must.)
So anyway, I have posted my firewall and traffic shaper scripts to my slashdot journal. They are drop-in ready for Ubuntu and Slackware, minimal editing may be needed for RedHat or others.
Try them out. Be particular to tune the top of the shaper file for the upstream speed to match your _advertised_ cable modem rate (INTERFACE_SPEED=768 in the file) and then you can fine tune the numerator part of the fraction in CEILING=... (98 worked best for me).
I get my full 8M down PLUS whatever speed boost is doing (24M down often) and my VoIP works great, even during peak usage etc, while people are gaming and web surfing in the house (my house is a high usage environment with multiple housemates skyping and gaming etc).
On top of that, the script is actually _BENEFICIAL_ to my ISP. By shaping my outgoing traffic I waste virtually zero bandwidth on retransmits so I am a great net citizen.
(If you set your firefox to enable pipelining and set max pipeline requests to a value like eighty (yes 80) you will find that you are a most efficent and therefore quite spunky web citizen.)
Share and Enjoy...
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
you might want to check out Astaro. There's a free home use license. Traffic shaping lets you cap your p2p bandwidth, or guarantee bandwidth for your voip traffic. It can install on x86 hardware, so plenty of horsepower.
Actually, yes it should, as long as you also set your bit torrent to use a maximum of download bandwidth, and report as choked to the "supplier".
My parent was talking about QoS at the router, not at the application. There's a difference. In any event, bit torrent is one protocol. The original question was more general and mentions "other high-bandwidth applications." Most protocols have no BCN (backwards congestion notification) nor is there any link layer method for allocating bandwidth a la fibre channel, which uses buffer credits. TCP is an inherently greedy protocol. It takes all the bandwidth it can until it starts dropping packets and then backs off a bit until it does the same thing over and over again. This does not play well with VoIP and the only way to truly control it is end to end QoS, like what is done in the enterprise.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
I disagree with this and a number of other comments that say you can't do ingress qos.
Your voip traffic can get hung up in a lot of different places, but by far the most common trouble spots are your router (on the way out) and your ISP's router (on the way in). Other than those two spots (and the same pair for the party you are talking to), it is quite rare to experience jitter that would affect voip call quality. Egress is completely within your control, provided you know what you are doing and/or have the right equipment.
Ingress can also be controlled at your router in at least two ways:
1. modification of TCP window sizes (Packeteer has done this for years, and probably others do too these days).
2. selectively dropping packets to cause TCP flows to back off.
Number 2 is relatively easy to do with any device that can place bandwidth caps on particular flows. There is a common argument that says it does no good to drop a packet after it has already traversed the bottleneck. For UDP or most other connectionless protocols this is true, but for TCP (including bittorrent and every other bandwidth-hungry protocol out there) this is a misconception. TCP will respond to dropped packets by lowering throughput. It isn't as elegant or efficient a method as TCP window modification, but it is very effective.
Oh, and you can ignore pretty much everything anyone here has said about tagging unless you have a specific agreement in place with your ISP regarding tagged packets.
The built in QoS on all the open linux firmwares only does outbound QoS. You can use iptables on the linux firmware to do prioritization. Slashdot's filter won't let me post the script because of "too many junk characters" so sorry I can't post it. I didn't make the whole script up myself. There is a program called WRT54 Script Generator v1.02. What I've done is prioritize nntp based on ports and gave it 2-5000Kbps and TCP on port 80 and port 443 to something like 90% minimum of my max connection speed. The script uses the mangle option of iptables to effectively prioritize DOWNSTREAM http over nntp.
This was a huge find for me because an nntp download using 8 connections would kill my connection and trying to download a new podcast for example would take forever. Now, when something on http starts downloading, nntp goes to almost zero, and I really mean zero. It effectively gets killed until the http is finished. All this is running on a WRT54GL with dd-wrt but you should be able to use any of the other firmwares out there. You could easily do this same thing for VOIP. Just tell the script generator that you want your VOIP port to get a minimum of 500Kbps or whatever and it can get a minimum of that speed if it really needs it all.
If you do decide to use DD-WRT, consider the add-on scripts described here for TCP Vegas:
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=28816
To hell with DD-WRT, Tomato is a much, much better firmware with QoS services that work better than the Cisco gear I have at work. You can prioritize traffic to/from hosts, specific ports or even application signatures (note that if you do alot of sig matching it may affect performance)
I have a RR Pro account, and I can have a torrent box churn away while I play Counterstrike and my wife talks on the VoIP phone with zero problems.
Conformity is the jailer of freedom and enemy of growth. -JFK
You can indeed do ingress QoS. It's not as good as egress, but it's a very good approximation that provides perfectly adequate results in most situations. In response to packet loss, TCP and other protocols throttle themselves. You're helpless if someone wants to DoS you, but in almost any circumstances short of that, you'll be okay.
What you do is figure out your real-world downstream speed, then set your downstream speed to somewhat less than that (say 80%) to allow for a bit of overflow from TCP retransmits and higher priority traffic. Give the higher priority traffic a big queue that doesn't drop packets (eg no RED), and you'll get very good results unless someone is really out to get you.
The inability to QoS ingress traffic is very widely accepted, but what people neglect to consider is that we can use an approximation. A lot of problems never get solved beyond workable approximations. You're not going to get a network suitable for hard realtime data, but it'll be good enough for VoIP.
I rarely criticize things I don't care about.
I have got a fanless 1GHz Via C7 based pfSense box that has really nice QoS support for VoIP. Not to be trifled with..
I chose a VIA chip because they have hardware crypto acceleration for AES, taking the CPU bottleneck out of the way so I can VPN in from a Cafe or whatever. pfSense also has a newer FreeBSD kernel to support the hardware crypto accelerator.
I can even run ntop on it!
Here's the hardware:
http://www.logicsupply.com/products/perimeter_f
What about http://m0n0.ch/wall/
I use monowall and it works well with the following caveats:
1. It takes a bit of knowledge to learn to setup the qos, but this is true of any effective qos router.
2. It takes a bit of playing to get the pipe size right. Set it too high and it's ineffective. Set it too low and you're not utilising your bandwidth.
3. Your internet connection speed should be fairly consistent, otherwise you will be tweaking #2 all the way to an early grave. ADSL and cable are consistent in my experience, wISPs are not.
4. Your ISP can't be throttling you, as was mentioned by some others in this discussion, for that would effectively bring you back to the problem of #2 & #3.
I've used a debian gnu/linux install on old PII hardware as a router and I actually found the QoS to be unequalled. Once you learn the syntax of iptables (and a dozen other sysadmin skills) it works pretty much perfectly to preserve voip quality. For somebody that doesn't mind getting his hands dirty I recommend a linux router/shaper as your best solution
But, as the OP mentioned, linux is a bit dreadful to set up as a router for the uninitiated. (I haven't tried IPcop or any of the dedicated solutions so I can't speak for those.) For somebody that likes a nice shiny push-button interface, you can't beat m0n0wall, and like I said, with a bit of playing around it too can be very effective at preserving voip quality.
And to those who recommend limiting your torrents to 15% of your max bandwidth: your heart's just not in it. I want my torrents now. I don't want to have to run turn down my torrents every time the phone rings, and I sure as heck won't remember to turn them up again when the call's done. It's a beautiful thing to watch a torrent upload at a steady 100% of your uplink speed, get on the phone, and see your torrent continue at 100% minus 86 kbps while enjoying a phone call with flawless audio, then see the torrent fill up the gap as soon as you hang up. Geek's paradise.
db
I am literally 3000 tokens away from the chaotic crossbow --Stephen
Tomato is really a great firmware, I think it is the answer to the initial post's problem. It really has a great interface and is easy to configure, DDWRT was nothing but headaches for me, and the QOS (When I used it a year ago) was absolutely broken.
here is a guide on configuring QOS, http://www.decimation.com/markw/2007/10/03/tomato-qos-setup/
Also it has great graphs such as realtime usage (tx and rx) reports http://en.wikibooks.org/wiki/Image:Tomato_Firmware_-_Bandwidth_Real_Time.PNG
And I can see a graph of exactly what percent of my traffic falls into which QOS classifications. http://www.polarcloud.com.nyud.net:8080/img/ssqosg108.png
I'm able to quickly check if anyone has been abusing the wireless, and see what percentage of my traffic is bittorrent, nntp, gaming, etc, If some device on the network suddenly started flooding traffic over port 25, I would know about it, all in a nice and easy color coded graph, check it out, I bet you will like what you find.
Web Developers: Celebrate to our roots! Animated Gifs and Tiled Backgrounds, dont let our history die!
you might want to check out Astaro. There's a free home use license. Traffic shaping lets you cap your p2p bandwidth, or guarantee bandwidth for your voip traffic. It can install on x86 hardware, so plenty of horsepower.
Astaro's web site is http://www.astaro.com/ and their community support forums are at http://www.astaro.org/
It needs a PIII or better, with 512MB RAM or more, but is VERY full-featured... VPNS, SMTP relay, http content filtering and antivirus, QOS, ...
Nothing to see here; Move along.
I agree, Tomato is a great firmware. Two important tips: 1) Do NOT set any of the "Prioritize small packets with these control flags" boxes. If a high/full speed torrent runs it will have a lot of those packets and it will kill any potential benefit of the QOS. 2) After trying Tomato, if you want to get even more speed out of your router try the speedmod: http://touristinparadise.blogspot.com/2008/04/linksys-wrt54gl-routers-improving.html More details there. PS: DD-WRT works fine too but the GUI of Tomato is so slick and user friendly that I don't want to miss it anymore.
The stock Linksys firmware didn't do it; its QoS features were pretty much worthless IMO and the stock tuning was regularly overloaded due to too-long TCP timeouts and the pounding the thing got from The Bad Guys.
DD-WRT allowed me to tune the settings to the point that it worked slick-as-you-please. There were a couple of critical settings.
First, I boosted the number of active connections allowed to the maximum, 4096. Second, I dropped the TCP/UDP timeout to 10 minutes. These two made all the difference in terms of stability; without them the connection count would rise to saturate the table and things would fall apart fast.
With stability in hand the next thing to do was QoS. I chose to cap bandwidth at about 80% of available and then give priority to the Vonage box's port. This worked neat-as-you-please; the phone never had dropouts and everything else kept going smoothly.
jim frost
jimf@frostbytes.com
Your router can only control what it sees.
Seems obvious, but let's consider the implications.... Your router cannot do anything of meaning about incoming data. By the time your router sees it, it's already traversed your cable or DSL line and the damage has been done.
For TCP connections your router could control the window size of the connection by rewriting outgoing packets. If you put a cap on the window size it would keep your throughput low. Your router would need to keep some state on TCP connections, you could probably get away with just the number of active TCP connections. Of course this wouldn't help with anything UDP based.
You can just get the Vonage Linksys: WRT54GP2. Has built in vonage and QOS for it.
Yeah, then watch it crash on a daily basis if you try to run bittorrent? No thanks. (speaking from experience here)
After plenty of trial-and-error, I've found a router with Tomato installed and QOS properly configured to be the best solution.
Priotizing bandwith with the Linux kernel's de-facto standard shaper HTB is not the correct approach if you care about latency. Nevertheless 95% of the internet's advise points exactly into that direction. What most people don't know, Linux already includes a shaper being able to make realtime scheduling guarantees: HSFC. It is a little bit more complicated to setup, but my box is able to give me 15 ms VoIP delays in parallel on a congested line (2000+ bittorrent peers).