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've read two conflicting statements, one that shows the above config, and one that says that the larger the queue-limit, the smaller the queue-bandwidth. What is the relationship between queue-limit and bandwidth.
They're not conflicting as much as they have different objectives.
One approach is, if traffic is such low importance it gets little guaranteed bandwidth, then it also is of such low importance it can be dropped. So, little bandwidth, little queuing.
The other approach is, if traffic is given little bandwidth guarantee, it's more likely to queue and queue deeper, so you need to increase such traffic's queue limit.
One approach then is to size queue limits in proportion to bandwidth guarantees the the other to size queue limits in inverse proportion to bandwidth guarantees.
Which to use depends on how you want to manage likely drops and what that means to the application, for instance, if bulk file transfer transfer we might want to drop as the application will both resend the lost packet(s) and slow its send rate. If the traffic was video, we want to avoid drops especially if some delay is tolerable (e.g. streaming video).
A second question has to do with how the queues are serviced. Consider the following config lines as presented in the Telepresence design quide for the same example above:wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100
wrr-queue random-detect min-threshold 2 80 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100
With the above lines, during congestion, what distinguishes Q1 from Q2 so that packets in Q1 are dropped before packets in Q2 since the min and max values are the same?
You need to consider bandwidth ratios for the queues too. If bandwidth ratios were the same, then they would be treated the same (with above). If bandwidth ratios were different, queue with lower bandwidth guarantee (everything else being equal) will queue first and queue deeper and hence its packets are more likely to be dropped (with the above).
