cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2000
Views
0
Helpful
17
Replies

QoS Output Queues Threshold above 100%

nocteam465
Beginner
Beginner

Hi,

First of all I have to say that I am not a native english speaker. Apologize errors of any kind.

On a 3750X, I am allowed on an output queue to set the value of Threshold#1 and Threshold#2 above 100% (up to 3200%).

From all my readings I understood that the thresholds applies on the allocated buffers  (the value returned in the "buffers" line of the example below) , not the "reserved" or "maximum" buffers.

Am I wrong here ?

Knowing that there is an implicite threshold 3 unalterably set to 100% what can be the reason to allow a threshold value above 100% ?

In the below example, the queue #1 drops every coming packet as soon as this queue is full, i.i. assoon it "consumes" 10 buffers. ( Threshold3 is 100)

Light welcome.

JM


mgth03#sho mls qos queue-set 2

Queueset: 2

Queue     :       1       2       3       4

----------------------------------------------

buffers   :     10     10     26     54

threshold1:   1111     200     100     20

threshold2:   2222     200     100     50

reserved :     98     50     50     67

maximum   :   3000     400     400     400

17 Replies 17

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Laugh - although for the last couple of years I've been working as a "wage slave", for several decades before I had worked "free lance" (perhaps as an "expensive consultant" ) who on the network front pushed QoS.

In my last consulting gig, the client's senior WAN engineer didn't believe in QoS mumble jumble until one night a 7500 reloaded itself and dropped all its QoS settings.  Next morning, the engineer noted his phone was lit like an XMAS tree with everyone complaining what's wrong with the network.  He "found" the reload, discovered the missing QoS statements, reconfigured the device with QoS, and his phone stopped ringing!  He then told me, why this QoS stuff really does something.  (laugh)

That particular client was a large international.  Interestingly, it was noted the other two regions kept buying additional WAN bandwidth, yet users kept complaining about network performance.  Our region had very little bandwidth growth, and little user network performance complaints (well after our region implemented QoS ).

BTW just being an "expensive consultant" doesn't mean you really know what you're talking about, although it does probably mean you wear nice threads.

On LANs, bandwidth upgrades can indeed be a less expensive solution.  On WANs, though, often QoS might be an less expensive solution.

On LANs, bandwidth, latency and buffer resources are such, if you need to implement QoS, it's likely more to deal with prioritization of packet drops rather than packet prioritization.  I.e. ". . .except that the VoIP physical ports were not configured with a "priority  queue out" statement, so not really fulfilling the requirements." might not really been needed, and PQ can starve all bandwidth from other queues."

Video can be very bandwidth bursty.  It also may not try to regulate its bandwidth usage.  If you're dealing with streaming (i.e. not RT) video, sufficient buffering usually is often all you need (NB: an issue with 3560/3750 series, they all seem a bit short on buffing resources).  If you're dealing with RT video, generally you need sufficient bandwidth so there's no or little need to buffer (NB: which might be up to about 4x the video's "average" bandwidth).

For your 3750X, optimal buffering is obtained by disabling QoS, but that also disables different QoS treatment for different traffic types.  If you (really) need different QoS treatment, you're very likely going to need to override QoS default settings.

On a 3750X, using the 2nd queue-set allows you to define different resource allocations.  So, for example, you might insure your video server's port really does allow whatever queue is being used for video to obtain about 100% of buffer resources.  Properly done, the reduction in drops might be dramatic.

Hi Joseph,

I hope I didn't hurt you, this was really not my intention.

I am sincerelly happy to have found someone of your level of expertise to talk about QoS. I mean I appreciate your "technical language" ( I am an engineer, and work for 30 years now in the IT) rather than just saying "you have to do it or you will get into trouble".

As you say - but only very few people say that, and even less understand it -

QoS is only a way of priorising packet losses. There is no negative meaning in that "only", it is a great think to be able to decide that in congestion cases I prefer loose packets from application A rather than from the business critical application B.

On the WAN we have packetshapers to insure QoS between our filliales ( I put packetshapers in services since 10 years, also on a worlwide network present in 220 countries)

On the LAN we have Cisco QoS for marking and classifying trafic: the DSCP is then used on the backbone by our provider to classify "Platinum", "Gold", "Silver" and "Bronze", our WAN traffic.

So you will understand that I am not "against" QoS, I just think that Cisco could make an effort to provide a better and consistent documentation.

I am a French, so very  ( too much ???) "cartesian", and over 50 years old, so from the old school, ...

My first computer was a Sinclair ZX80, a yellow hosepipe my first network... When I was young it was expected that in the 2000 years each of us will use a personnal rocket instead a car. So old fashionned...

Best regards

JM

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

I haven't been hurt, or offended, by anything you've written.

When I wrote about QoS is used to prioritize packet loss, that's true, but it can also be used to prioritize transmission. What I was trying to make clear the transmission prioritization usually becomes less important as bandwidth increases.  This because devices usually don't have buffers to create adverse latency (due to queuing) when you get gig and above.

How packets are prioritized and how they are actually dropped can be a crucial part of a QoS strategy; which is often overlooked.  Many assume no packet dropping is the best situation, but it can sometimes be detrimental in a couple of ways.

I've never used a PacketShaper, but I've studied what techniques they use.  I've even tried to "borrow" their technique of shaping TCP ACK packets (to "shape" ingress TCP).  Unfortunately, Cisco QoS feature aren't precise enough to really take full advantage of this approach.

Actually I've thought Cisco's QoS documentation is rather good although I've haven't always fully agreed with their recommendations.  One thing to note, they pretty much keep old and new documentation on-line, so it can be very confusing trying to sort out what they are recommending as QoS recommendations/thinking have changed over the years.  For example, you might still come across (old) documentation explaining the Olympic model (gold, silver, bronze) and the sometime (much newer) like MediaNet QoS.

One trap I've seen many fall into, is often when they read Cisco documentation they take bandwidth allocation percentages as cast in stone when all they are, are examples trying to convey the concept.

Years ago, a friend of mine owned a Sinclair (or its immediate descendent?), so I'm not unfamiliar with it.  My first microcomputer was a TRS-80, which I spend 1/3 of my annual income to purchase.  Back then, networks were "unusual" except for public dial-up timeshare and/or internal (non-IP) business terminal access (both RS-232 and none RS-232; sometimes coax but not Ethernet).

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers