cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1485
Views
3
Helpful
5
Replies

QoS - Policing ISG

Sirajhussain
Level 1
Level 1
5 Replies 5

shehinpm1
Level 1
Level 1

Hi siraj,

how the policy was configured earlier.when u experience slow connection.and u can edit the policy for upload speed also.

Yes Shehin,

I know that and re configured the policy where upload is fine so i am not doing any change for input policy. only I changed for output policy. My question here is it was very well working with the policy i mentioned above, i do not understand the reason of the slow speed issue.. The issue is fixed with below change but I need to find out the root cause. There is no change in network or any major configuration only customers are increasing day by day.

policy-map type service INTERNET

class type traffic TC_INTERNET

  police input 5120000 100000 100000

  police output 5120000 512000 512000

Thanks for your reply

Regards,

Siraj

Joseph W. Doherty
Hall of Fame
Hall of Fame

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

Changing the Bc parameter can have a major impact on TCP traffic performance.

Realize TCP bandwidth usage, when you "see" it running at some throughput bandwidth usage, is a measure of its average usage.  TCP, during slow start or congestion avoidance, sends blocks of packets at the host sender's full bandwidth capability, and then pauses its transmission until those packets are ACKed.  This is why TCP is often "bursty".

Policing measures bandwidth usage over some time interval.  If the measured time interval it too small, tail end packets of a TCP burst will be dropped.  If the measured interval is increased, the burst can be passed.

Since TCP will decrease the number of packets it sends when drops or detected, premature dropping of TCP packets will very much slow TCP effective transmission rate.

In other words, a policier being used against TCP traffic with a too small Bc will often cause TCP to run much slower than the policed CIR rate.

Setting Bc too large can actually be adverse to TCP too, as TCP will "think" there much more bandwidth available than allowed, and when it transmits a large block, much of the large block can be dropped perhaps forcing TCP into slow start.

Somewhere on Cisco's web site, they do recommend Bc and Be values, which I recall (?) are 1.5 and 2x CIR, but a more optimal setting might need to consider the end-to-end BDP (bandwidth delay product).

Even if a policer's Bc is "too" large, the only adverse effect should be "over" utilization during the Bc (and Be) interval, long term bandwidth utilization should still be constrained.

You've described that before you increased Bc everything was working fine, but I suspect it was more that no one had, until recently, noticed TCP traffic was unable to fully utilize the allocated CIR.

Getting a policer to be really optimal is complex.  If available, I generally recommend using a shaper rather than a policer since it more closely mimics an interface buffering packets.  The disadvantage of a shaper is by buffering it can introduce additional latency that a policer will not, but this can be managed by QoS, which too can be complex unless something such as FQ is available and meets the performance needs of all your traffic.

PS:

I didn't address the difference between average policing versus  peak policing.  The former only uses Bc the latter uses Bc and Be.  By  using Be, you can police your CIR more accurately for average  consumption while still allowing transient bursts.

This reference (one of many like it) shows policing and shaping impact to traffic: http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/Medianet_Ref_Gd/chap4.html#wp60957

Hi Joseph,

Thanks for the brief explanation of Policing parameters which i understood properly.

So according to you increase in burst size is the correct solution and you also recommends to use shaping in place of policing. One thing I want to add here, I come to know that ISP (outside my network) has put filter on  firewall to block certain websites (country policy). Isn't this cause of dropping more TCP packets and Internet speed affected?

I would like to thank you once again for your help and time.

Regards,

Siraj

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

Can't say with 100% guarantee that increasing the burst size is the correct solution without analysis of your particular case although the fact that performance was improved likely indicates original Bc was too small.

As to my recommendation for using shaping, suggested it since it generally isn't as adverse to traffic performance while still controlling bandwidth consumption; often adds latency, though.

Regarding an ISP firewall impacting performance, it might, but usually not too likely.  Anything it drops should be an all or nothing situation.  Most firewalls, unless overloaded for their capacity capabilities add minimal latency; total bandwidth rarely affected.

Review Cisco Networking for a $25 gift card