QOS: Bandwidth vs Priority

mzinz

So this is something I've had trouble grasping for a while now.

It seems like bandwidth and priority are similar, but I've only seen one difference:
Priority percent 20 - This would mean that 20% of the pipe is reserved (when saturated), but any traffic above 20% will be queued or dropped.
Bandwidth percent 20 - This would mean that 20% of the pipe is reserved (when saturated), but additional traffic above 20% still can be prioritized.

I don't get it. Obviously I'm missing something.

networker050184

The part you are missing is that the priority queue is emptied first.

mzinz

networker050184 wrote: »

The part you are missing is that the priority queue is emptied first.

Gotcha. So priority queue is emptied before bandwidth queue.

Thanks for clearing that up.

creamy_stew

mzinz wrote: »

So this is something I've had trouble grasping for a while now.

It seems like bandwidth and priority are similar, but I've only seen one difference:
Priority percent 20 - This would mean that 20% of the pipe is reserved (when saturated), but any traffic above 20% will be queued or dropped.
Bandwidth percent 20 - This would mean that 20% of the pipe is reserved (when saturated), but additional traffic above 20% still can be prioritized.

I don't get it. Obviously I'm missing something.

As I understand it, Traffic that matches the priority queue can _only_ use the priority queue. I.e. let's say you have a voice vlan and you put all traffic from that vlan into "priority percent 20". The voice vlan would _never_ exceed 20 percent usage across the interface where the policy-map is applied. OTOH, it would always be forwarded first to ensure low latency.

networker050184

creamy_stew wrote: »

The voice vlan would _never_ exceed 20 percent usage across the interface where the policy-map is applied.

If the link is not congested the traffic from the priority class will still be transmitted even if exceeding 20%. The drop action only takes affect during times of congestion. Only traffic that conforms to the built in policer is garunteed priority though.

creamy_stew

networker050184 wrote: »

If the link is not congested the traffic from the priority class will still be transmitted even if exceeding 20%. The drop action only takes affect during times of congestion. Only traffic that conforms to the built in policer is garunteed priority though.

Hah, too bad cisco cancelled ONT while I was studying for it . Hopefully, I would've caught this in the Exam Guide for ONT (which I've paid for, grrr....)

edit: studying FOR

kurfer

A priority queue is also strict in the fact that you are not allowed to use more bandwidth than allowed in the queue.

They are used to often protect voice from starving data.

Bandwidth queue's allow more bandwidth if it's available.

creamy_stew

kurfer wrote: »

A priority queue is also strict in the fact that you are not allowed to use more bandwidth than allowed in the queue.

They are used to often protect voice from starving data.

Bandwidth queue's allow more bandwidth if it's available.

You seem to confirm how I thought it worked.

Am I misunderstanding something?

networker050184

creamy_stew wrote: »

You seem to confirm how I thought it worked.

Am I misunderstanding something?

The priority queue will only hold the amount of traffic configured, but the traffic is not dropped unless there is congestion. If there is no congestion it is still forwarded but not given priority.

So, you are not entirely correct in saying that the class will never exceed the 20% (or what ever is configured). See the link below. Specifically this portion.

"During congestion conditions, the traffic class is guaranteed bandwidth equal to the specified rate. (Recall that bandwidth guarantees are only an issue when an interface is congested.) In other words, the priority command provides a minimum bandwidth guarantee. In addition, the priority command implements a maximum bandwidth guarantee. Internally, the priority queue uses a token bucket that measures the offered load and ensures that the traffic stream conforms to the configured rate. Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested."

Comparing the bandwidth and priority Commands of a QoS Service Policy [QoS Packet Marking] - Cisco Systems

creamy_stew

OK, I still don't get it, but now I'm blaming the beer.

chmorin

My understanding of it, though I have not touched the material since I took the test, but the priority command will create a max and min amount of bandwidth that can be consumed, but it will also forward the data before all other queues are considered.

Sort of like having a queue 4/5 of a mile long for a ride, and another queue 1/5 mile long for 'speed line'. The 'speed line' will get onto the ride first, and emptied first, before the 4/5 mile queue is allowed on the ride.

This graph in the above link is a good sum up:

Function | bandwidth Command | priority Command

Minimum bandwidth guarantee | Yes | Yes

Maximum bandwidth guarantee | No | Yes

Built-in policer | No | Yes

Provides low latency | No | Yes

networker050184

I think it would be beneficial for you to learn about traffic policing and token buckets. It may help you understand the processing behind the priority queue.