[c-nsp] VoIP without QoS

[Paul Stewart]

Interesting approach..;)

So, in theory you could rate-limit *everything* in access-list 106 except
for the VOIP traffic itself therefore "almost guaranteeing" X amount of
bandwidth specific to your needs?

in other words:

access-list 106 deny ip any host x.x.x.x
access-list 106 permit ip any any

Just curious...

Paul
 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jared Mauch
Sent: Tuesday, May 22, 2007 2:29 PM
To: Lamar Owen
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] VoIP without QoS

On Tue, May 22, 2007 at 01:48:48PM -0400, Lamar Owen wrote:
> On Tuesday 22 May 2007, Nassess, George wrote:
> > I am in the process of extending our distributed VoIP call center to 
> > a partner company, and their networking staff are extremely adamant 
> > that they do not wish to implement QoS on their remote LAN, the DS3 
> > link that the voice traffic will traverse, or the core LAN in our 
> > shared datacenter.
> 
> I too would like to see a good discussion of this, as I'm getting 
> prepared to implement VoIP here, on an 8540MSR core with Catalyst 
> 5500-series distribution-access switches (using RSM's and RSFC's in 
> each 5500-series to provide dual layer 3 uplinks into the core, 
> collapsing access and distribution); Cat 5500's and 8500's don't 
> implement all the things VoIP is supposed to require, but I'd like to see
both sides, too.

	I've typically "cheated" in doing voip QoS by rate-limiting TCP
traffic in one direction.  This keeps the TCP traffic from taking the entire
link and results in a basic reservation of traffic.

	here's an example: (you may need to modify this based on platform)

interface Serial0/0
 description T1 to somewhere
 ip address 1.2.3.4 0.0.0.0
 rate-limit input access-group 106 1280000 4470 8000 conform-action transmit
exceed-action drop !
access-list 106 permit tcp any any
!

	The result is ~256k of reserved bw on a t1, enough for ~2x88k
g711ulaw streams.

	simulating the tcp loss with the rate-limit causes tcp to think the
link is smaller, yet leaving headroom for the udp bits :)

	works well for a home network, you may need to adjust depending on
other streaming media applications that are udp based (perhaps they need to
get matched in your access-list 106) and depending on what you do.

	As long as you don't have any true congestion and output drops on
your interfaces (i assume you graph these?) you should be ok without the qos
stuff.
g711ulaw streams.

	simulating the tcp loss with the rate-limit causes tcp to think the
link is smaller, yet leaving headroom for the udp bits :)

	works well for a home network, you may need to adjust depending on
other streaming media applications that are udp based (perhaps they need to
get matched in your access-list 106) and depending on what you do.

	As long as you don't have any true congestion and output drops on
your interfaces (i assume you graph these?) you should be ok without the qos
stuff.

	- jared

--
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/