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
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.
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
Hmm, didn't know GC was lit up in Canada.
> 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
Indeed, people like me 
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
> 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
> 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
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
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
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>
> > > 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.
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?
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.