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
"Solving" drops can be quite complex. Sometimes "solving" doesn't totally eliminate drops, but "solving" often does minimize the number of drops.
Drops can be used for TCP flow control. When used in this role, the idea is to drop the minimum number of packets to have the flow's source send at about the available bandwidth.
Increasing queue depth often, but not always, will mitigate drops but it also can increase latency. I.e. "solving" drops might warrant decreasing queue depth, although not often done on Cisco devices since their default queue depth usually isn't too large.
For TCP, optimal queue size should support BDP (the bandwidth delay product). Too small a queue leads to premature drops, too large a queue leads to needless queuing latency.
