MPLS QoS Question

[boshardy1]

We are using AT&T and have 4 clases of service. In COS1 AT&T recommends using strict priority for voice. If I give it a priority of say 1mb, does that mean it will always get 1mb and never more (we have a 10mb pipe between sites), or can it spill over if bandwidth exists? Based on observation it almost seems to me that it just drops if it goes over the 1mb strict priority.

[Marwan ALshawi]

with priority queue u gona police the traffic to that amount of traffic because the proirity queue aslo contain a policer

so if u give the class priority 1mb it will be serviced first but at the same time policed to that 1mb

it is posiable to play with this default behivour but not recomended

while with the bandwith command u gonna resirv the designated bandwidth but if there is free bandwith in line it will go above that amount

please, if helpful rate

[shivlu jain]

actually what happens your voice traffic requires less jitter and delay thats why it is designed to travel with strict policy. After 1 mb the whole trafic will be dropped becasue no queues are formed in strcit priority. It means if delay in traffic simply drop the traffic means no compromise with the quality.

regards

shivlu

[n.nandrekar]

hi!

I would differ with the views stated here.

The Priority queue configuration can be either

defined using strict priority + police command. strict priority means you just specify "priority" under the class. since there is no upper limit, you also define a policer to restrict the priority traffic from starving other classes.

When you specify priority queue using "priority " or "priority percent <%> " in the class map, its a different case than the above combination. The traffic is still policed at the limit mentioned, but it is a congestion-aware policer. This means that it will police only when there is a congestion. Else it will let the traffic pass. (there is no sense in droping priority traffic when there is no congestion on the interface and there is bandwidth available to send the traffic.

For reference check :

http://www.cisco.com/en/US/netsol/ns341/ns396/ns172/ns103/networking_solutions_white_paper09186a00801b1c5a.shtml

search for "congestion-aware policer" under the "voice traffic" section.

Regards,

Niranjan

(Pls rate helpful posts)

[Marwan ALshawi]

Niranjan

i would say this time i missed it

although the concept i have mentioned above is right but need to be modified a bit

so what you have mentioned now i agree with it

and also the below pargrph from cisco press, End-to-End QoS Network Design, 2004

LLQ Policing

The threat posed by any strict priority-scheduling algorithm is that it could starve lower-priority traffic. To prevent this, the LLQ mechanism has a built-in policer. This policer (like the queuing algorithm itself) engages only when the interface is experiencing congestion.

now i hope my information helpful and more accurate.. and i am happy with this nice discussion

thank you all

Marwan

[n.nandrekar]

Its cool! Sometimes we goof up on some basic things. Happened to me just the other day with 1 question in BGP :)... its these discussions that keep on making us go back to the book and refresh :)

Cheers!

Niranjan

[Joseph W. Doherty]

As Niranjan's post notes, LLQ's implicit policier only activates when there's interface congestion. However, that's LLQ behavior, you'll also need to be aware whether the MPLS provider is using any explicit policiers or rate limiters. Those will enforce the class traffic limit regardless of other traffic bandwidth usage. Also, since MPLS often supports any-to-any, you need to think not only of your control of the outbound interface to the MPLS cloud, but what QoS policies the providers has for MPLS ingress, MPLS egress and within MPLS.

With AT&T (I believe), you can chose a QoS profile that reserves much of the bandwidth (80% of CDR?) for real-time. Since other classes using remaining percentages, you can go with a large percentage devoted to real-time, not use it, and have other classes behave as desired. However, if you reserve only a small ratio for real-time, you might bump into drops within real-time due to non-real-time traffic causing congestion when you rather have real-time push such traffic aside.