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
Trying to avoid all packet drops can be counter productive. For example, as Paolo has already (correctly) noted, TCP uses drops as a flow control mechanism. Even if very large queue depths avoid any drops, it can create very highly variable (and perhaps high) latency. Consider with your queue depth set to 32,768 packets, the last packet in the queue has to wait for transmission of the 32,767 packets ahead of it.
Generally, to allow for maximum TCP transmission rate, your queue depth should not need to be larger than about half the BDP (bandwidth delay product) to reach the furthest TCP destination.
If you're using HQF QoS, I would suggest enabling fair-queue in your CRITICAL_APP class. I would also suggest, explicity defining the class-default class in your child policy and also enabling fair-queue in it too.
Fair queuing's two major advantages are: low volume flows will likely be less impacted by high volume flows; both regarding latency and packet dropping. In fact, packet dropping tends to only hit the high volume flows, i.e. the flow(s) causing the congestion, and the flow(s) we want to "signal" to slow its/their transmission rate.
