QoS Map Priority Queue

[gregh]

Been reading various documents regarding QoS maps and came across this in a PDF titled ADTRAN Configuring an efficient QoS Map:

"In a QoS map, there is one priority queue that will always forward traffic until it’s empty before

other queues are able to forward traffic."

Using the following example QoS map, is it possible to starve out other types of traffic if there is a consistent stream of EF-tagged traffic filling up the priority queue?

qos map TEST 10

  match dscp ef

  priority percent 25

qos map TEST 20

  match dscp cs2

  bandwidth percent 25

qos map TEST 30

  match dscp cs1

  bandwidth percent 25

Thanks in advance,

Greg

[jayh]

gregh wrote:

Been reading various documents regarding QoS maps and came across this in a PDF titled ADTRAN Configuring an efficient QoS Map:

"In a QoS map, there is one priority queue that will always forward traffic until it’s empty before

other queues are able to forward traffic."

Using the following example QoS map, is it possible to starve out other types of traffic if there is a consistent stream of EF-tagged traffic filling up the priority queue?

qos map TEST 10

  match dscp ef

  priority percent 25

qos map TEST 20

  match dscp cs2

  bandwidth percent 25

qos map TEST 30

  match dscp cs1

  bandwidth percent 25

If the bandwidth statement on the interface matches the actual outbound bandwidth, not as configured.

The priority percent 25 limits the priority queue to 25% of the bandwidth. 

Potential gotchas and things to consider: 

• Ethernet interfaces typically have less available bandwidth than the wire speed of 100 Mbits/s or 1 Gbit/s so you need to specify the actual bandwidth available.
• Without a limit specified, it is possible to starve other traffic.
• By default you can only reserve 75% of available bandwidth, the 25% remaining is available for unspecified traffic.
• It's far easier to control QoS leaving the device than entering it.

[gregh]

jayh,

Looks like you're the only one who responds to my discussions. You spend way too much time on the boards. : )

OK, so yes I agree regarding BW on the interface, need a "traffic shape-rate" command, etc.

But, I'm talking queues here based on the quote above.

The quote directly from the document says "...priority queue that will always forward traffic until it’s empty before other queues are able to forward traffic."

