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 might be able to, but it's often not well documented and often you need to look at multiple sources.
For example, many years ago, in my early experience using QoS, I had a policy that just didn't seem to be as effective as I expected it to be. I then stumbled across a Cisco white paper explaining a problem case where VoIP wasn't getting the expected performance across an ATM interface. Well, I wasn't using ATM in that instance, but the issue was, physical ports (BTW, not just ATM ports) maintain their own FIFO buffers, and those "overflow" into your QoS policy queues. So, often default interface FIFO buffers negate what you're trying to do to insure service to critical traffic. (NB: the "fix" is to configure smaller interface FIFO buffers using the tx-ring-limit command.)
So, again, you often need to do a lot of "digging", and even then, sometimes Cisco's documentation doesn't go deep into how things actually work, or, sometimes, isn't always correct.
That said, a good source for internal details is often Networkers presentations and/or other web sites where someone has analyzed how a Cisco feature appears to work.
What I would suggest, try it both ways and see how it works for you.
