QoS - Bandwidth Guaranteed?

[gregh]

Hopefully simple question but can't seem to find definitive answer in docs.

Based on the following QoS Map, during times of congestion, will RTP (ef tagged) packets be "guaranteed" the specified percent of available bandwidth under any and all conditions?

qos map VOIP 10

match dscp ef

priority percent 50

qos map CONTROL 20

match dscp 26

bandwidth  percent 10

Follow-on question, will all other packets have equal access to the remaining 40% of available BW or is it possible that RTP traffic could starve out the other packets if RTP attempts to send more than the 50% allocated in the first QoS statement?

[jayh]

gregh wrote:

Hopefully simple question but can't seem to find definitive answer in docs.

Based on the following QoS Map, during times of congestion, will RTP (ef tagged) packets be "guaranteed" the specified percent of available bandwidth under any and all conditions?

qos map VOIP 10

match dscp ef

priority percent 50

This statement will match DSCP EF and place all EF-tagged packets in the priority queue until the point where EF-tagged packets consume 50% of the available bandwidth.  If EF-tagged traffic exceeds 50% of bandwidth, tagged traffic in excess of 50% will be placed in the default queue and handled by the default queueing mechanism.

qos map CONTROL 20

match dscp 26

bandwidth  percent 10

Follow-on question, will all other packets have equal access to the remaining 40% of available BW or is it possible that RTP traffic could starve out the other packets if RTP attempts to send more than the 50% allocated in the first QoS statement?

Your control traffic will reserve 10% of bandwidth. 

By default, you can only reserve a total of 75% of interface bandwidth with QoS, so 25% is left for other traffic.  You can override this if you really need to.

Gory details here:

https://supportforums.adtran.com/servlet/JiveServlet/previewBody/1649-102-2-1706/Configuring%20QoS%2...

[gregh]

Thank you jayh, excellent insight. I forgot to mention that I usually up the "max-reserved-bandwidth" to 90% but for the discussion "available" relates to any BW within the "max-reserved" allocation, default or otherwise.

The reason for the question is I've heard that without a third QoS statement allocating some % of the remaining bandwidth to "all other" packets, traffic could get "starved" out.

For example, (and my previous example was wrong, statement 20 should have also been named VOIP):

interface eth 0/1

max-reserved-bandwidth 90

qos map VOIP 10

match dscp ef

priority percent 50

qos map VOIP 20

match dscp 26

bandwidth percent 10

qos map VOIP 30

match any

bandwidth percent 30

Supposedly, without the last map statement, non-RTP packets might be dropped when RTP packets go above the 50% threshold defined in the first map statement.

[jayh · Accepted solution]

The "priority" map doesn't reserve bandwidth, it puts those packets first in queue.

If you have "priority percent 50" then your RTP will be put into the low-latency queue up to 50% of bandwidth.

If your RTP is greater than 50%, then the excess RTP will compete with all other traffic for the remainder, which could result in both RTP and/or non-marked traffic being queued, dropped, or both.

Your last statement of "match any" will of course match both EF-tagged as well as other traffic so would likely have little effect in the event that your RTP is >50% of bandwidth.  You would need to explicitly tag your data traffic DSCP 0 (or some other value) and match on that if you want to reserve bandwidth for it.

Of course, if you start dropping or queueing RTP due to lack of bandwidth, you're likely to get a phone call (that you can't understand ) from the customer, and a chance to upsell them. 

[gregh]

Thanks, just reading the QoS doc that you linked and I see where CBWFQ would be used which could lead to RTP traffic contending for the left-over BW and still having higher priority resulting in starvation of other packets.

I understand that the "priority" command does not reserve bandwidth but it should guarantee that RTP traffic received it's 50% of BW during times of congestion, if needed.

Good point on re: the "match any", makes perfect sense.

[gregh]

jayh,

I have to amend my previous statement regarding the "match any"; not sure it makes perfect sense the more I think about it.

So if my ef traffic goes over its' alloted BW based on the first statement, are you suggesting that it flow's through to the "match any" statement at the end of the QoS map?

Or, as you indicated previously, wouldn't the ef overrun traffic be dropped into the default queue, bypassing the rest of the qos map?

"If EF-tagged traffic exceeds 50% of bandwidth, tagged traffic in excess of 50% will be placed in the default queue and handled by the default queueing mechanism."

Got me thinking now. : )

[gregh]

Found some interesting information that appears to contradict what you said about excess traffic being placed into the default queue.

From the Adtran QoS configuration guide (61200860L1-29.3H, April 2012):

"When congestion is present, policies defined with the bandwidth command will be limited to the minimum value specified while excess traffic is queued.

During a congested state, policies defined with the priority command will be limited to the maximum value specified while excess traffic is

dropped."

So, if I'm comprehending the docs correctly, it would appear that ef traffic above 50% in my example would be dropped altogether.

qos map VOIP 10

match dscp ef

priority percent 50

qos map VOIP 20

match dscp 26

bandwidth percent 10

qos map VOIP 30

match any

bandwidth percent 30