QoS Concept Question

Answered Question
Apr 7th, 2007

Hi:

All Cisco QoS books and papers are focused on managing congstion over output queues (TxQ). There is few or no mention to INPUT queues. What is the reason? Is it so irrelevant?

Please consider this scenario: A hub-and-spoke network (central node "A") with 2 remote nodes ("B" and "C") connected to "A" through FR PVCs. "B" is only transmitting VoIP to "A" and "C" is only transmitting data. "A" receive both traffics in the same interface. If "C" is flooding with FTP traffic the INPUT queue in "A", What do I do to avoid that VoIP traffic coming from "B" be discarded in "A"? How do you manage congestion in "A" INPUT queue?

I have this problem too.
0 votes
Correct Answer by rseiler about 9 years 9 months ago

What I am talking about is called 'Hierarchical Qos policy' and is configured in a Cisco router using the MQC. Recent IOS versions use the MQC framework rather than the legacy frame-relay traffic-shaping, so be sure to research this correctly before you implement this.

Note also that a traffic-shaper differs from a traffic policer in that it actually shapes the traffic to a specific rate by slightly delaying traffic until the next interval rather than discarding traffic that exceeds the traffic rate like a policer. The difference between the two is staggering for VoIP, video, TCP throughput, response time for interactive applications such as telnet, ssh, tn3270, citrix, etc.

One problem with all the QoS information that is out there is that there are literally hundreds of commands available in Cisco IOS for various QoS features and hardware platforms and this makes it very difficult to figure out which tools to use for your specific network.

Feel free to send any questions that you have and I will do my best to answer them, including giving you some guidance in how to configure this properly. Done correctly, this is really not that complicated.

Here are a few URLs to get you started:

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_white_paper09186a0080123415.shtml

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bc6.html

http://www.cisco.com/en/US/products/ps6566/products_feature_guide09186a00805f3be9.html

http://www.cisco.com/en/US/products/ps6566/products_feature_guide09186a0080758dfb.html

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
rseiler Sun, 04/08/2007 - 16:18

First, once a packet arrives at an input interface, isn't the damage already done? What are you going to do with the packet once it has already arrived at your inbound interface. The only option is to put it into an inbound priority queue (only on specific hardware), forward it normally, or discard it (police).

Any packets that you discard on the inbound interface essentially reduces the inbound interface bandwidth so most designs to not do anything to the inbound interface other than ensure a priority queue exists on slow wan links (< T1) or oversubscribed/HOL blocking (head-of-line) linecards (any c4500 linecards and 61xx,63xx,64xx c6500 linecards).

QoS from a queueing perspective is only effective in the outbound direction. If you control both ends of the link (regardless of topology) then you can control inbound queueing issues with outbound queueing on the other end of the link.

In your example with a single head-end link supporting multiple spokes (remote sites), you have to design this carefully, particularly if there is a built-in oversubscription problem. For example, a single T1 at the head end with T1s at each of 4 remote sites in a hub-and-spoke configuration represents an oversubscription problem of 4 to 1. The potential instantaneous utilization on the head end could exceed the available bandwidth by 300%.

The way to solve this is traffic-shaping, and your example is a classic design that requires this tool. I refer to traffic-shaping as a 'layer-2' QoS tool since it solves an issue of oversubscription at the link layer, regardless of layer-3 protocol. Note that the service provider will resolve the oversubscription problem for you by randomly discarding frame-relay frames. This will essentially kill any hope of a successful VoIP implementation and will reduce the throughput of TCP applications and create huge variations of response time with interactive applications (telnet/ssh/citrix/etc).

Note that even if the remote sites have a relatively low utilization, particularly measured at 5 min intervals, you still will have many issues because of instantaneous periods of utilization in which both remote sites send packets at the exact same time. It is more of a statistical problem than a utilization problem.

Enter traffic-shaping. In your example, the best design is to shape the traffic leaving the central site to each remote at a rate equal to the the number of remote sites divided by the available central site bandwidth. In your case (with 2 remote sites) 50% or 1/2 a T1 (768K) to each remote site. You would do the same in the opposite direction; shape traffic leaving the remote site to 50% of the head-end bandwidth or 50% or 1/2 a T1 (768K) toward the central site (again, assuming 2 remote sites and a 2 to 1 oversubscription at the head end).

The architecture is that you apply an outbound QoS policy on top of the traffic-shaper which shapes traffic out the physical interface (or PVC) to a rate that does not oversubscribe the head end at all. Your voice is prioritized over data (or potentially multiple classes of data each with a minimum bandwidth guarantee) and is sent in the correct order at a rate that ensures the other remote site does not force the service provider or telco to discard traffic.

Now I know that you are saying to yourself 'yes, but I loose half the bandwidth to the remote sites', and that is true. Most users, however, would prefer reliable and consistent behavior with their applications, voice and video over a slightly higher throughput that is not reliable, consistent, or of any quality.

Correct Answer
rseiler Sun, 04/08/2007 - 16:20

What I am talking about is called 'Hierarchical Qos policy' and is configured in a Cisco router using the MQC. Recent IOS versions use the MQC framework rather than the legacy frame-relay traffic-shaping, so be sure to research this correctly before you implement this.

Note also that a traffic-shaper differs from a traffic policer in that it actually shapes the traffic to a specific rate by slightly delaying traffic until the next interval rather than discarding traffic that exceeds the traffic rate like a policer. The difference between the two is staggering for VoIP, video, TCP throughput, response time for interactive applications such as telnet, ssh, tn3270, citrix, etc.

One problem with all the QoS information that is out there is that there are literally hundreds of commands available in Cisco IOS for various QoS features and hardware platforms and this makes it very difficult to figure out which tools to use for your specific network.

Feel free to send any questions that you have and I will do my best to answer them, including giving you some guidance in how to configure this properly. Done correctly, this is really not that complicated.

Here are a few URLs to get you started:

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_white_paper09186a0080123415.shtml

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bc6.html

http://www.cisco.com/en/US/products/ps6566/products_feature_guide09186a00805f3be9.html

http://www.cisco.com/en/US/products/ps6566/products_feature_guide09186a0080758dfb.html

Actions

This Discussion