[c-nsp] VoIP without QoS
alaerte.vidali at nsn.com
alaerte.vidali at nsn.com
Tue May 22 15:47:06 EDT 2007
Hi,
My 2 cents about Mr. QoS versus Mr. Excess bandwidth :)
I have seen big networks without QoS working properly. But in that case
it were dedicated networks (mostly voice with minor data sessions)
On the other hand, I have seen networks without congestion and wrong QoS
implementation causing drops (policer of priority queue) on Voice UDP
packets.
What I recommend is really monitor QoS (if any) to see if it is
appropriate for the network. (number of drops on different classes)
Most of the time UDP is the guy that takes more bandwidth, as TCP is
sensitive to drops and decrease the rate when there is congestion. So, I
suggest to keep an eye in UDP traffic other than Voice UDP traffic.
Another question that may arise is:
-Should we drop excessive Voice packets?
and
-Are we able to drop per session voice packets?
If the answer is not, the QoS tool may discard several different call
sessions, decreasing the overall quality of voice calls.
Related to this, we should consider if the number of calls can be
decreased if there is congestion (call admission control mechanism).
Also important is signaling. To keep the Voice session, give proper
priority to signaling is so important as give proper priority to Voice
(probably more important, as drop signaling may cause drop on call)
Good Lucky,
Alaerte
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]
Sent: Tuesday, May 22, 2007 4:05 PM
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 54, Issue 69
Send cisco-nsp mailing list submissions to
cisco-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of cisco-nsp digest..."
Today's Topics:
1. Re: VoIP without QoS (Jared Mauch)
2. Re: VoIP without QoS (Paul Stewart)
3. SPA-POS-1xOC48 on SXF or SRA on 7600? (Phil Bedard)
4. Re: VoIP without QoS (Jared Mauch)
5. Re: VoIP without QoS (Eric Kagan)
6. Re: VoIP without QoS (Dan)
7. Re: VoIP without QoS (Pelle)
----------------------------------------------------------------------
Message: 1
Date: Tue, 22 May 2007 14:29:04 -0400
From: Jared Mauch <jared at puck.nether.net>
Subject: Re: [c-nsp] VoIP without QoS
To: Lamar Owen <lowen at pari.edu>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20070522182903.GD12623 at puck.nether.net>
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 2
Date: Tue, 22 May 2007 14:35:25 -0400
From: "Paul Stewart" <paul at paulstewart.org>
Subject: Re: [c-nsp] VoIP without QoS
To: "'Jared Mauch'" <jared at puck.nether.net>, "'Lamar Owen'"
<lowen at pari.edu>
Cc: cisco-nsp at puck.nether.net
Message-ID: <003c01c79c9f$f6a1cb00$213dc0c0 at nexicomgroup.net>
Content-Type: text/plain; charset="us-ascii"
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/
------------------------------
Message: 3
Date: Tue, 22 May 2007 14:36:08 -0400
From: Phil Bedard <philxor at gmail.com>
Subject: [c-nsp] SPA-POS-1xOC48 on SXF or SRA on 7600?
To: cisco-nsp List <cisco-nsp at puck.nether.net>
Message-ID: <D7FB86B7-40E7-4890-8821-A61B03142BBF at gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Looking at the datasheet for the 1-port OC48 POS it says that
the
minimum release on the 7600 for that SPA is 12.2(33)SRA but in the
hardware configuration docs for the SIP-400 it give some caveats for
the OC48 SPA when running 12.2(18)SXF... The SIP-400 is supported in
SXE... I'm a bit confused by the docs on when support first showed
up for that SPA...
Phil
------------------------------
Message: 4
Date: Tue, 22 May 2007 14:43:46 -0400
From: Jared Mauch <jared at puck.nether.net>
Subject: Re: [c-nsp] VoIP without QoS
To: Paul Stewart <paul at paulstewart.org>
Cc: cisco-nsp at puck.nether.net, 'Jared Mauch' <jared at puck.nether.net>
Message-ID: <20070522184345.GE12623 at puck.nether.net>
Content-Type: text/plain; charset=us-ascii
On Tue, May 22, 2007 at 02:35:25PM -0400, Paul Stewart wrote:
> 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...
Sure, I don't know what your network looks like so don't want
to give you terrible advice, but there are things to do.. but at the
same time, I have to already "get" the packet in order to rate-limit
it. If someone sends me a 500M TCP/SYN flood down my t1, and i'm
rate-limiting it on a 2600, i'm not going to get all of those
packets.
If you're in a closed network where you have less of this
malicious traffic and are properly segmenting those hosts that are
still doing tcp/445 and other scans, you will be in a much better
situation.
(this all assumes that you have good acl performance, or enough
cpu
to handle the acl processing).
- Jared
> -----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/
--
Jared Mauch | pgp key available via finger from jared at puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.
------------------------------
Message: 5
Date: Tue, 22 May 2007 14:46:39 -0400
From: "Eric Kagan" <ekagan at axsne.com>
Subject: Re: [c-nsp] VoIP without QoS
To: "'Jared Mauch'" <jared at puck.nether.net>, "'Lamar Owen'"
<lowen at pari.edu>
Cc: cisco-nsp at puck.nether.net
Message-ID: <014801c79ca1$88a79420$760da8c0 at axsdom.local>
Content-Type: text/plain; charset="us-ascii"
>
> 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
Who or why are people against using a policy map that allows "up to x"
of
bandwidth for the specified (ACL, class-map) but is available for all
other
traffic when there is no VOIP ? This seems backwards / worse to me to
restrict the pipe and loose that much available bandwidth for other apps
when there is no VOIP ?
Eric
------------------------------
Message: 6
Date: Tue, 22 May 2007 13:47:15 -0500
From: Dan <dan at technc.com>
Subject: Re: [c-nsp] VoIP without QoS
To: Jared Mauch <jared at puck.nether.net>
Cc: cisco-nsp at puck.nether.net
Message-ID: <46533AB3.60409 at technc.com>
Content-Type: text/plain; charset=ISO-8859-1
We have a voip system we have been running in our department now for
about a year. Only 12 phones, connected through various wireless links
with throughput of up to 40mbit. Speed is definitely not an issue for
us, but we notice glitches with the quality on an ongoing basis. We are
currently implementing qos and are wondering what is the best way?
Jared,
You mentioned you "cheat" by rate limiting other traffic. What is the
recommended way to implement qos for voip and video? We have 3550,3560
and 2960 switches.
Dan.
, Jared Mauch wrote:
> 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
>
>
------------------------------
Message: 7
Date: Tue, 22 May 2007 21:04:51 +0200
From: Pelle <lists at ip4all.net>
Subject: Re: [c-nsp] VoIP without QoS
To: cisco-nsp at puck.nether.net
Message-ID: <20070522190451.GB20983 at ip4all.net>
Content-Type: text/plain; charset=iso-8859-1
On Tue, May 22, 2007 at 01:47:15PM -0500, Dan wrote:
> What is the recommended way to implement qos for voip and video? We
have
> 3550,3560 and 2960 switches.
If you have got cisco phones, you might try the "auto qos" feature. It
doesn't
cope with video (as far as I can recall), but might suffice for the voip
traffic. And it's very easy to implement :)
--
Pelle
------------------------------
_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 54, Issue 69
*****************************************
More information about the cisco-nsp
mailing list