Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Traffic-shaping for delay sensitive traffic

Hello, I would like to verify the use of a traffic-shaping policy within an MQC. I was told that you need to apply a shaping policy in order for QoS to always be engaged and not simply during times of congestion. This apparently is critical when you have apps like VoIP. 

On a similar note, i remember reading up on Ciscopress that you might NOT want to subject VoIP to any form of Shaping as this introdues delay and can cause Jitter.

Below is a sample config. If you can post an authoritative source on CCO that explains this I would greatly appreciate it.

Regards,

-Mike

policy-map QoS-Policy

 class realtime

  priority 512

    police 512000 conform-action transmit  exceed-action drop

 class preferred

  bandwidth remaining percent 40

  random-detect dscp-based

 class missioncritical

  bandwidth remaining percent 39

  random-detect dscp-based

 class trans-apps

  bandwidth remaining percent 16

  random-detect dscp-based

 class general

  bandwidth remaining percent 1

  random-detect dscp-based

 class class-default

  bandwidth remaining percent 4

  random-detect dscp-based

policy-map shape-20MB

 class class-default

  shape average 2000000

  service-policy QoS-Policy

!

interface Serial0/0/0

 service-policy output shape-20MB

2 ACCEPTED SOLUTIONS

Accepted Solutions
Super Bronze

DisclaimerThe Author of this

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

I was told that you need to apply a shaping policy in order for QoS to always be engaged and not simply during times of congestion.

 

Nope.

 

You only need to shape when you're dealing with a path where you know the end-to-end bandwidth is less the the egress interface's physical bandwidth and where you cannot manage congestion further downstream along the end-to-end path.

 

On a similar note, i remember reading up on Ciscopress that you might NOT want to subject VoIP to any form of Shaping as this introdues delay and can cause Jitter.

 

Semi-true.

 

The problem can be mitigated by decreasing the shaper's Tc.  Also, if shaper doesn't account for L2 overhead (and I believe many do not), you'll need to shape "slower" than the nominal bandwidth.  The major problem with the latter, L2 overhead varies, as a percentage, based on packet size.  So, you can either allow for worst case, which will best guarantee VoIP service, but tends to give up much of the available bandwidth, or you can shape for average case, which will make VoIP latency and jitter more variable but usually not so much to exceed its service requirements.

 

You can also bypass shaping for some traffic, but then you need to shape all your other traffic even slower to guarantee the non-shaped traffic bandwidth is always available.  As you're effectively reserving this bandwidth, it then becomes unavailable for your other traffic even when unused.

 

An example of the latter:

policy-map QoS-Policy

 class preferred

  bandwidth remaining percent 40

  random-detect dscp-based

 class missioncritical

  bandwidth remaining percent 39

  random-detect dscp-based

 class trans-apps

  bandwidth remaining percent 16

  random-detect dscp-based

 class general

  bandwidth remaining percent 1

  random-detect dscp-based

 class class-default

  bandwidth remaining percent 4

  random-detect dscp-based

 

policy-map shape-20MB

 class realtime

  priority 512

    police 512000 conform-action transmit  exceed-action drop

 class class-default

  shape average 1950000

  service-policy QoS-Policy

!

interface Serial0/0/0

 service-policy output shape-20MB

 

NB: BTW, the above doesn't account for L2 overhead, and I wouldn't recommend it for other reasons, but it should show how you can bypass the shaper.

Super Bronze

DisclaimerThe Author of this

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

Yes, and usually somewhere in the range 10 to 15% less does the trick.  For example, for your 20 Mbps, you might try shaping at 17 to 18 Mbps.

4 REPLIES
Super Bronze

DisclaimerThe Author of this

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

I was told that you need to apply a shaping policy in order for QoS to always be engaged and not simply during times of congestion.

 

Nope.

 

You only need to shape when you're dealing with a path where you know the end-to-end bandwidth is less the the egress interface's physical bandwidth and where you cannot manage congestion further downstream along the end-to-end path.

 

On a similar note, i remember reading up on Ciscopress that you might NOT want to subject VoIP to any form of Shaping as this introdues delay and can cause Jitter.

 

Semi-true.

 

The problem can be mitigated by decreasing the shaper's Tc.  Also, if shaper doesn't account for L2 overhead (and I believe many do not), you'll need to shape "slower" than the nominal bandwidth.  The major problem with the latter, L2 overhead varies, as a percentage, based on packet size.  So, you can either allow for worst case, which will best guarantee VoIP service, but tends to give up much of the available bandwidth, or you can shape for average case, which will make VoIP latency and jitter more variable but usually not so much to exceed its service requirements.

 

You can also bypass shaping for some traffic, but then you need to shape all your other traffic even slower to guarantee the non-shaped traffic bandwidth is always available.  As you're effectively reserving this bandwidth, it then becomes unavailable for your other traffic even when unused.

 

An example of the latter:

policy-map QoS-Policy

 class preferred

  bandwidth remaining percent 40

  random-detect dscp-based

 class missioncritical

  bandwidth remaining percent 39

  random-detect dscp-based

 class trans-apps

  bandwidth remaining percent 16

  random-detect dscp-based

 class general

  bandwidth remaining percent 1

  random-detect dscp-based

 class class-default

  bandwidth remaining percent 4

  random-detect dscp-based

 

policy-map shape-20MB

 class realtime

  priority 512

    police 512000 conform-action transmit  exceed-action drop

 class class-default

  shape average 1950000

  service-policy QoS-Policy

!

interface Serial0/0/0

 service-policy output shape-20MB

 

NB: BTW, the above doesn't account for L2 overhead, and I wouldn't recommend it for other reasons, but it should show how you can bypass the shaper.

New Member

Hi Joseph,Thanks for the

Hi Joseph,

Thanks for the great explanation/clarification. Is it the value of the "shape average" that needs to be changed to "account for L2 overhead"?

Regards,

Mike

Super Bronze

DisclaimerThe Author of this

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

Yes, and usually somewhere in the range 10 to 15% less does the trick.  For example, for your 20 Mbps, you might try shaping at 17 to 18 Mbps.

New Member

Thanks again, and best

Thanks again, and best regards!

Mike

119
Views
0
Helpful
4
Replies