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."
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.
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.
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
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.
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.
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