Qos / ATM / VoIP - where to rate-limit / police

[Erik Dekkers]

Hi folks,

This question probably passed a couple of times. But I didn't found a consistent answer unfortunately

Setup:

Cisco 886VA-K9

Cisco IOS Software, C880 Software (C880DATA-UNIVERSALK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2)

This router has two VLAN's on one Ehternet interface

VLAN1: data

VLAN2: voice

The WAN connection is a regular DSL line with PPP.

Modem FW  Version:      120306_1254-4.02L.03.B2pvC035j.d23j

Modem PHY Version:      B2pvC035j.d23j

Output of show interface brief:

Interface                  IP-Address      OK? Method Status                Protocol

ATM0                       unassigned      YES NVRAM  up                    up

BRI0                       unassigned      YES NVRAM  administratively down down

BRI0:1                     unassigned      YES unset  administratively down down

BRI0:2                     unassigned      YES unset  administratively down down

BVI1                       192.168.5.99    YES NVRAM  up                    up

BVI2                       192.168.10.99   YES NVRAM  up                    up

Dialer0                    ***.***.***.*** YES manual up                    up

Ethernet0                  unassigned      YES NVRAM  administratively down down

FastEthernet0              unassigned      YES unset  up                    up

FastEthernet1              unassigned      YES unset  down                  down

FastEthernet2              unassigned      YES unset  down                  down

FastEthernet3              unassigned      YES unset  down                  down

NVI0                       unassigned      YES unset  administratively down down

Virtual-Access1            unassigned      YES unset  up                    up

Virtual-Access2            unassigned      YES unset  up                    up

Vlan1                      unassigned      YES unset  up                    up

Vlan2                      unassigned      YES unset  up                    up

We all know you can't manage data traffic on the internet since your not in control of both sides of the link. So only queuing would not be a good practice IMHO. I was thinking on just rate-limit or police data-traffic so Voice always has bandwidth available when needed. I've did tried to rate-limit on the ATM0 interface, but no luck. Voice was still very bad.

My question is: where to rate-limit the data traffic? On the VLAN interface, the ATM interface, DIALER interface?

regards

Erik Dekkers

[paul driver]

Hello

What do you want to do ? -Prioritise your voice traffic or police your wan traffic or both? (One thing,- I suggest not to use CAR as cisco recommends to MQC Shaping/Policing now)

Below is a sample config for LLQ for voice traffic and shaping outbound traffic to 10mb

access-list 100 permit udp any any range 16384 32000

access-list 100 permit tcp any any eq 1720

class-map match-all voice

match access-group 100

Policy-map Voice_child
class voice

  priority percent 15

class class-default

policy-map Voice_Parent

class class-default

  shape average 1024000

  service-policy Voice_child

int x/x (wan)

service-policy output Voice_Parent

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Erik Dekkers]

Hi Paul,

thnx for your answer.

This would be suitable for upstream data, but wouldn't it be easier just to rate limit data traffic to say 7,8Mbit/s. This way you have the same at the end (2.2MBit/s voice) but rate-limiting can be done on both upstream and downstream.

Please let me know what you think of this

regards

erik

[paul driver]

Hello,

You have no control to police traffic incoming from  the WAN link  as it would have already traversed the link before it hits your policy,  unless you want to police traffic going inside to your lan?

Shaping(queueing of packets) is always performed outbound and policing(droping of packets) is usually only done on inbound interfaces ( ie traffic coimmg in on you lan going through the router )

Note: Shaping always performs FIFO queuing unless this is specified (fair queue)

hope this helps

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Erik Dekkers]

Hi Paul,

You're right about that. What I said in the reply to JosephDoherty I'm going to shape the outbound traffic and see if that will help

thank you for your reply!

regards,

Erik

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

So only queuing would not be a good practice IMHO. I was thinking on just rate-limit or police data-traffic so Voice always has bandwidth available when needed. I've did tried to rate-limit on the ATM0 interface, but no luck. Voice was still very bad.

This asymmetrical DSL?  If so, as upstream is often much less than downstream, often worthwhile to shape and prioritize the upstream (egress).

As for ingress, yes that's problematic.  You can indeed police non-VoIP trying to leave bandwidth for VoIP.  Several problems though, such as congestion can still form before the policer and not all traffic responds to drops (although TCP should).  I've found policing can be effective slowing inbound TCP, but you need to police much slower than you might think (because it takes time for the sender to detect the packet lost and reduce its transmission window).  Another technique I've tried is shaping the outbound ACKs, but as you don't know the inbound rate and the ACKs can be piggybacked, its not very exact.

A traffic shaping appliance do better with inbound traffic and it can monitor inbound flow rates and also shape ACKs and/or spoof the RWIN, but besides the expense, they still will have difficulty with traffic that doesn't vary its transmission rate when drops are detected.

[Erik Dekkers]

Hi JosephDoherty,

The WAN link is a regular asymmetrical DSL link with no fancy traffic classes. The downstream:upstream ratio is 10:1.

I think I'm going to shape the egress data and leave the ingress data alone right now.

Shaping ACK's would not help much since I would like to prioritize SIP/RTP data.

Anyway, thank you for your helpful information. I will report back when I've managed to shape the data.

regards,

Erik

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

The WAN link is a regular asymmetrical DSL link with no fancy traffic classes. The downstream:upstream ratio is 10:1.
I think I'm going to shape the egress data and leave the ingress data alone right now.

Yup, good place to start.

Shaping ACK's would not help much since I would like to prioritize SIP/RTP data.

Shaping ACKs serves much the same purpose as policing other than VoIP traffic.  It's to slow other traffic leaving bandwidth for VoIP.  In theory, there's a couple advantages of shaping ACKs such as it can better "smooth" inbound traffic rate and it avoids dropping packets already received.  Some of the newer TCP implementation monitor RTT, so slowed ACKs might also have them reduce their send window.  In practice, the trouble of shaping ACKs, on a ordinary network device, is lack of precision.