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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: nanog@nanog.org 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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: nanog@nanog.org 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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:58 AM To: Christopher J. Wolff Cc: nanog@nanog.org 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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: nanog@nanog.org 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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:58 AM To: Christopher J. Wolff Cc: nanog@nanog.org 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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jason Lixfeld Sent: Monday, February 10, 2003 9:47 AM To: nanog@nanog.org 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
> > 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
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 :)
> > 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
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
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
> 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
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
> 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
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Stephen J. Wilcox Sent: Monday, February 10, 2003 12:56 PM To: Bill Woodcock Cc: nanog@nanog.org 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
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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
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
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:bicknell@ufp.org] Sent: Monday, February 10, 2003 11:44 AM To: nanog@nanog.org 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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
participants (6)
-
Bill Woodcock -
chaim fried -
Christopher J. Wolff -
Jason Lixfeld -
Leo Bicknell -
Stephen J. Wilcox