[55735] in North American Network Operators' Group
RE: VoIP QOS best practices
daemon@ATHENA.MIT.EDU (chaim fried)
Mon Feb 10 13:33:05 2003
Reply-To: <cef@wireone.com>
From: "chaim fried" <cfried@wireone.com>
To: "'Stephen J. Wilcox'" <steve@telecomplete.co.uk>,
"'Bill Woodcock'" <woody@pch.net>
Cc: <nanog@nanog.org>
Date: Mon, 10 Feb 2003 13:19:08 -0500
In-Reply-To: <Pine.LNX.4.44.0302101751450.9430-100000@MrServer>
Errors-To: owner-nanog-outgoing@merit.edu
> -----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
>
