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
Thanks for the rating.
I wanted to expand a little about PQ usage and Cisco's 33% recommendation.
If I remember correctly, Cisco 33% recommendation is to allow bandwidth for the other traffic. Well that's true, but what they don't really clarify is that might, or might not, be important. What usually is important is meeting the performance needs of the traffic we're placing in PQ - i.e. there's some reason why we believe it needs to be there.
An easy method to think of sizing PQ bandwidth, is consider how the PQ traffic would behave having x amount of bandwidth. For instance, if we were supporting just voice using something like g711, which is constant bit rate, we could probably fill the link close to 100% (somewhat similar to what happens on an analog DS0). So, we could set PQ bandwidth to 99% and as long as total PQ consumption didn't exceed that, voice performance should be fine.
If instead of g711 we used g729, the voice traffic bandwidth consumption is variable across time. We know what the average consumption per call is, but we need to allow for the variable bandwidth consumption at any time by providing excess available bandwidth for peaks, this to avoid delaying packets during bursts. A rough rule of thumb might be to not use more than about 66% of the link for PQ for this kind of traffic.
Video is generally also variable bandwidth consumption, but besides using more bandwidth per flow, it tends to also be even more variable in its consumption. Real-time video, like voice, doesn't like being delayed. Because of the extra variability of typical video, we often need to allowing even more excess bandwidth for handling video bursts. Another rough rule of thumb might be not to use more than about 33% of the link for PQ for this kind of traffic.
Since PQ takes precedence over all other traffic, it doesn't really matter much to the PQ traffic whether the excess bandwidth is actually being used or not being used. What's important is whether sufficient bandwidth is available, or made available, to keep PQ traffic from not being delayed. This is also why you generally shouldn't see PQ traffic actually queued.
PS:
BTW, video streaming, although perhaps even using the same codec as real-time video, and having the same bandwidth consumption attributes, often has receiver buffering. For this kind of video, you don't generally need PQ nor the same amount of excess bandwidth because the receiver buffering usually allows queuing bursts. Generally you might find you only need to insure your video's average consumption is somewhere between 60 to 80% of total bandwidth. Streaming auto, generally with less bandwidth consumption variability, might be be pushed to 70 to 90%. (NB: unlike real-time excess bandwidth that's provided to avoid queuing packets, and delay caused by that, the excess bandwidth for non-real-time traffic is needed to "catch-up" or drain transient bursts that have been queued. Insufficient excess bandwidth for non-real-time traffic can create enough delay that receiver's buffer empties and/or multiple bursts exceed queue resources.)
