Prioritization within QoS queue possible?

Answered Question
May 13th, 2009

Our company runs QoS over an MPLS WAN, but I am personally new to the technology. Given that our provider only allows four queues (EF, AF31, AF21, and BE), we have configured four corresponding policies. This seems somewhat limiting, given the number of queues Cisco actually supports. Here's the question; Is it possible to further prioritize traffic within a given queue?

Say for example, we want to place a certain traffic type within AF31, but we do not want to adversely impact other traffic within the queue. By the same token, we do not want to move either of these traffic types to EF. Can we control, in a more granular manner, prioritization within a respective queue? Any clarification you can provide would be greatly appreciated.

I have this problem too.
0 votes
Correct Answer by Joseph W. Doherty about 7 years 7 months ago

As Laurent also describes, it's usually possible to fully manage congestion to MPLS (generally easy if you control the CE router). With MPLS, though, where the limitations of the provider's QoS model are most troublesome is upon MPLS cloud egress. It's possible to indirectly control this if you logically manage your MPLS cloud as you might with frame-relay or ATM. Unfortuanately, this is often impractical if you have more than a few nodes and have a logical mesh topology vs. hub and spoke.

PS:

Some MPLS providers allow you to select from various "profiles" of QoS model choices. This can be very helpful if traffic ratios vary between sites. Also, some MPLS vendor QoS models also provide support for different drop thresholds within some classes.

Correct Answer by Laurent Aubert about 7 years 7 months ago

Hi,

Unfortunately, inside a class, it's the war between the different flows.

What you could do is to have a cascaded router behind the one connected to your SP link:

LAN--ROUTER-A---ROUTER-B--SP Cloud

On Router-A interface facing router B, you can do what you want in term of QoS. The only requirement is that congestion happens on this interface before it happens on Router B WAN interface so the way the traffic is prioritized on router A will not be changed by router B even if router B has less Class Of Service than Router A.

This implementation works only for the outgoing traffic. You still rely on the 4x classes of your SP for the receiving traffic.

HTH

Laurent.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Laurent Aubert Wed, 05/13/2009 - 18:07

Hi,

Unfortunately, inside a class, it's the war between the different flows.

What you could do is to have a cascaded router behind the one connected to your SP link:

LAN--ROUTER-A---ROUTER-B--SP Cloud

On Router-A interface facing router B, you can do what you want in term of QoS. The only requirement is that congestion happens on this interface before it happens on Router B WAN interface so the way the traffic is prioritized on router A will not be changed by router B even if router B has less Class Of Service than Router A.

This implementation works only for the outgoing traffic. You still rely on the 4x classes of your SP for the receiving traffic.

HTH

Laurent.

Correct Answer
Joseph W. Doherty Thu, 05/14/2009 - 03:09

As Laurent also describes, it's usually possible to fully manage congestion to MPLS (generally easy if you control the CE router). With MPLS, though, where the limitations of the provider's QoS model are most troublesome is upon MPLS cloud egress. It's possible to indirectly control this if you logically manage your MPLS cloud as you might with frame-relay or ATM. Unfortuanately, this is often impractical if you have more than a few nodes and have a logical mesh topology vs. hub and spoke.

PS:

Some MPLS providers allow you to select from various "profiles" of QoS model choices. This can be very helpful if traffic ratios vary between sites. Also, some MPLS vendor QoS models also provide support for different drop thresholds within some classes.

Actions

This Discussion