My interpretation is, that as long as the priority queue (which I'm assuming is a dedicted, independent queue) has packets waiting to get onto the wire, priority packets will always be transmitted first until the priority queue is empty.

Seems like a recipe for starvation of the packets in other queues IF there is a steady stream of priority traffic coming into the router.

[jayh]

gregh wrote:

jayh,

The quote directly from the document says "...priority queue that will always forward traffic until it’s empty before other queues are able to forward traffic."

My interpretation is, that as long as the priority queue (which I'm assuming is a dedicted, independent queue) has packets waiting to get onto the wire, priority packets will always be transmitted first until the priority queue is empty.

Seems like a recipe for starvation of the packets in other queues IF there is a steady stream of priority traffic coming into the router.

It may be semantics in the document, or the quote doesn't clarify that the queue will always forward traffic until it's empty but is only allowed to fill to the amount specified either as absolute bandwidth or a percentage of interface bandwidth.

[gregh]

I'm thinking the document is probably wrong but doesn't surprise me; I find quite a few contradictions across the Adtran docs.

Maybe I'm just being stubborn but the way it's written it doesn't matter how much the priority queue fills.

If there are packets in the priority queue they are serviced until the queue is empty and it would seem that there could be situations where a steady stream of priority traffic could starve out other traffic during times of congestion.

[gregh]

Let me add that it would probably be by poor design that would allow priority traffic to eat up all the BW.

[Anonymous]

Gregh,

Actually what you are referring to is correct - it was more the context is being lost. The document was assuming the user was aware that priority traffic is policed down to the amount which is alluded to several times before hand but not specifically stated. Once you understand that a priority queue is always policed and may never exceed the amount given to it via the QoS map, that statement is true - the priority queue will always have precedence until it is full i.e. it has reached it's allotted bandwidth.

We are consistently working to add and improve documentation as new features come out and our products change. If you find issues with documentation, as you refer to with "I find quite a few contradictions across the Adtran docs" , please feel free to comment on those documents and ask if that information is incorrect or needs to be updated, etc. Those comments are directly sent to our email in-boxes and we usually respond very quickly.

We recently have done a large document audit and are currently working on producing new supplemental documents as well as improving old documentation. However, we must rely on members to report any problems they find so we can be aware of any sections that are not clear from a user standpoint.  The document you pointed to is en-queued to be worked on shortly as we move documentation over to a newer user-friendly format. I will be sure to update it with clearer information regarding policing as well.

Hopefully together, we can make this forum the best it can be.

Thanks,

Evan

[gregh]

dj,

Thanks for the reply. I hope that I didn't offend with my statement about contradictory Adtran documentation. That statement could be used for any technical documentation and is why I ask for clarification on the boards. Sorry if the statement came across as accusatory, that was not my intention.

So, yes, I understand that the "priority" queue has a hard limit or is policed to whatever percent or bandwidth statement is configured in the QoS map.

If there is a steady stream of UDP voice traffic, and it reaches the limit imposed by the QoS priority statement, packets will be dropped at the same time that packets are being processed and sent out the egress interface.

But, if UDP VoIP traffic continues to ingress the router in a steady stream, could/would it be possible for the priority queue to always have more than zero packets?

Seems like this could be a possible state; under steady load, the priority queue is never completely empty.

I could be over-analyzing this and/or maybe the statement about forwarding traffic until the queue is empty is incorrect.

Also, your statement regarding the priority queue,

dj_flow-control wrote:

Gregh,

... Once you understand that a priority queue is always policed and may never exceed the amount given to it via the QoS map, that statement is true - the priority queue will always have precedence until it is full i.e. it has reached it's allotted bandwidth.

seems to suggest that once the priority queue is full it will no longer have precedence?

Speaking of confusing documentation, here is another one that I would love clarification on.

"Configuring QoS in AOS" document # 61200860L1-29.3H, page 17 NOTE box says:

"The max-reserved-bandwidth command is set from the interface configuration mode. By default, it is set to 75 percent, which reserves 25 percent of the interface bandwidth for system-critical and best effort traffic."

Is it true that system-critical AND best effort traffic share the portion of BW that is set aside from QoS policies?

Doesn't sound right but I am new to the Adtran world which is why I'm combing thru the docs.

Thank you

[gregh]

More clarification:

When I said, "Let me add that it would probably be by poor design that would allow priority traffic to eat up all the BW."

I meant poor design on my part in setting up a scenario whereby a non-stop stream of VoIP traffic would starve out other traffic.

I didn't mean poor design of the Adtran product.

Just goes to show, gotta be careful what you write. : O

[Anonymous]

Gregh,

Not a bit. A lot of documentation was written a long period of time ago. As you know, technology changes quicker than everything else. We periodically try to go through our documentation and as I had stated above we are going through it currently. Unfortunately, when people find problems in documents, or just places that need more clarification to a user, they don't always let us know about. Documentation is not for us (although we do use it ), it is for you. So we always want a customer's opinion to know how we can make it better. If it looks like a masterpiece to us, and the opposite to you, then it is not accomplishing its goal: to help our users use and learn how to use our equipment properly.

As far as the question - I definitely understand where you are coming from, and QoS is not simple beast in any sense of the imagination. First, I will clarify some more - in that document and the way I normally discuss QoS with our products, I relate a "queue" to a sequence in the map. So traffic is put into queues up until the bandwidth allocated. If the "queue" is full, i.e. it has reached the priority statement, traffic is dropped (or not inserted into the queue). In reality, underneath the structure of AOS, traffic is actually all put into queues and dropped form there. The queue-to-sequence analogy is one that makes it a little easier to understand from a "newer user" standpoint.

So looking at it that way, your question:

"But, if UDP VoIP traffic continues to ingress the router in a steady stream, could/would it be possible for the priority queue to always have more than zero packets?

Seems like this could be a possible state; under steady load, the priority queue is never completely empty."

This is a tough one to picture in your head, right? The main part of this is the interface itself and its bandwidth. If your bandwidth is 100mbps, you can actually transmit at that speed. So, as long as that steady stream of UDP packets is coming in fast enough that the queue is staying pretty full to the "naked eye", there will still be plenty of empty gaps because the router can process packets must faster than they are coming in. A voice stream normally includes an RTP packet every 20ms, but the router may be able to process normal packets at 100,000 packets per second which is a packet every 10 micro-seconds. So there will definitely be gaps for best effort traffic provided the priority traffic is policed down to its allotted rate. '

The other statement:

Also, your statement regarding the priority queue,

    dj_flow-control wrote:

    Gregh,

    ... Once you understand that a priority queue is always policed and may never exceed the amount given to it via the QoS map, that statement is true - the priority queue will always have precedence until it is full i.e. it has reached it's allotted bandwidth.

seems to suggest that once the priority queue is full it will no longer have precedence?

This is looking at the queues in the virtual representation. In that manner, traffic over the amount is policed and therefor is never a part of that "queue" or sequence. So not only will it not have precedence, it will be dropped.

As for the statement in , this statement is worded incorrectly (I will write that down as one of the changed we need to make to that document). The 25% should only include system critical traffic. Best Effort traffic is part of the 75%, but only gets the leftovers after the other sequences in the QoS map are serviced (which I am sure you understand that part of it). In reality, this is a very safe number and in most regards you can increase the max-reserved-bandwidth to 95% or so. I believe this is covered in a little more detail in .

You seem like a very knowledgeable member, so we will always forgive being new to the ADTRAN world (by the way, welcome!) as long as you stay with us . I would encourage you to continue participating and answering questions as I am sure there are other members who could benefit from your knowledge. As I said as well: do not hesitate to let us know when clarification is needed. We pay attention to every comment on every document and have a pure commitment to making our forum the best it can be and our documentation the best it can be. It would be nice to catch everything, but having knowledgeable customers to back us up is always a big plus .

If you have any other questions, feel free to let me know.

Thanks,

Evan

[gregh]

Thank you dj, excellent response.

I must admit that I struggle with the finer points of QoS.

Your explanation definitely clarifies the subject and I'll now try to move on to other topics; pretty much beat this one up.

I will definitely continue to participate on the boards, it's one of my primary resources for learning the ins and outs of the Adtran products.

[Anonymous]

Gregh,

I went ahead and flagged this post as "Assumed Answered".  If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  It appears that everything has been clarified, but if you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Thanks!

David