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."
Most gaming routers allow for this kind of functionality. In fact the first search result on google for 'gaming router' brought me to a product from dlink that provided exactly that.
Perhaps try picking up a WRT54GL and installing Tomato on it.
firmwares. It would help to know what router you have.
If you have the Vonage box prioritized, and the BT box bulked,(set for low priority) that should completely eliminate your problems, if it isn't, either you didn't set up QoS properly, or the QoS sucks and doesn't work.
For my setup with VOIP, I use a WRT54GL, with OpenWRT. Before I setup QoS, I experienced the same problems you did, but after I did all the problems went away.
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.
If you're running a business, your first worry should be about servicing your customers not using Bittorent. Get another DSL/Cable/Wifi connection for your business and run your VOIP over that.
If you only need the limited bandwidth that you are looking for you'd be fine with the lowest speed (read cheapest) connection any ISP offered.
Interesting exploration of the issues here: http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx
QOS should work if you set it up properly.
On my WRT-54GL with Tomato (others might work, Tomato is the easiest of ddwrt, openwrt in my experience), the QOS settings can be limited in just the way you want, with everything except the highest only being allowed only 75% of your upload, or whatever you want.
Downstream is a bit harder to restrict, since the queue is on the Telcom side of things, but you could do some QOS in your router there as well.
If I have nothing to hide, don't search me
I have heard that most ISPs put VOIP packets on super-low priority anyway, so even your setup at home won't affect it a whole lot. I may have heard wrong, though.
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.
Handy man!!!
It is pitch black. You are likely to be eaten by a grue.
http://openwrt.org/ (extend yourself, open, maybe takes longer to set up)
http://www.dd-wrt.com/dd-wrtv3/index.php (web interface like normal, just tons more options)
both should do the trick and maybe even run on your router
check:
http://www.dd-wrt.com/wiki/index.php/Supported_Devices
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.
You can check the DD-WRT support list at
http://www.dd-wrt.com/wiki/index.php/Supported_Devices
to see if your router can maybe use that firmware which supports the reserving of bandwidth. It might be complicated to install for some routers but there are often step by step instructions that work out pretty well.
The easiest solution for you is probably just to limit your bittorrent client's upload and download rate to maybe 70-80% of your maximum so that there is always enough bandwidth available.
However, there are a couple of things to bear in mind before you go to any expense in buying a bandwidth reservation device.
1. Yes, prioritisation of VoIP packets is part of the way to go but even though you set up prioritisation at your end of things, how do you know your ISP or any of the interconnecting providers are going to preserve that prioritisation? Routers do weird and wonderful things with packet queues and remarking packets such that the priority you sent the packet with is not necessarily the same the far end receives it with.
2. Bandwidth reservation is all fine and dandy as long as reserved ALONG THE ENTIRE PATH of the call. Sure, your broadband connection is theoretically the lowest bandwidth part of the path - but what happens if your ISP hits a congested period?
With point 1., you can at least packet sniff both ends to see if the prioritisation is preserved but unless your ISP can reserve bandwidth for VoIP, I'm not sure that a router that does it at your end only is going to be much of a guarantee of overall service.
Gentoo Linux - another day, another USE flag.
Between the modem and the router. Hook the phone into the adapter as usual.
The adapter is what guarantees bandwidth for your phone.
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.
You answered your own question, buy a newer Linksys (or other supported brand) router model that you can get one of the many Linux firmwares (dd-wrt, open-wrt, etc.) onto. They all have QoS sections in their web gui's that are somewhat simple to use. The big thing to remember though is that bit torrent uses hundreds of connections that can build up at the ISP side and give you horrible latency and jitter so to avoid that you may have to severely restrain your torrents.
The problem is related to the amount of traffic coming to you from the internet. No amount of QoS applied to your router will be able to shape the traffic that is piling up against the provider's side of the link to your house. That leaves you with 2 options:
1. If your BitTorrent client supports it, set the maximum download rate to less than what your internet connection speed is. I won't guarantee this will completely solve the issue, but it should help.
2. Don't download big files while you are using your VoIP phone.
This has worked for me, no regrets.
Hook the Vonage box up to your cable / DSL modem, then hook the router up to your Vonage box. This way, Vonage can starve the network when you're on the phone.
Once you're past the router you'll also have the problem that your ISP may not be honoring the QoS tagging of the VoIP traffic or otherwise identifying it and giving it priority. (In fact they may chose to identify it and give it LOWER priority if it's not theirs.)
So fixing your router may only be half the solution: It may throttle back your BitTorrent traffic to keep from stepping on the VoIP packets on the way to your ISP's first box, only to have it stomped by somebody ELSE's BitTorrent (or whatever) traffic on the next hop.
This, by the way, illustrates both halves of why "network neutrality" can't be just "treat all packets the same". You have to give the VoIP packets priority in scheduling over the BitTorrent packets to get them to work well (which doesn't do anything but slightly slow BitTorrent). But the tools to do that also give an ISP the ability to give the VoIP packets for their high-dollar service priority over BitTorrent while letting their competitors' VoIP packets fight it out, or even be handicapped further. Now try writing legislation to mandate the first while forbidding the second.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I've tried Sonicwall in the past, and it had a bandwidth limiter in its configuration. The price is reasonable and the configuration doesn't require extensive knowledge of routers.
Routers are cheap. Buy a WRT54GL. Note the 'L', this is the "Linux" version and is more or less equivalent to a WRT54G, version 4 (v5 is when they started to suck). Install dd-wrt, the flavor with QoS.
I have basically the same setup as you, Vonage, home network, occasional BT use. dd-wrt is configured to give highest priority to the port the Vonage box is plugged in to, and bulk (lowest) priority to traffic in the bittorrent port range. Works very well for me.
All the QoS settings are in the dd-wrt GUI, you don't need to know Linux per se.
Wouldn't it be a lot easier/cheaper to just use your bittorrent client, almost all of which let you configure the amount of bandwith it uses and when?
DD-WRT is your answer. Google it!
-- By all means let's be open-minded, but not so open-minded that our brains drop out.
You might as well just get yourself a power-efficient linux-powered router and set up tc properly to guarantee an uplink bandwidth slice to VOIP. (There are various recipes on lartc.org to help you with this.
Downlink bandwidth management is slightly more complicated, but you can sort of manage it by droping or delaying non-voip packets which are coming in too fast to keep your ISPs queue empty.
http://www.donarmstrong.com
I also use vonage and had similiar issues. To fix them we delved into the vonage box and gave it a static IP that wasn't assigned by our router. Next turn on DMZ Host for that specific static IP address. Then we also turned on QOS to highest level for the port it was plugged into or you can do it by IP depending upon your router. QOS, DMZ host, and a static IP like that fixed all of our problems with quality. Now we get excellent call quality even while downloading at 1.5 Mb/s and uploading at 95Mb/s (nearly max for my house's connection).
Inherited Will. The Destiny of the Age, and the Dreams of the People. These are things that will not be stopped. As l
I know you're looking into the router, but another option is to impose a limit in your BitTorrent client. I know UTorrent has functionality for restricting upstream and downstream speeds. Perhaps the client you are using has the same capabilities. Or perhaps I'm just made a worthless point, let the mods decide!
-
Soon to be modded -5 retarded, Bob
In a word: pfSense. There are other options; but this 'appliance' installation is a solid, free, powerful product. I suggest you take a look. Just turn off dhcp on your linksys and use it as a wireless access point. I also suggest using a mini-itx board and case to keep power and size low. Possibly using the new Intel Atom; but you'd have to verify it will work on that hardware; I expect that it would.
This thing is supposed to be pretty idiot-proof and can be found for $30-$50.
http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&pagename=Linksys%2FCommon%2FVisitorWrapper&cid=1146774321820
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.
Proper QOS is not the same as bandwidth. You could reserve all the bandwidth you want but if you've got bad jitter then the call will still be hopeless.
Pausing bittorrent during calls is one solution. You could implement QoS so the other party can hear you, but for you to hear them your ISP really needs to apply QoS
Bandwidth is important to make sure your data arrives in a timely manner. However, there are other considerations when you are dealing with VOIP- mainly packet order and jitter.
I would recommend that you do a packet capture (wireshark) and take a look at the time between packets arriving. Also, pay attenation to sequence numbers. One or two every here and there can be compensated with, but if yours or the ISP's router buffer is delivering packets out of order (or even worse, dropped packets), then that's another problem you need to look into.
Grump
(former VOIP engineer)
Is it true that more people vote for the winner of American Idol, than vote for the president? -Ali G.
My SpeedTouch 546 will do this, I think all the SpeedTouch routers will. I don't think you can do it with the web interface, but you can with telnet or by editing a config file. You just turn IPQoS on and the default ruleset prioritises VOIP and shares bandwidth fairly between the four ethernet ports. In fact, it might be on by default.
Speedtouches are very capable little routers under the hood. In addition to the usual 1:many NAT, firewalling and port forwarding, mine is currently also doing proper NAT (I have a public IP block) and IPQoS. The firewall is based on chains, so is pretty flexible. I think they run pretty much the same firmware as the "business" routers which are 5x the price, but with a dumbed-down web interface. If you don't mind a command line (it's quite a nice CLI for an embedded system - on-line help, interactive command entry and a command history) they'll probably do everything you'd want a router for a small network to do.
Chernobyl 'not a wildlife haven' - BBC News
You can shape the outgoing traffic, but not the incomming one. Even if that is bandwidth-limited by the application, different bittorrent senders will create bursts of incomming traffic when their traffic combines. There ia absolutely nothing you can do about this, except haveing more bandwidth available than the combined maximum burst speed of the incomming traffic.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
pfsense
I use Vuze (Azureus) as a torrent client, which lets you limit the up and down bandwidth of torrents. Not sure what you can do for intensive browsing, non p2p downloading and voip though.
Too bad it's Vonage. If you get VoIP through your ISP and they provide services such as 911, chances are they already do this kind of thing for you out of necessity. VoIP traffic is generally given the highest priority in order to ensure call quality for emergency situations. It would rather suck if a torrent kept the ambulance from being dispatched while you're having a heart attack, so ISP's have the ability on their end to isolate the VoIP traffic in a way that not all services can (Vonage) in order to make sure this doesn't happen. /disclosure: I work for a business that provides VoIP to Cable Companies
It isn't "esoteric". Do some research and you will find it is not that hard, and it does work fine. However, I have to dump Vonage anyways... Even with it being plugged DIRECTLY into the cable modem it doesn't work as well as it should. I've been a Vonage customer for 3 years...and I'm canceling my number this weekend to switch to Skype. I have had zero Skype problems whatsoever, and it is 1/3 the cost for the same features (minus 911, but you can always call the emergency departments directly)
I use Vonage for VOIP as well and I use BitComet. I too has the same problem, but I solved it without a router.
Vonage requires a minimum of 20-30 KB/s upload and download to work well. BitComet (and other clients) allow you set the maximum bandwidth usage. When I limited the maximum bandwidth in the BitComet settings to 30 KB/s less than my maximum upload/download bandwidth, it solved all of my problems.
Perhaps this would work for you too and be a less expensive option than purchasing a new router that would effectively do the same thing.
I have found that when I'm riding my motorcycle down the freeway at 90 mph, it becomes difficult to light my cigarette. Can anyone recommend a better lighter?
VOIP traffic needs to get good bandwidth in both directions - inbound and outbound. Your router can prioritize outbound traffic so that VOIP packets always go first (assuming it can recognize VOIP), but there's it can't control inbound traffic because the bottleneck in that direction is the DSL/cable link from your broadband provider to your router, not the Ethernet from the router to your PC. In theory, your ISP could offer QoS features and if the people you're talking with sent you properly marked packets it could do the same, but it practice that never happens with consumer-priced services.
So how can you restrict the speed of incoming BitTorrent traffic or other kinds of high-volume traffic? You're basically trying to get your router or your computers to tell the far end to slow down.
If you're only running one BT system, you can use a BT client that throttles traffic, and set it to a level that'll usually leave your voice usable. It's not perfect - BT is typically sending requests for blocks to a bunch of different peers, and the peers are sending those blocks when they get around to it, and if you're talking to four peers they might all transmit the same millisecond, but at least on average you can get some control that'll help.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
You're fighting the age old P2P battle my friend. Sysadmins and service providers have been waging this war for years; how do we allow for both... truth is, you don't. Because P2P applications more often become popular because of their illegal content avilability they are developed with this in mind. QoS unfortunately can help but it is marginal at best. QoS prioritizes packets based on characteristic matching, be it DSCP flags, IP address, port matching, w/e. The fact of the matter is the router has to do SOMETHING with each of these packets. P2P apps often create massive amounts of SYN traffic as it tries to establish connections with peers in the "swarm". The cheap $40 off the shelf "home-use" routers may have 8MB of RAM, and maybe a Citrix 133MHz (if your lucky) processor. As it attempts to throttle the traffic it has to work very hard. If QoS is available for your computer (where the traffic is originating) you may be able to configure it to shape the traffic before it overwhlems your box. Long story short, use a separate connection for your P2P stuff or upgrade to a business class router that can handle the traffic. A nice Cisco unit will run you about $3,000 or a second ISP $40/mo. You can sometimes find used equipment from businesses upgrading or going out of business that can still meet these needs but give you a nice price break. I would expect to spend about $1,000 for something worthy of attempting P2P traffic shaping.
In my experience DD-WRT QoS features don't work in the latest release. You're better off buying a tomato compatible router and flashing it with that firmware. The other option is OpenWRT but after reading the installation guides it doesn't seem so easy to get working.
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 been a VOIP user in Australia almost since the very first VOIP PSTN services were offered to the general public about four years ago. I understand entirely the issues described in this posting. But its more complex than what you might thing.
What exactly sounds choppy? Does the far end caller sound choppy to you, or do the people you're talking to complain that you sound choppy, or both???
Implementing a QOS router only helps in the UPSTREAM direction - that means the people on the far end are likely to hear you better (less choppy for them) but it will make NO DIFFERENCE to you. I'm presuming you've got switched and wired Ethernet between your router and your VOIP Analogue Telephone Adapter and the Ethernet is substantially faster / non-blocking compared to your broadband connection.
After years of complaints from my wife and family, I finally got a workable solution that pretty much makes VOIP sound better than our crappy 5km analogue PSTN line....
1) I implemented QOS in my router
2) I got the router to identify P2P traffic specifically and limit its maximum rate both upstream and downstream to about 100 kbit/s less than the nominal DSL line rate.
3) I configure my bittorrent clients to limit traffic anyway, although this is probably paranoid.
4) When my wife calls down expletives from upstairs, I immediately stop the bittorrent client and go and hide.
Are you getting a feeling now for how the problem can be addressed??? I suspect that while ISPs offer 'best effort' internet services, VOIP and Bittorrent are going to be difficult to mix.
I also took a fifth action which was the best 'solution' of all - but still not perfect.
5) Subscribed to the fastest DSL service I could get - which for me turns out to be about 4M downstream and 384k upstream (sadly, that's all you can achieve on long crappy lines like mine) - but it worked. Mind you, It was the FOURTH ISP I churned to that got it working - the other three implement 'shaping' which (GRRRRR) cannot discriminate between P2P and VOIP - and VOIP calls were constantly dropped after about a minute if I had a torrent running.
Good luck. But watch out for QOS services from your ISP some time in the next decade.
Do we really need requests for commercial product recommendations on the front page?
Why not just get your VoIP through Comcast? They'll have no problems throttling your bandwidth for you for no extra charge.
If the calls sound choppy to you, then the problem probably is the incoming bandwidth, which a router on your premises is not going to be equipped to solve. By the time the packets come in to your border router, they've already occupied the bandwidth that you would be attempting to reserve.
May I suggest this fine combination between a firewall and a VOIP system. Just look here for more info.
See, here's the problem. With QoS on these routers, you only have actual REAL control over what you transmit, not what you receive, and since you're receiving data across the internet, all the QoS bits on your inbound traffic from Vonage are thrown away as soon as they hit a backbone router.
So, yeah, you can control how much bandwidth on your outbound you allocate to VOIP traffic, but your bottleneck is not on outbound (if Bittorrent is what is causing your problems), but on traffic coming in. The best you can do is have your router drop non-voip packets inbound, and trust that the sender will slow their rate and retransmit. But, if they do, your BT client might try to compensate by the reduced flow by trying to connect to more peers. And, even if it doesn't, you're still having to receive the connections, determine whether they're VOIP traffic or not, and either pass or drop them. Your pipe is hammered and filled before your router ever gets a chance to do any QoS.
Basically, unless you control both endpoints and all the links in between, you cannot have real, hard QoS. You can "hope for the best", which is what you've got now.
Some routers do bandwidth limitation by limiting average bandwidth. That is they send at full speed, pause, send at full speed, pause.
That's not good for VOIP as it hoses your latency, but it's going to be fine for SMTP. Maybe yours does that.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Basically the issue is that your router can prioritize outgoing packets, but your ISP controls the priority of incoming packets. The only sensible solution is to bandwidth limit your other uses (most bittorrent clients can do this) so that there's always spare capacity for VOIP.
If only there was some way to route analogue sounds signals over some unused bandwidth in those internet wires that you have coming into your house...
Why not just set up plain old telephone call forwarding, and get calls to your business number routed to your home number?
A pizza of radius z and thickness a has a volume of pi z z a
The problem isn't your upstream (IE, from you to the ISP), it's your downstream (from the ISP to you). You can control your upstream with QoS settings on most good routers (although you need a 'real' router to get true QoS handled in hardware - most of the software implementations in the little SOHO routers suck badly), but you are at the mercy of your ISP for your downstream. If you are doing anything that pulls large amounts of data toward you (IE, downloading), it is far more effective to have the application do the throttling than the router (the router will just drop a ton of inbound traffic on the floor which is rather ineffective since you will usually have a much higher bandwidth on the LAN side than the WAN side in the first place). As for bittorrent, limit the number of inbound connections and limit the bandwidth per connection in the application, that will be most effective...
Your best option is to get a SIP ATA (analog telephone adapter) that has a router built-in. I have personally used a Grandstream 486,and they work great. Vonage uses SIP and I have read (but never tested myself) that you can use any SIP compliant device with it. The difference between Vonage's ATAs and others' like Grandstream's is that Vonage's are locked down to only work with Vonage.
So you would go from your DSL/Cable modem to the ATA/Router then to your Wireless/LAN access point or switch. If you would prefer to still use your wireless router for everything you could set it up in a DMZ on the ATA and put the ATA on a different subnet than the wireless router.
You can only half do it. QoS means prioritising packets - sending important packets before less important packets. So, you can prioritise VoIP, outbound. You can't do it inbound - only the router at the other end of the link can do that - and since that belongs to your ISP, you can only do it in one direction, unless your ISP offers it (unlikely on a non-business type product). You've also talked about bandwidth reservation - same deal applies. Since a voice call goes in both ways, I think you can get the idea. Good luck!
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!
Don't most of the good BitTorrent clients let you throttle how much bandwidth you want to let it use?
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,
Check for firmware updates for your router. Consider purchasing a new router. At most it will help a bit.
which helps a little, but not enough.
As you've noticed, evidently.
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?"
Well, first off that would be a pretty stupid waste of capacity. And secondly, no, if the packets are flooding in from the outside, even if your router is rejecting them, they are still flooding in saturating the pipe.
There are 2 things you can do:
1) Throttle down your bittorrent at your end, to limit its download rate. That will keep peers from saturating your incoming link.
2a) Contact your ISP and see if they offer QoS service, which means they will prioritize your VOIP packets through their network, and their routers.
Shaw in Canada for example offers it for $10/mo
http://www.shaw.ca/en-ca/ProductsServices/Internet/Internet+Explained/QoSVoIP.htm
In theory this is the best solution. In practice, its somewhat controversial.
Some have alleged shaw and other ISPs deliberately manipulate competitors voip traffic to promote its own voip offering. While this is possible, in my experience that isn't the case at all [at least with shaw].
Others allege that its a 'scam' to let shaw squeeze more money out of people and has no effect. But to counter that I have heard of cases where people have found QoS made a big difference.
Still others claim that QoS should be free and automatically applied to real-time apps like voip, video chat, etc and refuse to pay for it. But that's a separate economics issue.
In my case (on Shaw) I use primus voip and have no trouble, except when torrenting, but throttling my torrents seems to generally resolve the issue, and I've never tried their QoS service. I also mostly torrent at night.
Bit-torrent is a HUGE resource hog and pretty much all consumer routers barely can keep up. Bit-torrent can generate hundreds up to several thousands of connections which fills up the iptables in the consumer router very quickly. There isn't enough memory or horsepower in a typical Linksys or D-Link router that can really keep up with it. Poor VOIP connections confirms this. Best bet is setup a Linux router using IPCOP (www.ipcop.org) and it's really easy to setup and configure. This way you can customize the hardware anyway you want to suit your needs. What's more you can easily add more features to it like OpenVPN. If IPCop isn't to your liking there are plenty of others out there. Take my word for it, you outgrew that Linksys router and no firmware will 100% fix it regardless of what people say. Good luck.
Dlink DGL-4100 router has traffic shaping that YOU specify. I play online games and use BitTorrent at the same time with no trouble now that I got the gaming router with the traffic shaping ability. It's WICKED nice. A bit pricey, but my lag spikes are gone, and it goes nice and smooth. This may help your VOIP blues.
I used to work for a VoIP company, although on the IP side of things (so i'm no expert on the edgemarc), and we looked at using Edgemarc as our CPE for businesses. These devices can be statefully aware of active voip calls and when there is bandwidth contention, it can adjust the tcp windowing of your non-voip traffic which slows the remote host's transmission of data. it's a reactive solution and the edgemarcs aren't cheap, but businesses use them. don't hold me to it, but it might be worth checking out. i think they make a few SOHO models.
Call up ImageStream (http://www.imagestream.com) and check out a Transport router. They are essentially just a small PC running Linux. I believe they go for about $800, but they are rock solid and extremely beefy.
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
>> 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?"
Why completely block out bandwidth even when you're not using the service that uses it? that seems kinda silly overkill to me. Packet prioritisation is much better.
I expect your actual problem is either:
1) Your bittorrent client doing all it can to make your bittorrent traffic not look like bitttorrent traffic so that your ISP won't throttle it, so your router can't prioritise it either.
2) Your ISP is recognising you have a bittorrent going on, and is flooding you with RST or SYN packets in order to limit your download speed, which is also having an effect on your voip call.
see http://torrentfreak.com/comcast-throttles-bittorrent-traffic-seeding-impossible/
1. If you have a good ISP all you need to do, it's to make sure you never use 100% of available upload or download. To limit it to 99% use NetLimiter on the PC or configure QoS on the router. Linksys WRT5GL + tomato firmware is probably the cheapest and still fully reliable device to use. 2. Your ISP sucks, in this case you have to limit also the number of connections you make. Tune down Torrents max inbound and outbound connection until your VOIP is working properly.
Love many, trust a few, do harm to none.
It is not possible to QoS inbound traffic, so you have to QoS outbound traffic on both sides. We are a Business VoIP service provider and here is what we do:
Juniper M20 QPP CHDS3 QoS / Tag VoIP traffic with highest priority ==T1== Customer Adtran 1224STR with QoS
This allows us to QoS traffic in both directions on the T1. You cannot do proper QoS with just one end device... sorry.
ImagePut - Free, Simple, Fast Image Hosting
I would recommend a Mikrotik, fairly cheap for all the options you get on then. I got one of the 450 models, and the board, case, and power supply will hit you for around ~100. It has a nice GUI interface for configuring everything.
Mikrotik Website
Router Boards
I use a reasonably cheap PC setup for my boarder router (used to be just a 486) and have flawless Vonage VoIP service.
The thing you are doing wrong is that you are not _THROTTLING_ the link from your router to your cable modem.
In point of fact, and sadly, there is virtually no buffer for outgoing data on a cable modem. If you are configured for 768kbps upstream then sending data any faster than that will lead to all sorts of misery.
So in a properly configured firewall you want to throttle your _outgoing_ data to about 99% of your rated upstream bandwidth and _then_ use packet shaping to make sure that the right kind of packets get to "go first" in the QOS stack.
This turns your router into the buffer that your boundary modem lacks and will both make your VoIP flawless _AND_ _VASTLY_ improve your TCP/IP (web etc) throughput.
I have six ranks in my QOS gateway:
1) TCP ACKs (actually tcp packets less than 80 chars in length)
2) SSH (for emergencies)
3) VoIP (udp from my vonage device)
4) special occasions (none of your business 8-)
5) Games (udp in general)
6) Everything else.
Doing both of these things together will speed up everything in your house (including bittorrent) and leave you with outstanding voice quality even when gaming and running bittorrent while watching video on demand.
If found the basic rules files searching aroud the net, and then tweaked them with dynamic math and weightings.
Flawless.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
You can set a set of bandwidth priorities in rules, which can be protocol and/or IP based, and when that rule is not in use, the bandwidth is available for other apps, but when it is, it gets its guaranteed bandwidth.
It's even got a topic in the Vonage Forum (which would have been the right place to ask this question).
I've tried a program called cFosSpeed (Windows only I think?) that prioritizes packets quite well. The main point is to keep latency as low as possible, especially during uploads, and I think it would work quite well for VOIP.
Most QOS stuff on routers is rubbish, the pfSense system works very well. It needs some understanding and effort to set up (the wizard isn't that good) but you won't find a more effective system.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I totally agree with what CommKing said. You can only do half of it. You can prioritize traffic from you to your ISP. They must prioritize traffic outbound from them (inbound to you). Also, you cannot deal with congestion in any other part of the network, than the link that you are connected to. There are things that you can do to mark your traffic, but you cannot force a certain behavior at equipment that you do not have control over. Most VoIP happen to work as well as they do because a lot of traffic is TCP and VoIP streams are usually UDP. A lot of UDP traffic will cause the TCP to slow down because it will cause some packet loss. UDP is connectionless and can easily consume bandwidth. So if there is a case of multiple UDP streams fighting for bw, there can be some issues. Also keep in mind that the ISP can choose to throttle you based on your use of bitTorrent. Whether one agrees or disagrees with that is another topic. So to answer the question you asked, yes a router can guarantee bandwidth. However, a single router cannot guarantee two way bandwidth through a network with many hops.
Have you looked into the Sonicwall TZ line? I have a TZ-170 that will do QoS tagging. The TZ-170 is a few years old at this point. They offer a wireless version of it. You're probably looking at ~$500 once you include the advanced firmware. It might be overkill for your situation.
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".
It must have been something you assimilated. . . .
I run a WRT-54G router with the stock firmware. And I run two Vonage lines over my cable modem which has about 256Kbps upload rate. the easiest thing to do is to find the mac address of your phone adapter and set that device to be high priority and then set your upstream bandwidth setting just a little below what you get from your ISP and it works everytime. I've done this on two ISPs and never had a Vonage problem since doing that.
Whenever my phone rings, first thing I do is kill the bit torrent client if I have one running. People come first. Other than that, VOIP totally rocks.
I wonder how much longer that will be the case. --I seem to recall some companies were getting hit hard with law suit losses.
-FL
Most BitTorrent clients allow you to control the upload and download bandwidth consumed by the torrent(s). Limit the total of your torrents to about 1/3 of your measured (as opposed to advertised) available bandwidth in each direction. I had the same issue with VPN connections to remote desktops and found that this was enough to restore performance.
If the torrents are saturating your bandwidth, there isn't a lot a router can do with QoS to avoid choppiness. And if you keep your torrents to less than half your bandwidth QoS isn't necessary. QoS could possibly help you run at the maximum possible torrent speed without losing VOIP clarity, but you'd still have to fiddle around with the bandwidth limits on the Torrents.
We are the 198 proof..
It seems a lot of people in this thread are throwing battle ships at a job a jon boat could do. Why not just set your torrent client's bandwidth limits to something sane? I use VoIP with no QoS, my torrent client is configured to allow 15K ingress/egress, and I've never had a problem. Sure, the torrents take a little longer to complete, but more people get their fair share of downloading from my client in the process.
I wasn't under the impression torrents were ever intended to be a fast way to transfer, just a shared method of distribution. The eager beavers with no bandwidth limitations in their clients have a lot to do with ISPs trying to come up with new ways to slow it down or block it.
See: Why BitTorrent causes so much latency
http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx
But if you can deal with 3 out of 4 things, you can make VoIP usable with a low enough ping. I can't say the same if you want a perfect gaming experience though.
I had this exact problem and after much research I found that the D-Link DGL-4100 has the QoS features needed to make sure VOIP works smoothly even when downloads are going on.
It sets up easily and handles different network setups flexibly. And it processes packets fast. It easily keeps up with my 5Mbps WAN connection
Well worth it; highly recommended.
Not to self reply... I put my firewall and traffic shaper scripts in my slashdot user journal so that people may share and enjoy. Note that you will want to set some of the variables (like INTERRFACE_SPEED and the numerator in CEILING to fine-tune for best performance on your link). Weight can also play a nice trick or two. Note that you need both scripts, or at least all of shaper and the CLASSIFY bits of firewall to make this work right. The firewall script is something I found on the internet and its a better companion/primer example of IPTABLES than any other script or article I have ever found. It is somewhat customized but should work "damn well" as posted. You might want to junk the various LOG elements from the firewall if you use your console as root much. Another super feature is that I added a ssh throttle so that if an ip address starts probing your site with random SSH attempts (more than three an hour) it will get blocked till it goes away for at least a day. Enough access for you but not a gaping hole for bots! 8-) Share and enjoy.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
There is a difference between QoS and Traffic Shaping. On a big gigabit network you can permit just using QoS to set preferred priorities which certain routers and level 3 switches can follow. That is most likely what the router does, just tag the packets that are passing through which might not always work.
You also have Traffic Shaping (in Linux this is very simple to set up look up tc) where you reserve pipes of your total guaranteed bandwidth which are reserved for certain traffic (packet-based, port-based or ip-based). Now before you go ahead and set these up: what is your guaranteed bandwidth? If you have a home internet connection, this could be as low as 64kbit/s for cable/dsl to 16k for dial-up or wireless. Of course, traffic shaping so that you'll ALWAYS have that available is not possible unless you want to have that low of a bandwidth. So try to figure out what your minimum practical bandwidth is throughout the day and see if you're happy with that (that's why businesses have contracts and expensive pipes for VoIP).
The other issue is: what happens with the traffic that can't pass through the pipe at a certain moment? Does the router drop it? Technically you should traffic shape on the host that is sending the packets because that is the only one that can shape without having to drop packets and all overhead associated with that.
Read up on the traffic shaping (tc) documentation for linux to find out more about it and find out about how some practical shaping implementations work
Custom electronics and digital signage for your business: www.evcircuits.com
Picked this up recently; after some configuration the D-Link DIR-655 has become far and away my favorite router. It's also a gigabit switch, and includes a gigabit WAN port just in case.
Incredibly fast (when configured properly) it's able to keep up with my 30Mbps connection no problem.
The QoS actually works, too.
I paid $119, but I saw them at Costco for $90, so it's within your stated budget. Some people have had issues (re Newegg reviews) but I have a suspicion they don't know how to properly configure the beast.
My router/modem/(mostly)ISP can't even guarantee 6mbps for 80 bucks a month. No point in getting a router since all their modems are combined with routers and allow 0 cusomizability. I can only see the status for it.
It's the only ISP in the area, that's decent. It's either 6mbps 40% of the time or 512kbps 100% of the time....
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
I use the dlink 8100 gaming router that has excellent QoS.
But I also use uTorrent which has a scheduler. You can set it to throttle down during the working day and then back to full speed evenings, nights and weekends.
The combo of the 2 has kept my torrents and Vonage living happily together.
Uh, I don't think anyone has given him the right answer yet.
The problem doesn't have anything to do with his router... the problem is that his ISP recognizes that he's using BitTorrent and is throttling his entire connection.
I have exactly this problem with Rogers in Canada: if I start a BitTorrent session, the total bandwidth of my ISP connection drops precipitously. Stop the BitTorrent session, my overall bandwidth pops back up.
Both of us need new ISPs.
Beware of this and that
Sounds like what you need is TCP Vegas. It emphasizes packet delay, not loss, so it should work well for you. DD-WRT supports it: see this thread.
Did you know that "FTW" ("for the win") is a direct translation of "Sieg Heil"?
If what you hear is bad, then there's a problem delivering packets to you. There may be little you can do about this.
;)
If your speech is getting broken up on the way to the far end, then you may be able to re-prioritise packets out of your router, but the broadband company is unlikely to honor any QoS markings you put on them.
Finally, you might try deliberately rate limiting your reception of the bit torrent (if it is TCP - idunno, are torrents TCP ?). Any good PC operating system should be able to do this
That should persuade the far end to slow down through back pressure on the TCP windowing system.
Nullius in verba
- and turn the throttle back on to full-blast over-night. That's when must of my bit-torrenting gets done.
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.
I recently bought one for my home office after having trouble with inbound port mapping for static IPs couple with outbound GRE packets for VPN - the netgear I was using before just wasn't able to keep up. QoS, both inbound and outbound, and scheduled based on bandwidth or percentage is allowed. DMZ, virtual networks, and other stuff as well are included as well.
utorrent as a program can limit the bandwidth by right clicking the icon near the windows clock. set to 80-90kb/second on a shaw cable (100kb max...ish) and i've saved 10-20% for my voip phone (have this problem myself)
good to just get everyone in the house using utorrent. then just talk between yourselves on whos doing their bandwidth binge at the time.
It has been some months since I read the manual for this thing -- to help a client in Italy solve a connection problem -- but I remember being impressed by its feature set and the granularity of control it offers, not least among them QOS. I have no hands-on experience with this router, nor have I had time to read the responses already here. Hope this helps. http://www.draytek.co.uk/products/vigor2800.html
Twice as crazy as I would be if I was half as crazy as I am.
Frankly they should just start paying attention to an 8 bit priority flag and then set up a sliding fee schedule. The higher the priority the more it costs to send. I think that's the fairest way to do things.
Use a codec that ultimately has a smaller foot print such as G.729a.
Trendnet TEW-631BRP. Has good QoS management and is Draft-N to boot.
- The race is not [always] to the swift, nor the battle to the strong. -
Their Linux based routers are the best that I have found for managing your WAN bandwidth. They don't break off bandwidth, but control non VOIP applications access to the defined bandwidth. Of course you can only control bandwidth leaving your network so the person on the other end of the call hears you clearly. For QOS returning to your network, your ISP has to have packet drop policies in place to make sure RTP gets forwarded and only regular data packets get dropped. Edgewater also provides MOS scoring analysis and allows Linux shell access so you can use TCPDump and built in Linux tools to help diagnose the call quality problem. Hope the helps
Try getting a PepLink 30, expensive and though it doesn't say on the website, the latest version supports QOS on VOIP data. We use these for our clients and our office. We've run file sharing apps on two computers and placed multiple voip calls at the same time with no problem.
Another brand to try is Intertex, they make routers that are design for sip data. You can also limit the amount of bandwidth you computers use, and save enought bandwidth for any VOIP device
This challenge is simple.
Restrict your bit-torrent client to only use a portion of your total bandwidth.
step 1. Use a few speed test, or download a few really well seeded torrents to determines your maximum up/download speeds.
step 2.
Subtract a few KB/s from the maximum speeds and cap your torrent client's upload/download speeds to the remainder. leave yourself a good 15-20kb/s for your voip connection and you should be alright. unless your isp is using flow limiting, then set the maximum connections for your torrent client to a number around 200, and it should work decently.
step 3.
Profit.
- Better to speak your mind than to remain silent, or someone may speak for you.
First off, on the off chance you have verizon fios, the fios router supports both inbound and outbound QoS and allows you to reserve an arbitrary percentage of your bandwidth for inbound and outbound (seperately of course). Just google for the model of the router and the words vonage QoS. You should come up with some hits about how to do it.
Your other option is to upgrade your device to the new V-Portal (unless you already have it of course) as it has its own internal QoS settings that ensure it always gets priority over devices plugged in behind it. You just have to make sure its first on the network.
Whichever route you go, 90kbps is not really enough. The bandwidth saver settings vonage lists show high as 90 kbps, but it actually uses a bit more bandwidth than that in each direction when on a call, so you're better off reserving at least 96 kbps, 128kbps if you have it to spare just to be sure. And one last note, if you do any conference calls, its 90kbps per direction per party on the line (if you are the one hosting the call).
And before people jump in and say I'm crazy, yes, I do work for vonage, and yes, I am a tech support agent.
What most people don't understand about TCP (and therefore bittorrent etc) and Cable Modems could fill a book.
:-)
Hence the reason one can find books on these subjects.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
the DSLAM doesn't have huge buffers, AND tends to prioritize traffic with the right TOS bits set. Most recent ADSL dslams do both of these, and believe it or not there is a lot many telcos could do to make voip worse if they wanted to, than the pretty decent default behavior built into most recent dslams.
It used to be thought that dropping packets was the worst thing you could do, and that robust networking equipment would buffer out the wazoo. The reality of multimedia and realtime services has now set in, and most modern equipment doesn't buffer nearly as much. The interesting upshot of this is that the modern ADSL that pretty much any telco will provision is *better* for VoIP than most SDSLs with no added edge router on each end to provide better QoS. (Paradyne MVL, once the favorite SDSL of little regional CLECs everywhere, is particularly bad in this regard; it's nearly unusable for VoIP in the absence of deliberate QoS on both ends.) In addition, the fast downstream on ADSL helps mitigate the effect of bursty TCP traffic, although it may not be enough for torrents.
By the way, if you are configuring Linux for QoS, the same issue applies. There is a tradeoff between latency and the likelihood of dropping packets. The linux defaults are biased toward very high speed interfaces (and very large buffers), and the kernel has the counterintuitive practice of copying the interface's queue length to each leaf qdisc. The defaults create excessive latency with many QoS setups. You should set the txqueuelen using ifconfig to something much lower than the default of 1000 (but usually at least 10), BEFORE you create the htb/cbq/hfsc qdisc and classes for QoS.
The thing to consider is that it may not even be your own network that is causing the problem.
Say for example your local device is prioritising and the outgoing traffic from your 'vonage' box fine -- but your ISP isn't. The result will be return packets are delayed etc. You can't fix this execpt maybe by arguing with your ISP.
Remember also that if a large data packet has already begun transmission then any smaller packet that comes after it will have to wait. This may not matter -- but you could try lowering your MTU.
Your local queing strategy may also have an effect in a conjested network...
I know...you don't really want to learn to use a router, however, your need for QOS (or want) determines that you need further education and a much better router. That said, you should give Vyatta a shot. It works really well in this type of application, and of course, is open source and there is a free (community) version.
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
I had DD-WRT on my WRT54G sharing with several neighbors (a six-apartment building). One neighbor in particular enjoyed bittorrenting from two computers over wireless... DD-WRT choked to death quite thoroughly once in a while.
After I stopped sharing with neighbors, I tried switching to 128-bit WEP (couldn't get WPA to work at all), but DD-WRT froze up after several minutes unless I stayed with 64-bit WEP.
After installing Tomato I haven't had many issues. Once every other month or so the wireless stops responding, but a quick reboot fixes that.
I'd switch to WPA but I don't think my wife's laptop's wireless card supports it.
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.
Are you sure about that? According to the documentation at Mozillazine @ http://kb.mozillazine.org/Network.http.pipelining the max value accepted is 8. Are you using a modified version of FX or is the documentation just wrong?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
Oops, wrong link, the page that gives the 8 maximum number is at: http://kb.mozillazine.org/Network.http.pipelining.maxrequests Sorry about any confusion.
I used an OpenBSD setup with Alt-Q and that works great. I prioritized outgoing VoIP packets including the ACT packets. (VoIP ACT packets higher than normal ACT packets, etc). I've never had a problem with VoIP even when downloading large files.
It's most probably latency, the router doesn't have enough juice to push voice packets through at the speed you want it to, especially when there is some "legal" bittorrent going on - remember, bittorrent takes a lot of your upload speed, not just download, uploading what might "be legal" or not, putting you in the p2p network. Again, how much of queuing would these home routers do?
I've tried several versions of firmware on Linksys WRT54Gx, and in the end I think the biggest problem with a consumer device is the processor speed...it's too slow to handle the traffic shaping requirements of VOIP and BT. I resolved the issue by using an old Celeron 500mhz machine with 2 IBM NICs--which I paid more for than any other part of the router I made. I used a floppy firmware called Coyote Linux (now called Brazil Firewall), and a custom version of Wondershaper---lots of trial and error, but in the end I had a sweet router---it handled two VOIP devices (both Packet8) and two households using Bittorrents almost constantly (30gb per month minimum). We never ever had a single problem with VOIP while using Bittorrents...leading me to believe the real issue, aside from getting the Upload and Download speeds tuned correctly, is the router processor speed.
To some this may seem like a good argument against net neutrality, but think about this;
Should your ISP prioritize your Skype over Gizmo? Prioritize Xbox Games above World of Warcraft? The list goes on forever...
If the ISP is not neutral, the ISP will dictate which providers you will have good results with and which that would fail for you, not a good thing.
The argument is a great one, one I think more people should consider more closly: Use of local small ISP that have the interest of prioritizing your needs!
If the ISP allowed YOU to prioritize YOUR downstream traffic, then there is no problem - there would be no need at all for going away from net neutrality. The writer of this argument seems to claims that small ISP's in fact allow you to do this.
If you indeed can control your own traffic shaping the internet can remain neutral. You could select movie downloads from Netflix above Blockbuster and visa verse, and everyone is happy (except for the big name ISP's who intend to force you to use their much more expensive private video rental services etc.)
Try pfsense
www.pfsense.org
Unfortunately most people see "QoS" in a home router webconfig and think this is how QoS can be enabled. Or they see the feature in an OS/app pkg and think that configuration of same will solve their QoS problems. This is mostly not the case. Those suggesting DD-WRT, ipcop etc are doing so out of ignorance of the issues surrounding effective QoS. I have experience with provider networks and business implementations of traffic management which has provided me with an understanding of the issues involved. Without an essay, the root of the issue of effective QoS is queueing. Simply marking packets or applying a queuing strategy will usually not provide effective control. In a situation where a link is a simple, as-designed ptp situation with no re-encapsulation QoS can be effectively implemented using in-box configuration. Home routers and OS-based control will work provided QoS is configured at each endpoint. Unfortunately few people have the kind of service which out-of-box QoS can be used effectively. Have a read of my blog entry on the subject for further detail: http://benryanau.spaces.live.com/blog/cns!E55F3F5F75B5A7BB!126.entry There are three options available: implement artificial queuing on a traffic-shaped interface at each end, use software or a router that can 'poison' and manage non-realtime traffic when realtime traffic is present, or the practical solution: buy more bandwidth. Until the ISP industry gets it together and develops a mechanism for large-scale access networks to provide customer interface queueing at each end of the link, this is the situation we're in. Hope this sheds some light on the topic.
The Edgemarc is the router you want. I have a 4500T4 and it works great with both my MGCP and SIP clients. Edgemarc is an ALG (Application Layer Gateway) which allows for premise based nat traversal. It is also a traffic shaper, it has knowledge of the VoIP devices registered on the LAN and can dynamically shape traffic by faking out TCP ACKs to allow Bandwidth for your VoIP devices. The only other option I know of for "reserving" bandwidth is to employ a rate-limit policy on an enterprise class router that uses source/destination to rate limit traffic.
My router is a standard Linksys WRT54G (version 4, I believe - I'm not home to verify) and I have no problems running BitTorrent and using Vonage VoIP at the same time... I used to, however.
When I did have issues, QoS didn't do crap for me... neither putting VoIP at the top or BitTorrent at the bottom did a damn bit of good... and neither did restricting BitTorrent speeds to well below my bandwidth limitations.
After doing some reading about the BitTorrent protocol, and snooping around my network, I found the issue had nothing to do with bandwidth, but had everything to do with the way BitTorrent drops connections (instead of closing them) and the default setting of the router only allowing 500 connections. I'm running DD-WRT, changed my connection max to 2000 and changed the dropped connection timeout to 120 seconds (default was 3600), and my $50 Linksys router handles my 12 PC network just fine even with 4 (max I've tried) instances of P2P sharing and Vonage, and I disabled QoS because it was doing me more harm than good.
class-map match-any VOICE-SIG
match ip dscp cs3
match ip dscp af31
class-map match-any VOICE-RTP
match ip rtp 16384 16383
!
policy-map VOICE-QOS
class VOICE-RTP
priority 32
class VOICE-SIG
bandwidth 16
class class-default
fair-queue
If your inbound traffic from downloading is TCP, then it's not being "broadcast" from the remote server, that server expects to see replies back from your box that the traffic made it (or it will be resent).
If your router slows down those responses, your download traffic will slow down as well.
It works - I run Monowall (in a virtual machine) and it works wonderfully. Without shaping my VOIP is about worthless during a big download.
Yes, it's called, OpenBSD.
www.openbsd.org
+1 Tomato Firmware
http://www.polarcloud.com/tomato
I run it on a WRT54GSv4 and a buffalo wifi router of some sort that I paid less than $20 for. Works great on both, though the Buffalo couldn't handle QOS for voip and BT traffic. The WRT does though.
TossableDigits.com: Temporary Phone Numb
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
I work for a pretty big VoIP provider, and one thing is known:
The amount of connections required for bittorrent KILLS latency with your VoIP connections. It's pretty important, because most VoIP is either SIP or MGCP, and relies upon stateless UDP to transfer data, so the ramped up latency will start to make your VoIP connection sound worse than a tin can.
I've seen it way too much -- the average joe, home business will call in and complain about hte quality of their VoIP service. They don't have a QoS router, so they immediately point to the fact they only have a computer or two.
Yet their teen upstairs is streaming a 198k stream via shoutcast, downloading three torrents occupying 20 different connections via bit torrent, and playing World of Warcraft.
Please, for the sake of our sanity, check what's going on with your topology before calling in and complaining that your call sucks. If your device is registered, we probably can't do much more than tell you you need to reserve 80k with overhead inclusive for you call, and don't live in Nova Scotia.
1. Buy a D-Link DVG-1120M VOIP router on ebay for 10 bucks including shipping. 2 Convert it into a DVG-1120S Here: http://www.dslreports.com/forum/remark,20580722?hilite= 3. Configure DVG 1120S with your provider, and put it as your first device (connect directly to your cable or DSL modem and then hook your LAN to it). This unit has great QoS VOIP bandwidth limiting, which is why AT&T used it for their VOIP service. It's only disadvantage is that it's WAN input is 10 base T so on a 10 mbps cable circuit the max throughput I get is about 8.4 mbps. For speeds below 8 mbps it's great! 4. Done
QOS guarantees and border routers
Most QOS algorithms are implemented incorrectly, including those included by default on FreeBSD , Linux, and other systems claiming to support QOS guarantees.
The problem is that these routers are at the border of a very high speed network (the local network), a slower network (your broadband connection), and another high speed network (the actual Internet.
As a result, what happens is that the packets end up being buffered at the router on the other side of the border router, or in the computer (if in the home, and your only router is the border router).
This effectively starves the connection of packet buffers on one side or the other, if there is a low priority but high bandwidth demand application sitting on the other end. No matter what you do in terms of rate based algorithms, your border router is not going to be able to do anything about the starvation, which is not happening on a box under its direct control.
The only approach that works very well (and which most traffic shaping software does not implement) is to advertise a smaller TCP window to the other end of the link, so that there are buffers available because the transmitting end believes that the TCP window is full on the receiving end of the TCP connection. RED queueing can also work, but only protects the endpoint equipment, and ignores the problems of the intermediate routers; typically, this makes things much worse for the intermediate hop routers, which have to put up with retransmits of the same data.
I've come to the conclusion that this is, in fact, why the broadband companies, which have fast links to their head-ends, but have relatively slower links to residences, have decided to start a war against peer-to-peer technology, and why some are suggesting higher feeds for streaming video users by placing bandwidth caps and punishing users who exceed them: you effectively starve the other customers behind the same head end as yourself by using all the head end router buffers for traffic that hasn't gotten to you yet, or you flood outbound with retransmits for unack'ed data.
My suggestion would be to buy something that know how to traffic shape with TCP windows (and it's my advice to both the poster and the infrastructure companies, who have apparently failed to grasp the idea that traffic shaping is not a job for amatuers who only prioritize outbound traffic, like AltQ and friends).
-- Terry
I have the same exact situation and I solved it by using the scheduling feature in utorrent. I download full during non business hours and throttle it during business hours. Since I started throttling I have had no problems with VOIP calls.
Does VOIP really use TCP usually? Shouldn't it be using UDP? Why would you want retransmits of lost packets during live voice conversations? I would think it would be better to just live with dropped packets than have the audio stream delayed by retransmits and such. Wouldn't that start to introduce more lag in the conversation?
Best router for home/small office ever.
Enable traffic-shaping at a rate 80-90k below your cap, for packets not coming from the VoIP device.
Done.
You can do tons of other tweaks also (prioritize the shaped packets, separate queues for different types of traffic, etc).
I did more than my fair share of VoIP and QoS deployments. The trick is that you provide HIGH QoS to voice, and low to EVERYTHING ELSE. Think of it this way, turning off QoS gives everything low priority, you need to mark the voice packets as 'important' and subject to 'special' treatment. Giving anything else medium QoS, you will telling the router to not let voice take top priority, that medium QoS queues will get serviced even if the high priority queue has packets waiting for transmission. Voice packets are very small, about 100 bytes on the large side. You want your voice queues to get serviced the instant a packet needs transmitting and put everything else on 'hold' until the high priority queue is empty.
Anything else, and you'll have choppy voice.
Joel
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
I had similar problems. The best and easiest way to do this would be to rate-limit all TCP transmission/reception to some percentage less than your overall Internet bandwidth, say 80%. That way, all applications (FTP, BitTorrent, HTTP, etc.) won't take up all of your bandwidth, and thus kill your VoIP. The problem that you're having is that you're saturating your uplink or downlink, and that's what's delaying the VoIP packets. You only need to rate-limit TCP, since Vonage (and most VoIP out there) is UDP-based. You want to let the UDP through without touching it. By limiting TCP, you're effectively reserving UDP bandwidth for your VoIP.
You can do this with a fairly inexpensive Cisco router (buy an 800-series off ebay). You can probably do it with DD-WRT as well.
For the true gearheads out there, I worked out something similar, except that my system actually senses when a call is in process and makes appropriate TCP rate-limiting for the duration of the call. Once the call is complete, the full bandwidth becomes available for other things. It's a clever use of Snort, pfSense, and a Cisco router. I call it AATQoS or Application Aware Triggered Quality of Service.
Whatever you end up doing, just understand that your call quality is suffering due to traffic congestion, and if you can alleviate that congestion enough to let the VoIP UDP packets flow, then your call quality will sound great.
The problem is the link between the router and the ADSL modem is 10Mbt, the router which is doing the traffic shapping, it keep pumping out packets to the modem at 10Mb rate. the modem starts to drop packets once its queue is full :(
use it in bridge mode and do the QOS at the point where the bridge is terminated!
ummmm... limit your upload on the torrent program?
it amazes me that people don't learn how to control bandwidth, it isn't hard, most programs have the option
I have the daily joy of riding herd on a global network that services about 10,000 locations in every major time zone on Earth.
While I had a role in designing, building, and deploying it over the last 12 years, my primary role for several years has been network traffic forensics. We employ very sophisticated QoS schemes and require our carriers give us visibility into the MPLS clouds. Since the network IS our money bitch, there's a keen interest from the top down on making the (packet) trains run on time.
What's interesting to me is that over the years, I've seen enormous amounts of money and effort spent on the network and tuning it to death while the vast majority of the system owners...including PCs...just jam their toys onto the wire with little to no thought about the network hardware and software IN THEIR FREAKIN' IRON!
I see crap like Nagle's (TCP_NODELAY), Receive Window size mismatches, VLWS set to OFF, SACK not enabled, and a host of other nightmares all the time. I'll get a call or e-mail from someone with a data mover application; FTP, backup job, etc., and they're complaining their 10Gb link is not running at 10Gb..they "measured" it with ping and traceroute...or simply "this isn't as fast as it should be".
Invariably, I'll interrogate the path, grab some traces, and see one or more "TCP bullets to the head"...from their host. Over the years, I've built some tuning guides for the UNIX, Linux, and Windows and send them along to the owner when the data reveals it's their shitty TCP/IP configuration choking the box.
It's helped. My suggestion from this is to make sure your "iron" is tuned for the link. It will help. My son's friends think I'm magic when I do surgery on their PCs and their torrents, Skype, etc. suddenly work better than they ever did before.
As for home gear, I don't know. I use Cisco and LinkSys and D-Link at the house. I have DSL AND cable. I have had occasion to talk to level 5 support for both, but for the most part, I'm happy with the service I get. I do monitor and trend my traffic, but that's habit more than anything, because of work.
I am my own gestalt.
Does VOIP really use TCP usually? Shouldn't it be using UDP?...
Yeh... the RTP protocol to transmit voice is UDP. This causes a lot of the problems with sip and nat/firewalls. SIP is also generally UDP, though it can use TCP. SIP is used to setup the session, do the auth, figure out where the streams need to go and how to translate addresses and even do billing stuff, etc, then it lets RTP do the grunt work of transporting the media. MGCP and other VoIP protocols also use RTP for the transport.
What most people dont understand about VoIP (even just SIP) HAS filled many books, and websites ;)
Tm
Support TBI Research: http://www.raisinhope.org
Reserving bandwide is not the solution for a simple reason: VoIP care little about bandwide and very much about latency.
There are other protocols that care about latency too. Games are a known category.
Buy a gaming router.
Most VoIP connections use UDP or RTP, which is built on-top of UDP.
The theory here is that one can control the rate at which large downloads come in by controlling the rate at which we send ACKs which correspond to the incoming packets. The system doing the download sends the ACKs as fast as it can, as it's doing the best job possible of filling the bandwidth available. If our router were to delay some of these ACKs, the remote system will slow down its transmission, as it would interperate the router as network congestion.
Once we have a handle on incoming TCP connections flooding the pipe from our ISP, the UDP/RTP packets will flow much more efficiently.
Check that second link out; the sections on flow control and congestion control explain this much more succinctly than I can.
kmem russian roulette: Aquillar> dd if=/dev/urandom of=/dev/kmem bs=1 count=1 seek=$RANDOM
I noticed that you are only shaping traffic on one interface. If your example eth1 is your internal LAN, then your script will nicely manage your downloads, but do little to prevent you from flooding your upstream. If eth1 is your external WAN then you are shaping your uploads, but merely dropping downloads when you flood. Since it works for you, I'm going to assume eth1 is LAN.
When I looked waaay into this subject last year, we had ten employees sharing a T1 for internet and voip. Since we are software developers, we use ssh a lot and it sucked bad too. I ended up using a linux box (FC6) for the firewall and installed traffic shaping on both the WAN and LAN interfaces using HTB, Stochastic Fairness and moderately decent filters.
This allowed us to torrent all day over a T1 while simultaneously enjoying 20ms latency on our ssh connections to Internet servers. Web browsing felt unaffected. We tested it heavily ;).
When we moved to a 100Mbps link, I continued rate limiting at 4Mbps to save money, but plumbed in some back-doors for favored servers.
In the spirit of sharing, I've also posted a sample script to my journal. There are probably bugs and improvements to be made, but it works well for us.
These opinions guaranteed or your money back.
Thats why everyone need to have the Richard Stevens set on their desk.
I've had the same problem with Vonage, and even when downloading & uploading is minimal. I'm going to give the Linksys OGV200 a try. It's described as a "Network Optimizer for Gaming and VoIP" and buy.com has it for $20. I'm going to try it and see if it helps. Of not, it will be going back to buy.com for a refund.
How about just stipulating that ISPs be upfront about how they're running their networks, say by posting that information to the public.
ISP conspiracies would be less likely to happen at that point, given that people would actually have a clear idea of what they're paying for.
The OP doesn't say but probably doesn't have a cable modem, he more likely has ADSL from the phone company.
I have fought those problems with VOIP and a poor DSL line. With a WRT54G and that optional firmware, and it was an abject failure. We couldn't solve the ADSL line problems at our end.
The solution is probably going to be calling his provider and demanding they give him the speed he is paying for, and if he's not paying for enough speed he may have to pay for more line speed.
The trouble with DSL is it is not guaranteed bandwidth. It can completely stop working for more than enough time to screw up VOIP and there is likely nothing he can do about it.
Cable modem service is typically enough faster than ADSL from the phone company he is much less likely to have these sort of problems, unless maybe his provider has installed Sandvine traffic management equipment and that is screwing him up detecting his P2P usage and throttling his circuit. I don't know if Sandvine equipment throttles the whole circuit or not. Does it? Does anyone know?
The funny thing is you would never have these problems on an ISDN circuit, which though slow by todays bursty ADSL standards is guaranteed bandwidth, just like that corporate OC-48 you have at work. You get two FM radio quality voice channels on ISDN and it does work, guaranteed. If not they *have* to fix it.
Whereas on ADSL they just say "sorry bub". Then they maybe say "If you got your VOIP from us I bet it would work". But only because in that case they would *have* to fix it. Evil telcos, to be sure.
.
Anonymous Coward here. work for fortune 500 company with 8 figure network budget. Still hard to get routers to provide QOS for voip when pipe is flooded.
Did I mention the captcha here sucks?
If you have money, you can buy a PacketShaper : http://www.bluecoat.com/products/packetshaper/specifications
Go far beyond routers with unparalleled QoS and traffic shaping with simple prioritization to ensure critical applications (including bandwidth max or min per application, user or flow). Also, limit or block recreational and malicious traffic.
I don't know if this router is available in your country but I'm using this router already for about 4 years with voip and wireless. In those years I had different smaller problems with voip but never bandwith problems.
Why would you need to have the Richard Stevens, set on your desk? Wouldn't he just be in your way?
She made the willows dance
Mikrotik Routers using queuing are very good for this
If you're experiencing that significant of a problem, then you may want to consider a different ISP, if that's a possibility. There is absolutely no reason a quality broadband connection cannot manage VOIP, Torrents and assorted other traffic simultaneously. Vonage uses 90kbps per second at default settings. This is such a small fraction of any current broadband connection it should be negligible. You can adjust this setting in your Vonage web account, and reduce it to as low as 30kbps/sec, but that often produces a tinny, less natural sound. What you're describing, however, indicates either a very low-end package, such as with bargain basement DSL lines or more likely, you're not getting the bandwidth and/or stability on that connection that you're paying for. Do some trace route tests before, during and after you place calls and run your torrent application. Choppy audio with VOIP is a result of dropped packets. I wager you'll see a number of lost packets as you saturate your connection. I highly doubt any QoS attempts on your end will make a difference. Throttling your own traffic isn't the underlying problem. Most likely you're ISP isn't giving you the reliable connection you're paying for. It's also possible that they're monitoring certain known ports, or sniffing packets for VOIP and/or torrents. I am also a Vonage customer. I run 2 game servers, a web server, my Vonage line and uTorrent all simultaneously with absolutely no degradation of call quality or other problems. I hope this information is helpful to you.
Nice graphs of queuing delay due to discrete packet sizes can be found in this online report, actually.
A. Heyde, "Using Synthetic Packet Pairs to Investigate Real-time Latency Variations over Home Broadband Connections," (pdf) CAIA Technical Report 080530B, May 2008
http://caia.swin.edu.au/reports/080530B/CAIA-TR-080530B.pdf
Draytek routers can.
Most home user oriented routers use a large output buffer to improve throughput...
Trouble is, the output buffer will be good for 2-3 seconds of line saturation, meaning that even if your packets are prioritised they will still take a couple of seconds to get out if the buffer already contains something else.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Thing about VoIP ... the payload is transported by UDP usually using RTSP for reliability over the top of TCP. Only the call control aspects use TCP as I recall.
I have had some experience using (or trying to use) VOIP over a slow V-SAT connection (256K/BIT up and 256K/BIT down).
As was previously stated it is not always the amount of bandwidth that is being used but the delays in clearing out the buffer.
The one solution that we found to work verry well was to set the MTU from std 1500 to something like 500 (not sure of the exact settings). The only problem is that after doing this normal browsing and especially MSN Messenger wont work anymore as it is full of s&*)^ when it comes to playing with the MTU.
As I understood from the question the voice becomes choppy on the users end. I.E. what the user hears and not the other side of the conversation. This is caused by data being transmitted from the ISP not having QOS prioritizing the VOIP packets.
Just some food for thought.
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).
The thing most people don't understand about TCP is that it accelerates linearly and falls back exponentially.
Indeed!
I could go on, but there are good books, I would suggest TCP/IP Illustrated. Problem is that TCP is all in all a bit of a hack on a hack on a hack!
Back to the point, if you want to control TCP you want to be controlling the loss and delay it experiences - thats how it works out the bandwidth.
The thing most people don't understand about TCP is that it accelerates linearly and falls back exponentially.
That is the AIMD behaviour of some variants of TCP (reno for example) and only when they have past slow start and are in steady state. This page has some graphs which show the difference in the cwnd behaviour for different TCP variations, it also links to the relevant papers. There is currently a mix of TCP variations in use and not all use AIMD. Linux, for example, uses CUBIC and in the past has used BIC and NewReno as the default TCP variation.
for good quality VoiP - the fritz!box is a well build european alternative. It's not cheap - but at least you get good support for it - with everything you may need.
www.fritzbox.eu
No one has said it yet. Lower the settings for call quality in your Vonage settings a bit till you reach a happy place. You already are giving top billing to the adapter so by doing that it would probably be all you need to do. I know when I first got my vonage i had a lot of delay issues while gaming or downloading, till I lowered the quality then it was all fine. Still sounds great and no lagging issues.
What you really want isn't TCP|UDP/IP, you want ATM. ATM can guarantee QoS. IP simply can not.
I really think people are on the wrong track if they are suggesting that the inbound (to your modem) is the problem here and can't be adequately shaped. In my experience when you have cable or dsl with a disproportionately low egress (outbound) in relation to the ingress(inbound), you will have the increased latency you describe.
I think the first step would be to upgrade to the highest level of service your ISP provides short of business class. If you have comcast, we are in the same boat and you should get the 8/768 plan as you are essentially doubling your upload speed.
If you don't have the money, then I would setup a simple test to see how well your connection performs under stress. Since you are testing for VOIP latency, I would use a UDP ping on a machine you give higher priority to, and run a simple speed test on a machine that would be running BitTorrent...it won't simulate the number of connections that machine will put out, but for the purposes of the test you want to see how well your router is shaping traffic when you reduce the upload cap by 60%, 50%, 40%, etc...and you want to get an approximation for the amount of bandwidth being received and sent out. Try adjusting your inbound bandwidth in the same manner.
Now you mentioned that you are prioritizing based on MAC address, and not based on protocol or service. This is not actually QoS, but rather CoS and is only layer2. CoS is really ineffecient at lower bandwidth rates...it's not really meant for that little traffic and if you throw a lot of connections at it, it will definitely screw up queueing.
Prioritize the VoIP traffic by port or application if you can, and try the different algorithms available to your router...I would definitely suggest as has been stated above to try different firmware images to see if you get better results...Tomato may have been the best suggestion given it's apparent inclusion of Layer 7 (Application) matching using the L7-filter projects signatures. If you can make BitTorrent the lowest possible priority that would be good too;)
Something that someone else might not have mentioned, is the number of connections that are allowed to be setup for either a given computer or application. Connection/Session limiting on your router would definitely help out QoS to prevent BitTorrent from opening more and more connections, and basically increasing overhead. That change can be made in iptables on any linux-based router running a modified image or full blown linux(has to be done from the command line).
--"It's Bradford Company, slash your last name, dot your first name"
It probably won't make much of a difference, but you may try reducing the bandwidths configured in your current router's QoS page (which should already be somewhat lower than the real values) to, let's say, 70% of the real values.
It will, of course, reduce your peak bandwidth, but it can help with the prioritization.
Zoom has several products that should fit this niche well. the only issue i have had with zoom is that their gateway/router *must* be the first one connected to the cable modem. in my situation, it didn't have enough customization (for opening ports, etc.) that i needed, so i wound up returning it in favor of the zoom product that solely does VOIP. but the zoom gateway/router will probably do the job for 90% of the people.
Yea, both are "purely for legal and non-copyright-violating purposes, of course". Mhyeeeeaaaa, suuuure :P
An year ago I discovered Rapidshare. Since that moment I never started any torrent and I will never again.
Torrents are a desperate way to get data from Internet, crushing the TCP/IP stack on all poor SOB routers that are unlucky to get crossed by its flow. Do you wonder why ISPs try to limit it? Its not because of copyright violations - they don't give a fsck about that, its because its stupidly hard to shape it properly. You have to reserve insane amounts of bandwidth for a figures like 30% overhead of flow control packets. When you have so much overhead it should fully qualify as denial of service attack by any routers along the way - because that is what you are doing!
Stop trying to find complicated ways to get FREE stuff and fkin pay for it. Nothing is free. There are only different ways to pay for it. Are you sure a fancy router is the lowest?
"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..."
Actually this is not true. Cable modems are notorious for having large transmit buffers and slow transmit speed.
The end result is that when you saturate your connection, the problem is not necessarily packet loss, but latency goes through the roof (because stuff is staying in that huge buffer).
This kills your download speeds in addition to your uploads because ACK packets get delayed in the buffer.
retrorocket.o not found, launch anyway?
We have a T-1 at work, and we're thinking of adding DSL for redundancy. During normal ops the T-1 would be dedicated to e-mail and certain outbound traffic, and the DSL would be for web access and so on.
Something similar might serve your purposes. Put in DSL and dedicate the cable to VOIP (or vice-versa). If one link is only used for VOIP, and the calls are mostly work-related, maybe it'll be deductible, or maybe your employer would reimburse you for it.
QoS settings on your local router only affect upstream (from your home to the ISP) packet ordering. Anything you do there will have no impact on packet queuing/ordering downstream (from the ISP to you) - this is being performed by your ISPs gear. Downstream bandwidth is commonly larger than upstream bandwidth, so this problem is frequently hidden - but if you have lots of data coming down, no QoS settings on your local gear will in any way impact the priority for packets coming from your ISP to you.
exactly! it's really necessary to do some outgoing traffic shaping just to ensure that you dont ever fill that buffer cause the results really really suck! so much of ensuring a good connection ends up coming down to ensuring that you dont step on any of the grumpy stuff in the middle's toes.
The serious answer to this issue is IPv6 with traffic classes *and* support from IAPs. Of course "standardized" traffic classes will have to cross IAPs boundaries (That would be enforced by a government regulation authority). In the IPv6 header you have a traffic class field and a flow id. Network equipement could do traffic shaping at a very low level of channels/flows thanks to those and the other header fields. But carefull, where shaping happens, unfairness between users can happen, so fairness of bandwidth in each traffic class between users must be enforced: net neutrality. The thing which seems to be missing: how your soft phone will discover the traffic classes, numbers of flows per traffic class and the bandwidth limitation of the each flow, all that per internet access point of your IAP?
What most people don't understand about TCP (and therefore bittorrent etc) and Cable Modems could fill a book.
You might want to mention that most voip uses UDP instead of TCP...
Your Qos scheduling will only apply on your internal network, once it hits your cable/dsl modem all your traffic gets re-wrapped by your ISP for transport over their network.
So basically, you can Qos your VOIP so it gets priority on your LAN both in and out. However, your ISP is going to treat all the inbound traffic at the same priority, until it hits your router. This means that if your P2P app is attempting to download enough to fill your pipe, your VOIP traffic is going to get 'lost' in the noise of all the inbound traffic since the ISP gives the same priority to all the inbound data.
This is why 3rd party VOIP services don't work that well. Pretty much any ISP that offers phone will install an EMTA which is really two cable modems: the one serving the phone traffic will get a high priority Qos so you don't have those kinds of issues.
If you can't tell, I work at such an ISP and we often get people calling in pissed off that we don't 'honor' their Qos priorities. I then have to explain that if we DID, everybody could simply set their router to top-level Qos ALL their traffic and then you're just back to square one.
m0n0wall
would be juniper's 5gt line -- they're around 300-500/USD retail but will certainly do QoS scheduling. I would be surprised if Cisco's pix 5xx series didn't do the same thing, but I have no personal experience with them as QoS devices so I can't say.
FreeBSD for the impatient.
You get two FM radio quality voice channels on ISDN
I'd be interested in knowing what kind of ISDN hardware you're using to get two FM quality channels on a single line. I work at a radio station, and the hardware we're using sounds fantastic, but to get FM radio quality it takes running two lines simultaneously with the left and right channels each on their own line. Are you referring to mono audio only? Are you sure you aren't actually using multiple lines to the same box? We're looking at upgrading our hardware to something with some newer codecs (and less latency, ugh) and it'd be nice to know if we could get something like FM stereo sound on a single line.
Create a login at www.astaro.com and you get a free copy of their Astaro Gateway software (limited to 10 ip's, will turn any spare PC with dual NIC's into a fully functional enterprise firewall).
More info and support can be found here
http://www.astaro.org/
Enjoy!
No sig here...
I use pfSense as my firewall. its FreeBSD based software that uses OpenBSD'd pf to handle connections. I used this to replace a linksys router that would die under the load that BitTorrent would stress on it. I now have QoS set up so that BitTorrent and other file sharing protocols are given THE lowest priority. you can also dedicate bandwidth for VoIP. Have had zero issues since switching over.
That's funny, I was able to pick up a corporate grade Sonic Wall on eBay a year back or so for about $100. One doesn't need to buy the subscription to operate the router... that's optional. Subscriptions usually cover support, upgrades and things like router-based virus protection -- all unnecessary for the hobbyist.
If you have a cable modem, you would be far better off just getting phone service from your cable provider. That is the only way to really guarantee bandwidth. When you use your cable providers phone service they do all the prioritization for you and you never have to think about it. Also they won't begin any maintenance if you are placing a 911 call. with Vonage you could be right in the middle of a 911 call and they would begin maintenance and leave you on your own in an emergency.
We just started using products from FortiNet and have been pretty impressed with them. Their FortiWifi-50B should do the trick for you. It'll do the QoS you need, but is also a great UTM device with built in AV, web filtering, firewall, VPN, etc. Good stuff!
http://www.fortinet.com/products/telesoho.html
The problem is most probably that BT is using ALL your upload bandwidth, this affects every TCP packet coming into your network since there is no upload room for control packets. In your BT client, limit the upload to 80% of your link's upload speed. For example, I have 1Mbit upload, I limit uTorrent to 80k/sec. Voila, problem solved.
The OP (me) actually does say that he has a cable modem, but it's buried rather obliquely near the bottom of the post.
We currently use the Asus WL500G Premium v1 at our work and we have VoIP. We installed OpenWrt on it (WhiteRussian firmware) and Rudy's Qos Script (http://forum.openwrt.org/viewtopic.php?id=4112&p=1). Since then we have no problem running multiple Torrent and download while talking on the phone. You should give it a try.
You can contact me if you need information, I'll be pleased to help you.
You can also install the X-WRT version of the WhiteRussian firmware, it have an Web Interface so you wont have to do everything in command line. The only thing you'll have to do is configure the Qos Script.
If you do not want to configure the router by yourself, we ( here at Quatral Solutions) could build the router with everyting you need and then ship it to you. If you need information, you can email me.
Here is my email: jfrank@quatral.com
I took similar steps when we had 10 people on a DSL for web and VoIP. :)
Doing QoS both up and down, we make VoIP top priority, then interactive SSH, DNS, and empty ACK packets, and then everything else. My boss didn't think it would work (he subscribes to the notion that inbound QoS is impossible, or he used to at any rate), but the results spoke for themselves.
PF offers several schedulers, but I've found the fancy ones aren't really useful on smaller connections (even a single 1500 byte packet can cause significant latency on a 768 kbps connection). I did tweak it so the VoIP and DNS/SSH queues didn't use RED, since we assume these services will never be bandwidth bound.
RED basically drops packets with an increasing probability as the queue fills up, allowing it to throttle and still mitigate fluctuations in traffic, where a standard queue would just fill up and then do nothing but add latency. That's great for web and e-mail, but bad for VoIP or DNS or whatever.
We've now got a dedicated wireless backhaul between us and the datacenter, so we too aren't terribly concerned any longer. :)
I rarely criticize things I don't care about.
Honestly, just flash the firmware on your existing router with DD-WRT. It will give you the functionality you want because it has quality of service that works.
www.Launchwifi.com
uses a special kernel to support application bandwidth sharing and throttling to each user. Making sure you have the correct bandwidth at all times.
We currently use the Asus WL500G Premium v1 at our work and we have VoIP. We installed OpenWrt on it (WhiteRussian firmware) and Rudy's Qos Script (http://forum.openwrt.org/viewtopic.php?id=4112&p=1). Since then we have no problem running multiple Torrent and download while talking on the phone. You should give it a try. You can also install the X-WRT version of the WhiteRussian firmware, it have an Web Interface so you wont have to do everything in command line. The only thing you'll have to do is configure the Qos Script. If you do not want to configure the router by yourself, we ( here at Quatral Solutions) could build the router with everyting you need and then ship it to you. If you need information, you can email me. Here is my email: jfrank@quatral.com You can contact me if you need information, I'll be pleased to help you.
Well, I didn't say it but you would need a codec box to get that. But clearly we weren't discussing FM stereo radio quality voice. I was just throwing that in as what you get on ISDN and how we're being so darned shortchanged by the telcos on our ADSL lines.
And sure you would need two channels for FM stereo. But I've seen that done on remotes with one line, but they only had one mic. It sounded great.
.
I notice that now. I read that several times to see if you mentioned the connection type. I missed it.
As I said cable lines are usually a lot faster than ADSL and should be having no problems.
So that leaves fake problems they made for you on purpose.
You might see if there are those Sandvine traffic management boxes I mentioned on your network throttling you.
That may screw up voip. I don't see how it could avoid it since what it does is send you phoney resets all the time.
Bit torrent can take that as can web but voice? Heck no. You will get lots of stuttering, distortion, etc. Pretty much unusable.
Kind of the problem you got. I suspect foul play.
.
Yes, that should not be a problem.
First however, you need a decent router:
http://www.newegg.com/Product/Product.aspx?Item=N82E16833124190&nm_mc=OTC-Froogle&cm_mmc=OTC-Froogle-_-Network+-+Wireless+Routers-_-LINKSYS-_-33124190
In that respect make sure you get the WRT54GL version.
Cisco, has gutted the normal WRT54G and so far has destroyed its quality and usefulness. (Much like the crap it sells anyway.) They have pulled out the memory, destroyed the ability to put better antennas on the unit, etc.
In short, they want to make sure they get as much money as possible, and your wireless sucks ass.
CISCO has SO FAR left the WRT54GL alone, and it is an exceptional beast, once you flash it with dd-wrt.
http://www.dd-wrt.com/dd-wrtv3/index.php
You want the package in this directory:
http://www.dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fv24%2FBroadcom%2FLinksys%2FWRT54GL_1.1/
Pick the voip generic package. (dd-wrt.v24_voip_generic.bin )
Then select the .bin file above as the target flash upgrade in the normal admin page for the WRT54GL.
Wait 5 minutes for the process to complete, and try to pull a web page from it. If you get a web page, wipe the config with the resessed button on the back of the unit, wait 2 minutes, then power cycle the unit.
It should come up as 192.168.1.1 and login with "root" and "admin" as the password.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Try setting the port that your VOIP is plugged to high priority and keep the rest at low. Made this change the other day and it seemed to fix the problem.
I think is covered in the docs. That does the trick. I should have mentioned it. Thanks
I am the OP. Your "answer" is nonresponsive. What's Rapidshare?
I had the same problem, had several Linksys Routers, tried all the 3rd party firmware (except tomato), still choppy VOIP. Installed the Zyxel X-550 and voila, no problems!!! It contains a VERY fast processor. Make sure you install the latest firmware from Zyxel, enable Streamengine (check Auto Classification, Dynamic Fragmentation, and automatic uplink speed), add a "game rule" to forward UDP traffic (ports 5061, 10000-20000) to/from your Vonage box IP address. That's it. Tech For Less has open box units for $33 currently.
Because the guy was complaining about using BitTorrent (which uses TCP) and it's impact on his VoIP (which doesn't).
But bandwidth it bandwidth.
Plus, since the BitTorrent transfers are going to be filling your outgoing packet backlog, if you check out the scripts referenced, you will find that the VoIP packets can "pass on the curve" in the scheduler inside the linux box.
Remember that VoIP is all about _timly_ dilevery, a "late" is indestinguishable from a "drop", so all the elements have to be considered including the protocols that are raising the interference bar (BitTorrent) instead of just the protocall being used.
It's called "Systems Theory"... 8-)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Interesting... It didn't ever "reject" the number I used. I never looked to see if it was just capping or rounding down the value. /doh! 8-)
(e.g. you put in 80 and it seems fine, now I'll have to find out if its being clipped or ignored or what... 8-)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Notoriously false. Take the scripts and do the experiment by setting INTERFACE_SPEED (which is uplink) and tuning the numerator of CEILING to effect 100% or more and test against a near-by speed test site.
You can step right off the edge of the crappy upstream buffer almost instantly.
Since changing the ceiling only (effectively) selects between whether the backlog is in the router or the modem, it becomes a direct demonstration of overloading the upstream buffer.
Yes, I did the experiment extensively.
(Note that this may vary by provider, I have Comcast)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
I figured people would get that part. Since the complaint is that BitTorrent (which does most of its stuff over TCP) is stepping on the VoIP, my point was that fixing the TCP and letting/making the UDP skip to the head of the line are the ways to fix the problem.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
You mention the WRT54G so I assume that you are using a WLAN AP with a built-in router. If so, then your problem is the 802.11 radio link, not the router and not the wired link to your ISP. Basic 802.11 is a best-effort, contention-based protocol. The VoIP box will compete for bandwidth with the BitTorrent box essentially on a first-come, first-served basis. There are extensions to 802.11 that allow the AP to control access to the link in order to exercise QoS policies. Most APs (and client NICs) don't support these extensions, especially in consumer products. Your other choice would be to buy a second AP, run it on a different channel from the first, and give your VoIP box exclusive access to the second AP. A simple hub/switch on the back end will give both APs access to your wired ISP link.
Exactly. If the backlog is in the router, the modem's buffer stays empty and latency is low.
If the backlog is in the modem, packet loss does not skyrocket much but latency does. This is a sign of a large buffer. If the buffer were small as you claim, there would be a packet loss increase but no latency increase.
retrorocket.o not found, launch anyway?
Mine's already hooked up in this order, and I have the same problem as the original poster.