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
