Re: VoIP QOS best practices
On Mon, 10 Feb 2003, Aditya wrote: FWIW, I purchased a Cisco ATA-186 and then a 7960 on eBay (after trying out MS Messenger and finding it lacking) and they just work. I also have used the same units to get a PSTN phone number routed over IP using www.iconnecthere.com -- and you can make it work behind NAT too (but I can assure you it's easier without NAT). Vonage (vonage.com) let's you get your feet wet at $25/month. Limited outbound, but unlimited inbound and you can pick from many area codes. They supply the ATA, and you have 30 days to play. IConnectHere.com is the consumer arm of Delta3. They are OK, but they offer no help if you get stuck. Vonage is truly plug-n-play. Works fine behind NAT, doesn't require any ports to be opened to function behind a nat or firewall. Just make sure 5060/udp and 69/udp can go out and you're off and running. As others have stated, it's more fun to talk about VoIP after you've used it. I've found the voice quality equals or exceeds my POTS line. There is some echo at times when the call starts, then the magic echo-cancellation stuff seems to learn and things get better. The delay is fine, but can be a bit off-putting during a multi-person conference call between excited tech and marketing folks. But if you regularly use a cell phone, you may not even notice this, as I find the delay on my cell to be worse. What I'm guessing Bill is getting at is the common VoIP implementations out there are running UDP. Since it's in spray and pray mode, you'll be worried more about it stepping on your well-behaved TCP traffic than vice-versa. I'm running a codec that tops out around 80Kb/s on an ADSL line and I've yet to find a way to affect my voice traffic. In 6 months of using the service I've yet to have a dropped call, and I regularly make 80 minute+ calls. All in all I think there's less voodoo involved than most people imagine. It just works. Now I need to figure out how to break into my ATA so I can use it for FWD as well (the ATA ships with an md5 key and the config it fetches via tftp is encrypted)... Anyone? C I'm willing to play tech support via email if anyone has questions about getting started. Adi
Re: VoIP QOS best practices
On Mon, 10 Feb 2003, Aditya wrote: FWIW, I purchased a Cisco ATA-186 and then a 7960 on eBay (after trying out MS Messenger and finding it lacking) and they just work. I also have used the same units to get a PSTN phone number routed over IP using www.iconnecthere.com -- and you can make it work behind NAT too (but I can assure you it's easier without NAT). Vonage (vonage.com) let's you get your feet wet at $25/month. Limited outbound, but unlimited inbound and you can pick from many area codes. They supply the ATA, and you have 30 days to play. IConnectHere.com is the consumer arm of Delta3. They are OK, but they offer no help if you get stuck. Vonage is truly plug-n-play. Works fine behind NAT, doesn't require any ports to be opened to function behind a nat or firewall. Just make sure 5060/udp and 69/udp can go out and you're off and running. As others have stated, it's more fun to talk about VoIP after you've used it. I've found the voice quality equals or exceeds my POTS line. There is some echo at times when the call starts, then the magic echo-cancellation stuff seems to learn and things get better. The delay is fine, but can be a bit off-putting during a multi-person conference call between excited tech and marketing folks. But if you regularly use a cell phone, you may not even notice this, as I find the delay on my cell to be worse. What I'm guessing Bill is getting at is the common VoIP implementations out there are running UDP. Since it's in spray and pray mode, you'll be worried more about it stepping on your well-behaved TCP traffic than vice-versa. I'm running a codec that tops out around 80Kb/s on an ADSL line and I've yet to find a way to affect my voice traffic. In 6 months of using the service I've yet to have a dropped call, and I regularly make 80 minute+ calls. All in all I think there's less voodoo involved than most people imagine. It just works. Now I need to figure out how to break into my ATA so I can use it for FWD as well (the ATA ships with an md5 key and the config it fetches via tftp is encrypted)... Anyone? Tough one there. I've tried, but the only thing I've been able to do is reset to factory defaults. In any case, the current ATA software (2.15) doesn't support multiple proxies; you can have two accounts, but they seem to only use one gateway/proxy (and a failover.) Any evidence to the contrary is welcome. I found the way around this is to use Asterisk (http://www.asterisk.org/) and register my iconnecthere.com account from the server. I can have as many SIP accounts registered at the server, and they all act as incoming channels that can then be routed to my ATA-186 (or to voicemail, or to an IVR, or whatever.) I've had success in the last two days in getting my analog line at the house, my INOC-DBA phone, my iconnecthere.com account, and a SIP gateway on the other side of the continent to all make calls inbound/outbound from my single ATA-186 on my desk. There are still some bugs to be worked out, but it's rapidly getting to be a locally-controlled voice system for multiple gateways. FWIW, I'll be posting a summary on the INOC-DBA list shortly on how to get it working. Now, back to the NANOG-ish content: I know a fundamental change in technology when I see it, and VOIP is an obvious winner. VOIP has been smoldering for a few years, and the sudden growth of various easy-to-implement SIP proxies and service platforms, plus the sudden drop in price of SIP hard-phones, is going to push growth tremendously. Currently, the underlying technology is UDP that moves calls around. This is all well and good until you get thousands, tens of thousands, hundreds of thousands of calls going at once. QoS is, as Bill says, not a problem right now on public networks; I've used VOIP across at least three exchange or peering sessions (in each direction, no less!) and suffered no quality loss, even at 80kbps rates. However, when a significant percentage of cable and DSL customers across the country figure this technology out, does this cause problems for those providers? Is it worthwhile for large end-user aggregators to start figuring out how they are going to offer this service locally on their own networks in order to save on transit traffic to other peers/providers? Or is this merely a tiny bump in traffic, not worth worrying about? More interestingly: what happens to the network when the first shared LD software comes into creation? Imagine 1/3 (to pick a worst-case percentage) of your customers producing and consuming (possibly) 80kbps of traffic for 5 hours a day as they offer their local analog lines to anyone who wants to make local calls to that calling area. Overseas calling I expect will show similar growth. Nobody wants to pay $.20 or even $.10 per minute to Asian nations, so as soon as Joe User figures out how this VOIP stuff works, there will be (is?) a tendency for UDP increases on
Re: VoIP QOS best practices
Indeed. I've unfortunately had many instances where a company runs 5+ VoIP calls -- in addition to data traffic -- over a 64k circuit with the line staying at 95-100% capacity 24x7. It's not easy, but it's doable. We're not running VoIP, but we did run an OC3 at 100% 24x7 for 6 months and, with custom queuing and some clever traffic shaping, no one noticed. Eric :)
RE: VoIP QOS best practices
Jason, My strategy would be to use the same carrier at point A and point B and purchase some kind of high-priority MPLS switching config between the two. I believe Global Crossing offers something like this where they differentiate between the proletarian traffic and the uber-business traffic. The other thing to keep in mind is that QoS only comes into play when you saturate your links. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: [EMAIL PROTECTED] Subject: VoIP QOS best practices Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? -jL
Re: VoIP QOS best practices
Providing your sites are local to the same ISP, that would be fine. Worst case scenario and probably a more likely scenario in most cases is that company A has a satellite office in Boston, one in Sydney and one in Tokyo while their head office is in Toronto. Not a very wide range of providers who can reach those areas, not to mention wether or not they can deliver MPLS. On Monday, February 10, 2003, at 11:52 AM, Christopher J. Wolff wrote: Jason, My strategy would be to use the same carrier at point A and point B and purchase some kind of high-priority MPLS switching config between the two. I believe Global Crossing offers something like this where they differentiate between the proletarian traffic and the uber-business traffic. The other thing to keep in mind is that QoS only comes into play when you saturate your links. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: [EMAIL PROTECTED] Subject: VoIP QOS best practices Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? -jL
RE: VoIP QOS best practices
Jason, I believe Global Crossing supports those sites, keep in mind I don't sell their product, but UUNET should as well. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:58 AM To: Christopher J. Wolff Cc: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices Providing your sites are local to the same ISP, that would be fine. Worst case scenario and probably a more likely scenario in most cases is that company A has a satellite office in Boston, one in Sydney and one in Tokyo while their head office is in Toronto. Not a very wide range of providers who can reach those areas, not to mention wether or not they can deliver MPLS. On Monday, February 10, 2003, at 11:52 AM, Christopher J. Wolff wrote: Jason, My strategy would be to use the same carrier at point A and point B and purchase some kind of high-priority MPLS switching config between the two. I believe Global Crossing offers something like this where they differentiate between the proletarian traffic and the uber-business traffic. The other thing to keep in mind is that QoS only comes into play when you saturate your links. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: [EMAIL PROTECTED] Subject: VoIP QOS best practices Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? -jL
Re: VoIP QOS best practices
Hmm, didn't know GC was lit up in Canada. On Monday, February 10, 2003, at 12:01 PM, Christopher J. Wolff wrote: Jason, I believe Global Crossing supports those sites, keep in mind I don't sell their product, but UUNET should as well. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:58 AM To: Christopher J. Wolff Cc: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices Providing your sites are local to the same ISP, that would be fine. Worst case scenario and probably a more likely scenario in most cases is that company A has a satellite office in Boston, one in Sydney and one in Tokyo while their head office is in Toronto. Not a very wide range of providers who can reach those areas, not to mention wether or not they can deliver MPLS. On Monday, February 10, 2003, at 11:52 AM, Christopher J. Wolff wrote: Jason, My strategy would be to use the same carrier at point A and point B and purchase some kind of high-priority MPLS switching config between the two. I believe Global Crossing offers something like this where they differentiate between the proletarian traffic and the uber-business traffic. The other thing to keep in mind is that QoS only comes into play when you saturate your links. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: [EMAIL PROTECTED] Subject: VoIP QOS best practices Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? -jL
Re: VoIP QOS best practices
Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. -Bill
Re: VoIP QOS best practices
On Monday, February 10, 2003, at 12:47 PM, Bill Woodcock wrote: Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. Indeed, people like me :)
Re: VoIP QOS best practices
On Mon, 10 Feb 2003, Bill Woodcock wrote: Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. My conclusion too when I looked at this a couple years back. However, its important that the backbone is operating properly ie not saturated which I think should be the case for all network operators, theres a requirement tho if the customer has a relatively low bandwidth tail to the network which is shared for different applications, its probably a good idea to make sure the voip packets have higher priority than non-realtime data... (this last comment is a suggestion, I've not actually tested this in a real environment, low b/w lab tests tend to exclude other traffic flows) Steve
Re: VoIP QOS best practices
However, its important that the backbone is operating properly ie not saturated which I think should be the case for all network operators, theres a requirement tho if the customer has a relatively low bandwidth tail to the network which is shared for different applications, its probably a good idea to make sure the voip packets have higher priority than non-realtime data... (this last comment is a suggestion, I've not actually tested this in a real environment, low b/w lab tests tend to exclude other traffic flows) We've got plenty of the INOC-DBA phones on the ends of congested satellite tail-circuits, and don't really have significant trouble. As has been pointed out, the VoIP traffic may be stomping all over TCP traffic on the same links, but it _sounds_ good. :-) -Bill
Re: VoIP QOS best practices
Any relationship between the two is just FUD from people who've never used VoIP. Indeed, people like me :) No, no, I didn't mean you, you were just asking the question. I meant the folks who don't want end-users doing their own VoIP because it means lost revenue on circuit-switched networks. And then tehre's the whole IEPREP crowd. -Bill
RE: VoIP QOS best practices
That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
RE: VoIP QOS best practices
That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? As someone who is looking to deploy VoIP in the near future this is of particular interest. C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. -Bill
Re: VoIP QOS best practices
On Mon, 10 Feb 2003, Bill Woodcock wrote: However, its important that the backbone is operating properly ie not saturated which I think should be the case for all network operators, theres a requirement tho if the customer has a relatively low bandwidth tail to the network which is shared for different applications, its probably a good idea to make sure the voip packets have higher priority than non-realtime data... (this last comment is a suggestion, I've not actually tested this in a real environment, low b/w lab tests tend to exclude other traffic flows) We've got plenty of the INOC-DBA phones on the ends of congested satellite tail-circuits, and don't really have significant trouble. As has been of course if your using satellite your already accepting the delay from propogation and delay from buffering from this kind of jitter which is fine, but may not be acceptable for say a commercial voip service in a local area which ought to be comparable to pstn quality.. Steve pointed out, the VoIP traffic may be stomping all over TCP traffic on the same links, but it _sounds_ good. :-) -Bill
RE: VoIP QOS best practices
My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:05 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
Re: VoIP QOS best practices
of course if your using satellite your already accepting the delay from propogation and delay from buffering from this kind of jitter which is fine, but may not be acceptable for say a commercial voip service in a local area which ought to be comparable to pstn quality.. VoIP is nearly always spectacularly better than PSTN quality. Anywhere where VoIP runs over satellite, PSTN is also running over satellite, but the PSTN doesn't have the advantage of modern CODECs or digital end-to-end. -Bill
Re: VoIP QOS best practices
On Monday, February 10, 2003, at 12:59 PM, Bill Woodcock wrote: Any relationship between the two is just FUD from people who've never used VoIP. Indeed, people like me :) No, no, I didn't mean you, you were just asking the question. I meant the folks who don't want end-users doing their own VoIP because it means lost revenue on circuit-switched networks. And then tehre's the whole IEPREP crowd. laugh -- Well, I do admittedly fall under the category of someone who's never used it before, but I'm in a different category than what you describe. Anyway... off to the next reply :) -Bill
Re: VoIP QOS best practices
On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED] said: That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? Qos is designed for dealing with who gets preference when there's a bandwidth shortage. Most places are having a bandwidth glut at the moment, so the VoIP traffic gets through just fine and QoS isn't able to provide much measurable improvement. msg08952/pgp0.pgp Description: PGP signature
RE: VoIP QOS best practices
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stephen J. Wilcox Sent: Monday, February 10, 2003 12:56 PM To: Bill Woodcock Cc: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices On Mon, 10 Feb 2003, Bill Woodcock wrote: Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. My conclusion too when I looked at this a couple years back. However, its important that the backbone is operating properly ie not saturated which I think should be the case for all network operators, theres a requirement tho if the customer has a relatively low bandwidth tail to the network which is shared for different applications, its probably a good idea to make sure the voip packets have higher priority than non-realtime data... (this last comment is a suggestion, I've not actually tested this in a real environment, low b/w lab tests tend to exclude other traffic flows) I have tested this in lab settings for video over IP (t1 with multiple 384k calls and data) , and came to that same conclusion. While it works on the tail and needs to be implemented bi-directionally (which never happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic. Steve
RE: VoIP QOS best practices
My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. -Bill
RE: VoIP QOS best practices
But I could conceivably have 10+ voice channels over a T-1, I still don't quite understand how, without prioritizing voice traffic, the quality won't degrade... C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:20 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. -Bill
RE: VoIP QOS best practices
Indeed, but in this case I'm dealing with a private network that doesn't have so much surplus as to guarantee no contention. C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:23 PM To: Charles Youse Cc: Bill Woodcock; [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED] said: That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? Qos is designed for dealing with who gets preference when there's a bandwidth shortage. Most places are having a bandwidth glut at the moment, so the VoIP traffic gets through just fine and QoS isn't able to provide much measurable improvement.
RE: VoIP QOS best practices
But I could conceivably have 10+ voice channels over a T-1, I still don't quite understand how, without prioritizing voice traffic, the quality won't degrade... Well, of course it all depends how much other traffic you're trying to get through simultaneously. Your T1 will carry ~170 simultaneous voice streams with no conflict, but you have to realize that they'll stomp on your simultaneous TCP data traffic. But you don't need to protect the _voice_... Look, just do it, and you'll see that there aren't any problems in this area. -Bill
RE: VoIP QOS best practices
There are two aspects to QoS that you have direct control over: 1) traffic leaving your network (easy to QoS since you (most of the time) have access to the egress equipment) and 2) traffic arriving on your end-point which is harder to do, but more and more service providers are assisting with QoS on that final ingress link to your network to ensure timely delivery of voice vs your regular traffic. Ray Burkholder -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 13:58 To: Stephen J. Wilcox Cc: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices However, its important that the backbone is operating properly ie not saturated which I think should be the case for all network operators, theres a requirement tho if the customer has a relatively low bandwidth tail to the network which is shared for different applications, its probably a good idea to make sure the voip packets have higher priority than non-realtime data... (this last comment is a suggestion, I've not actually tested this in a real environment, low b/w lab tests tend to exclude other traffic flows) We've got plenty of the INOC-DBA phones on the ends of congested satellite tail-circuits, and don't really have significant trouble. As has been pointed out, the VoIP traffic may be stomping all over TCP traffic on the same links, but it _sounds_ good. :-) -Bill
RE: VoIP QOS best practices
Indeed, but in this case I'm dealing with a private network that doesn't have so much surplus as to guarantee no contention. You don't need a guarantee of no contention, you just have to be able to live with your web browser being slow if there isn't enough bandwidth to support both your phone call and your simultaneous web browsing. But the voice only uses about 9kbps per call, worst case, so you've got to have a _lot_ of simultaneous calls before it has a noticable effect on the rest of your traffic. -Bill
RE: VoIP QOS best practices
QoS isn't necessarily about throwing packets away. It is more like making voice packets 'go to the head of the line'. Of course, if you have saturation, some packets will get dropped, but at least the voice packets won't get dropped since they were prioritized higher. Ray Burkholder -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:05 To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
RE: VoIP QOS best practices
Yes, but most companies do not want to upgrade the access link to unneeded levels just to ensure that VOIP never has contention. It is on the access link where QOS matters, ingress and egress. That is where we (ATT) have deployed it and where it makes sense. It's not about pitting one customer's traffic against another's across the core. The core is over-provisioned for high bandwidth and simplicity. It is pitting one customers applications against their other applications. It is about large packets (1500 byte) vs. small VOIP packets. It is about getting the VOIP out the door while less sensitive applications wait in queue if that is what is required on the access link. It is usually about T1 and below. Michelle Michelle Truman CCIE # 8098 Principal Technical Consultant ATT Solutions Center mailto:[EMAIL PROTECTED] VO: 651-998-0949 (NEW NUMBER) w 612-376-5137 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 12:23 PM To: Charles Youse Cc: Bill Woodcock; [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED] said: That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? Qos is designed for dealing with who gets preference when there's a bandwidth shortage. Most places are having a bandwidth glut at the moment, so the VoIP traffic gets through just fine and QoS isn't able to provide much measurable improvement.
RE: VoIP QOS best practices
QoS isn't necessarily about throwing packets away. It is more like making voice packets 'go to the head of the line'. Of course, if you have saturation, some packets will get dropped, but at least the voice packets won't get dropped since they were prioritized higher. Why bother? It's a pain in the ass, and doesn't give any noticable benefit. -Bill
Re: VoIP QOS best practices
In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried wrote: happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic. I've got a question about this issue. Many networks reorder packets for a number of reasons. At least once before I've attempted to measure the effects of this reordering on a number of forms of traffic, but I have never understood the particular effects on VOIP traffic. Indeed, the two times I was asked to investigate this for video people it turns out the video receivers /had no ability to handle out of order frames/. That's right, get one packet out of order and the video stream goes away until it resynchronizes. Now, I realize reordering should not happen to a large percentage of the packets out there, but it also seems to me any IP application has to handle reordering or it's not really doing IP. So what's the real problem here? Are the VOIP boxes unable to handle out of order packets? Do the out of order packets simply arrive far enough delayed to blow the delay budget? What percentage of reordered packets starts to cause issues? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg08964/pgp0.pgp Description: PGP signature
RE: VoIP QOS best practices
--On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED] wrote: It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: VoIP QOS best practices
QoS is important on T1 circuits and makes voice higher priority. Voice can even be done on sub T1 circuits with excellent results. In this regard, there are some additional packet sizing and fragementation issues to worry about in order to make voice packet timing constant, but nothing impossible to over-come. There are commonly accepted industry practices for this. Old hat for many practitioners in the Voip world. Ray Burkholder -Original Message- From: Charles Youse [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:09 To: Bill Woodcock Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:05 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
RE: VoIP QOS best practices
Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. C. -Original Message- From: Alec H. Peterson [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:40 PM To: Bill Woodcock; Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices --On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED] wrote: It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: VoIP QOS best practices
Depends upon the codec you are using. G.711 uses about 80 kbps in each direction, g.729 takes about 16 to 24 kpbs in each direction. So it is easy to do the math on how much capacity you need, and what your bandwidth budget is when you factor in traffic from other services. If you operate in a cisco world, they have info on their site for traffic engineering your outbound traffic. And if you have good relationship with your upstream provider, they could use the same rules to ensure traffic is regulated into your pipe. Ray Burkholder -Original Message- From: Charles Youse [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:22 To: Bill Woodcock Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices But I could conceivably have 10+ voice channels over a T-1, I still don't quite understand how, without prioritizing voice traffic, the quality won't degrade... C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:20 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. -Bill
RE: VoIP QOS best practices
Ok, I've taken all the courses and done some stuff myself. Here is roughly what to expect. It IS important to do QoS at the CPE. This ensures that during times of congestion, voice traffic gets out to the real world in a timely fashion. In networks supported by Nanog people, usually they have bandwdith to spare, and so QoS isn't necessarily important. The issue is when traffic crosses ISP boundaries, because many times these links are clogged. It used to be you had to stay away from MAEWEST and such because of big packet drops and delays (big no-no's for voice). Things are getting better in this regard because of a larger number of cross connects between carriers. General rule of thumb used by the big Voip guys is to send most of your voip traffic through what could loosely be termed as Tier 1 providers (please don't flame me on this remark). They you can be pretty sure that there is much excess bandwidth, fast switches, and fast transit time with little drop out (all important criteria for good voice quality). The issues are always when crossing carriers, and at the network edge. These are the troublesome spots. Some solutions include peering with multiple Tier 1 providers, and doing traffic engineering to ensure your traffic goes through the best provider to the end destination, etc, ... When you get into IP Telphony in a LAN environment I can get into a whole other discussion of myth dispelling. For example, just because your LAN switch has underutilized GigE and FE ports, did you know that you can still suffer horrible voice quality? QoS fixes this in a LAN enviroment which could be viewed as bursty system where as internet switches tend to be more smooth flow in nature (if I'm wrong on this one, I'd like to hear about it). Ray Burkholder -Original Message- From: Charles Youse [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:03 To: Bill Woodcock; [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? As someone who is looking to deploy VoIP in the near future this is of particular interest. C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. -Bill
RE: VoIP QOS best practices
If you are in an environment where the uplink is already saturated, or nearly so, QOS is necessary. But QOS only discards packets in times of contention. So, if you don't have contention, you don't need it. IF you have 300 people and 4meg of data all fighting for that t1, it makes a world of difference. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:28 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices But I could conceivably have 10+ voice channels over a T-1, I still don't quite understand how, without prioritizing voice traffic, the quality won't degrade... Well, of course it all depends how much other traffic you're trying to get through simultaneously. Your T1 will carry ~170 simultaneous voice streams with no conflict, but you have to realize that they'll stomp on your simultaneous TCP data traffic. But you don't need to protect the _voice_... Look, just do it, and you'll see that there aren't any problems in this area. -Bill
RE: VoIP QOS best practices
On Mon, 10 Feb 2003, Ray Burkholder wrote: QoS isn't necessarily about throwing packets away. It is more like making voice packets 'go to the head of the line'. Of course, if you have saturation, some packets will get dropped, but at least the voice packets won't get dropped since they were prioritized higher. Thats what I meant too... To qualify further on where it needs to be deployed, its required on whatever the slowest link in the typical path to the Internet. What I mean is that if you download your email you will utilise the whole bandwidth of the slowest link in the chain, this may be a dialup modem but more likely in the office to be your T1, you dont want this full utilisation of the link (which will occur in small bursts of a few seconds, dont forget with voice we are interested in per second traffic volumes not 5 minute averages!) to affect the jitter you need to implement priorities at this point. Steve Ray Burkholder -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:05 To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
RE: VoIP QOS best practices
--On Monday, February 10, 2003 13:41 -0500 Charles Youse [EMAIL PROTECTED] wrote: Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. The other dimension is voice quality. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: VoIP QOS best practices
On Mon, 10 Feb 2003 10:27:39 -0800 (PST), Bill Woodcock [EMAIL PROTECTED] said: Look, just do it, and you'll see that there aren't any problems in this area. For those looking to just do it, it's not very complicated or expensive to try -- and the quality is very, very good esp. if you have broadband. For an easy, step-by-step way to try it out over the public, non-QoS Internet, look at the steps at: http://www.pulver.com/fwd (yes, there are other free, public SIP servers, but I haven't found any with as much useful documentation and I'm not associated with pulver.com except for being an enthusiastic FWD user) FWIW, I purchased a Cisco ATA-186 and then a 7960 on eBay (after trying out MS Messenger and finding it lacking) and they just work. I also have used the same units to get a PSTN phone number routed over IP using www.iconnecthere.com -- and you can make it work behind NAT too (but I can assure you it's easier without NAT). I'm willing to play tech support via email if anyone has questions about getting started. Adi
Re: VoIP QOS best practices
You're specifically talking about the g728a codec? I typically have been using g711ulaw which is a 64k vs the g728a codec that is 8k. Aside from that, Bill is quite correct here. There's little need for QoS other than at the edge of ones network to insure that your circuit is not full of other streaming media applications that put your tcp performance in the toilet. - jared On Monday, February 10, 2003, at 01:19 PM, Bill Woodcock wrote: My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. -Bill
Re: VoIP QOS best practices
On Mon, 10 Feb 2003, Jared Mauch wrote: I typically have been using g711ulaw which is a 64k vs the g728a codec that is 8k. g729a, yes. -Bill
RE: VoIP QOS best practices
G.711 gives you the 64kbps quality you get on a channel in a PRI line. No compression is performed. G.729 is a well accepted codec that performs compression, and with ip packet overhead, uses about 16 to 24 kbps (can't remember which). It gives voice quality very close to G.711. G.723 has a noticeable voice quality change, and is in the 6 to 8 kbps range. The optimal is G.729 for quality vs bandwidth issues. There are some other considerations involved but these are the main ones. Ray Burkholder -Original Message- From: Charles Youse [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:42 To: Alec H. Peterson Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. C. -Original Message- From: Alec H. Peterson [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:40 PM To: Bill Woodcock; Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices --On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED] wrote: It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: VoIP QOS best practices
On Mon, 10 Feb 2003, Leo Bicknell wrote: In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried wrote: happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic. snip So what's the real problem here? Are the VOIP boxes unable to handle out of order packets? Do the out of order packets simply arrive far enough delayed to blow the delay budget? What percentage of reordered packets starts to cause issues? You have two choices Drop them - you either have gaps in the stream or the codec allows for gaps and reconsutrcts small missing sections (buffer to do this) Reorder them - fine, but you need to buffer, we want to minimise delay so how long do you want to wait, what delay is acceptable on top of the other delays we have as well.. (same outcome as jitter) As to what percentage is a problem, that depends on which of the two above ways you are using and how much delay you want. Or in the drop it scenario how many missing frames cause the speech to become degraded. Steve
Re: VoIP QOS best practices
On Mon, Feb 10, 2003 at 10:34:14AM -0800, Bill Woodcock wrote: QoS isn't necessarily about throwing packets away. It is more like making voice packets 'go to the head of the line'. Of course, if you have saturation, some packets will get dropped, but at least the voice packets won't get dropped since they were prioritized higher. Why bother? It's a pain in the ass, and doesn't give any noticable benefit. So QoS on the access link can do two things: - Reduce jitter on selected packets (by moving them to the head of the queue) - Reduce packet loss on selected packets (by preferentially dropping non-selected packets, _if_ there is congestion). So, has anyone done measurements to see if either of these makes a difference in the real world? IP phones have jitter buffers to reduce the effects of jitter. Does reducing packet jitter make a noticable difference? VoIP can withstand a small amount of packet loss without too much loss of quality. Does normal TCP backoff keep the UDP packet loss low enough in the event of congestions? It seems that Bill's experience with a real-world deployment indicates that, _subjectively_, percieved quality without QoS is good enough. Anyone have real counter-examples, or real measurements? Steve
RE: VoIP QOS best practices
There are many companies with branch offices scattered across the country who already have data circuits in place. Why not use those circuits, which in many cases are data T1's, for sharing both voice and data? Long distance rates are so low now-a-days, it is hard to justify voip for that reason alone anymore. But voip on circuits between branch offices allows the capability of uniform dialling plans, user extension between branch offices, traffic management, access to messaging systems, etc, etc. For corporate communcations, when mixed with other technologies, voip is a very powerful tool. And in some contexts, converts in the realm of IP Telephony. Ray Burkholder -Original Message- From: Jim Cabe [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 15:31 To: Ray Burkholder Cc: Charles Youse; Bill Woodcock; [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices Its better to use TDM when trying to share a line anyway. VOIP is only practical for a mobile work force. On Mon, 10 Feb 2003, Ray Burkholder wrote: QoS is important on T1 circuits and makes voice higher priority. Voice can even be done on sub T1 circuits with excellent results. In this regard, there are some additional packet sizing and fragementation issues to worry about in order to make voice packet timing constant, but nothing impossible to over-come. There are commonly accepted industry practices for this. Old hat for many practitioners in the Voip world. Ray Burkholder -Original Message- From: Charles Youse [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:09 To: Bill Woodcock Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:05 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
RE: VoIP QOS best practices
Many boxes are able to reorder packets. If packets arrive too late to be inserted into the conversion stream, they are dropped. One dropped packet in a sequence can usually be 'hidden' or 'faked' by the codec. When more than one packet is missed in sequence, it becomes noticeable to the listener. Ray Burkholder -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:44 To: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried wrote: happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic. So what's the real problem here? Are the VOIP boxes unable to handle out of order packets? Do the out of order packets simply arrive far enough delayed to blow the delay budget? What percentage of reordered packets starts to cause issues? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
RE: VoIP QOS best practices
Also note that those sizes are for the voice part of the payload onlyIt does not take into account any payload/packet overhead... We use G.711 quite a bit on our network, and are traffic flows are right around 80k... Spencer Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: [EMAIL PROTECTED] Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 * Ray Burkholder [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 02/10/2003 02:21 PM To: Charles Youse [EMAIL PROTECTED], Alec H. Peterson [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices G.711 gives you the 64kbps quality you get on a channel in a PRI line. No compression is performed. G.729 is a well accepted codec that performs compression, and with ip packet overhead, uses about 16 to 24 kbps (can't remember which). It gives voice quality very close to G.711. G.723 has a noticeable voice quality change, and is in the 6 to 8 kbps range. The optimal is G.729 for quality vs bandwidth issues. There are some other considerations involved but these are the main ones. Ray Burkholder -Original Message- From: Charles Youse [mailto:[EMAIL PROTECTED]] Sent: February 10, 2003 14:42 To: Alec H. Peterson Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. C. -Original Message- From: Alec H. Peterson [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:40 PM To: Bill Woodcock; Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices --On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED] wrote: It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: VoIP QOS best practices
Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. Yeah, if you're operating in the modern world, your tradeoffs are audio quality, bandwidth utilization, and DSP resource utilization. If you're in the circuit-switched world, add in cost of software loads which contain the CODEC you want. -Bill
Re: VoIP QOS best practices
It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. The correct answer here is that it depends. Most multimegabit connections are underutilized enough not to introduce significant jitter to change VoIP behaviour, however specially when going to corporate networks where peak hour usage is very near or at available bandwidth the mechanics are different. However, in our experience VoIP performance is more often hurt by either broken router code or misconfigured devices in the path (route cache purges, duplex mismatches, etc.) than actual lack of bandwidth. If it does not cost you, it´s a good idea to let the VoIP packets first to a low-bandwidth link but putting serious engineering or money for hardware is not neccessary. Fancy queueing will give you more consistent performance when something else uses up the link(s). Pete
RE: VoIP QOS best practices
Good point. Later version from the larger video-conferencing Gateway manufacturers, seem to do a better job (better- not perfect) handling reordering. So clearly there seems to have been issues with the applications buffering itself. Out of order packets are considered lost, so whatever you would put your tolerance threshold for loss will determine your tolerance for ou of sequence? I would measure in terms of .0x% for my customers, who expect toll-quality video. Based on the traces we've examined, most of the time it's not that the latency is too much to be rectified with proper buffering. However, again we don't want anybody reordering our packets. -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 11:44 AM To: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried wrote: happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic. I've got a question about this issue. Many networks reorder packets for a number of reasons. At least once before I've attempted to measure the effects of this reordering on a number of forms of traffic, but I have never understood the particular effects on VOIP traffic. Indeed, the two times I was asked to investigate this for video people it turns out the video receivers /had no ability to handle out of order frames/. That's right, get one packet out of order and the video stream goes away until it resynchronizes. Now, I realize reordering should not happen to a large percentage of the packets out there, but it also seems to me any IP application has to handle reordering or it's not really doing IP. So what's the real problem here? Are the VOIP boxes unable to handle out of order packets? Do the out of order packets simply arrive far enough delayed to blow the delay budget? What percentage of reordered packets starts to cause issues? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: VoIP QOS best practices
You are mistaking utilization for congestion. At the packet level, a link is congested if it is not immediately available for transmit due to one or more previous packets still being queued/transmitted. This transient congestion causes jitter, VoIP's worst enemy. Certainly, as utilization rises so will congestion; however, it is quite common to have transient congestion while overall utilization is minimal. S - Original Message - From: Shawn Solomon [EMAIL PROTECTED] Sent: Monday, 10 February, 2003 12:54 Subject: RE: VoIP QOS best practices If you are in an environment where the uplink is already saturated, or nearly so, QOS is necessary. But QOS only discards packets in times of contention. So, if you don't have contention, you don't need it. IF you have 300 people and 4meg of data all fighting for that t1, it makes a world of difference. - -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]]=20 Sent: Monday, February 10, 2003 1:28 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices But I could conceivably have 10+ voice channels over a T-1, I still don't quite understand how, without prioritizing voice traffic, the quality won't degrade... Well, of course it all depends how much other traffic you're trying to get through simultaneously. Your T1 will carry ~170 simultaneous voice streams with no conflict, but you have to realize that they'll stomp on your simultaneous TCP data traffic. But you don't need to protect the _voice_... Look, just do it, and you'll see that there aren't any problems in this area. -Bill --
Re: VoIP QOS best practices
Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism. Reordering is also unlikely, since each packet is sent 20ms or more apart; I'm not aware of any network devices that reorder on that scale. S - Original Message - From: Leo Bicknell [EMAIL PROTECTED] Sent: Monday, 10 February, 2003 12:43 Subject: Re: VoIP QOS best practices - --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried = wrote: happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic.=20 I've got a question about this issue. Many networks reorder packets for a number of reasons. At least once before I've attempted to measure the effects of this reordering on a number of forms of traffic, but I have never understood the particular effects on VOIP traffic. Indeed, the two times I was asked to investigate this for video people it turns out the video receivers /had no ability to handle out of order frames/. That's right, get one packet out of order and the video stream goes away until it resynchronizes. Now, I realize reordering should not happen to a large percentage of the packets out there, but it also seems to me any IP application has to handle reordering or it's not really doing IP. So what's the real problem here? Are the VOIP boxes unable to handle out of order packets? Do the out of order packets simply arrive far enough delayed to blow the delay budget? What percentage of reordered packets starts to cause issues? - --=20 Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org - --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE+R/LkNh6mMG5yMTYRAsn4AJ9Y1vO1RILDjvGdTJUPmiiknUlpHgCfedQm rOH5KvKO+PVnSVoLPZkG4zI= =LCXI - -END PGP SIGNATURE- - --OXfL5xGRrasGEqWY-- --
RE: VoIP QOS best practices
But in order for RTP to resync the out-of-order packets it must introduce some delay, no? And that delay causes issues. C. -Original Message- From: Stephen Sprunk [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 5:21 PM To: Leo Bicknell Cc: North American Noise and Off-topic Gripes Subject: Re: VoIP QOS best practices Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism. Reordering is also unlikely, since each packet is sent 20ms or more apart; I'm not aware of any network devices that reorder on that scale. S - Original Message - From: Leo Bicknell [EMAIL PROTECTED] Sent: Monday, 10 February, 2003 12:43 Subject: Re: VoIP QOS best practices - --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried = wrote: happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic.=20 I've got a question about this issue. Many networks reorder packets for a number of reasons. At least once before I've attempted to measure the effects of this reordering on a number of forms of traffic, but I have never understood the particular effects on VOIP traffic. Indeed, the two times I was asked to investigate this for video people it turns out the video receivers /had no ability to handle out of order frames/. That's right, get one packet out of order and the video stream goes away until it resynchronizes. Now, I realize reordering should not happen to a large percentage of the packets out there, but it also seems to me any IP application has to handle reordering or it's not really doing IP. So what's the real problem here? Are the VOIP boxes unable to handle out of order packets? Do the out of order packets simply arrive far enough delayed to blow the delay budget? What percentage of reordered packets starts to cause issues? - --=20 Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org - --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE+R/LkNh6mMG5yMTYRAsn4AJ9Y1vO1RILDjvGdTJUPmiiknUlpHgCfedQm rOH5KvKO+PVnSVoLPZkG4zI= =LCXI - -END PGP SIGNATURE- - --OXfL5xGRrasGEqWY-- --
Re: VoIP QOS best practices
Thus spake Bill Woodcock [EMAIL PROTECTED] QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. To paraphrase Randy, I encourage all of my competitors to think like this. Iff you operate a network with enough excess capacity to keep jitter and packet loss within acceptable limits, you do not need QOS. Most real networks are far from that ideal, however. S
Re: VoIP QOS best practices
Thus spake Ray Burkholder [EMAIL PROTECTED] QoS is important on T1 circuits and makes voice higher priority. QOS is a much broader subject than just giving voice priority treatment. Voice can even be done on sub T1 circuits with excellent results. Indeed. I've unfortunately had many instances where a company runs 5+ VoIP calls -- in addition to data traffic -- over a 64k circuit with the line staying at 95-100% capacity 24x7. It's not easy, but it's doable. S
Re: VoIP QOS best practices
Thus spake [EMAIL PROTECTED] On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED] said: That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? Qos is designed for dealing with who gets preference when there's a bandwidth shortage. Most places are having a bandwidth glut at the moment, so the VoIP traffic gets through just fine and QoS isn't able to provide much measurable improvement. That's certainly true of ISPs, but most VoIP is over bandwidth-starved private networks. S
Re: VoIP QOS best practices
Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism. Most VoIP implementations don´t care about storing out-of-order packets because they think that 20ms or 30ms late packets should be thrown away in any case. Reordering is also unlikely, since each packet is sent 20ms or more apart; I'm not aware of any network devices that reorder on that scale. Most core routers, at least from vendors C and J have enough packet memory to keep packets for hundreds of milliseconds. Apply sufficent per packet load balancing (which would be stupid but doable) to this, and you´ll arrive at the end result. Our observations tell us that reordering does not happen too much but there are periods from a few minutes to an hour where reordering from specific AS´s skyrocket to return to normal, in many cases even without observable path change. (MPLS in action?) Pete
Re: VoIP QOS best practices
From: Charles Youse My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. I have run VOIP from Germany without any optimization, customization, QOS, crossing public Internet, going through a firewall that slows everything and its dog down, across heavily loaded T1 into my office in LoneGrove, Oklahoma, and I don't get a delay one, no echo, no problems. Granted, I'm sustaining a single voice thread here, although it might be useful to point out that I'm using two different platforms on each side. VOIP can give you problems, but QOS is usually the least of your worries. I'm more concerned with the products I'm using and how they handle echo, latency, etc. This is a market that you test before you buy, and then test some more. If you go off promo material, you're digging a quick grave, IMHO. -Jack
Re: VoIP QOS best practices
On Tue, 11 Feb 2003, Petri Helenius wrote: Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism. Most VoIP implementations don´t care about storing out-of-order packets because they think that 20ms or 30ms late packets should be thrown away in any case. Reordering is also unlikely, since each packet is sent 20ms or more apart; I'm not aware of any network devices that reorder on that scale. Most core routers, at least from vendors C and J have enough packet memory to keep packets for hundreds of milliseconds. Apply sufficent Really.. including many Gigabit, OC-12,48 interfaces per packet load balancing (which would be stupid but doable) to this, and you´ll arrive at the end result. And its unlikely you will be doing this therefore.. Our observations tell us that reordering does not happen too much but there are periods from a few minutes to an hour where reordering from specific AS´s skyrocket to return to normal, in many cases even without observable path change. (MPLS in action?) Pete
Re: VoIP QOS best practices
The issue is when traffic crosses ISP boundaries, because many times these links are clogged. It used to be you had to stay away from MAEWEST and such because of big packet drops and delays (big no-no's for voice). Things are getting better in this regard because of a larger number of cross connects between carriers. When crossing carrier boundaries I would be more concerned with convergence times - kurtis -
