JUNOS QoS/CoS: Relationship between minimum and maximum bandwidth

How often do you get asked, “Hey John, can we get like minimum 500 kbps speed on this line?”

And when you hear this, you scramble to find documentation regarding how to set minimum bandwidth. And this often leads to confusion for some network admins that just started. In fact, the concept of “minimum bandwidth” is trivial. There is a reason for this.

When people think about minimum bandwidth, they think of the “at least”/”guaranteed” bandwidth; and in terms of QoS/CoS in JUNOS, it is essentially the “maximum bandwidth” or the bandwidth-limit when configuring a policer. This is, if you are looking for aggressive QoS policies since using policer will place strict policies on traffics (dropping packets). You can also configure a more lenient policy using shaping but for the sake of ease to demonstrate and discuss this topic, we’ll strictly talk about bandwidth limits and not shaping.

It may sound totally counter-intuitive at first, but what maximum bandwidth means in JUNOS QoS is basically the bandwidth guaranteed or “allowed/allocated” to the certain CoS/Queues. When you specify the bandwidth-limit in JUNOS, the OS actually can give more bandwidth to the queue under certain condition even if you don’t explicitly configure anything else. Extra bandwidth may be allocated to a particular queue when other queue are NOT utilizing its bandwidth, this is a separate function from the burst-rate, or the burst-size-limit parameter. To turn this option off, you can use the parameter exact when configuring the transmission rates for each queue.

Now, why is the concept of minimum-bandwidth trivial? The simple answer is that, you never really know what you will be transmitting minimally at any time other than 0 which is not using any bandwidth at all. However, you DO know how much you can allow a certain queue to transmit, therefore, you set a maximum bandwidth allowed for that particular queue. If you have used any p2p client, you will probably have seen options to set maximum download/upload rate, but you probably see a minimum download/upload rate because you never know how fast your peers are for you to upload or how fast you can download at. You always set the maximum because that maximum number is the limit in which it will not impact your network.

With this in mind, it may have already become apparent that when deploying bandwidth limit policies, you should be dividing each queue so that the sum of each queue equals the total bandwidth allowed by your network or by your ISP. And that in effect, gives each queue a “guaranteed” (or “minimum”) bandwidth. And speaking of ISP, it is probably where the confusion arose from since residential ISPs rarely gives an accurate view of the bandwidth you are really “guaranteed” since the practice of over-subscription is so rampant in the residential high-speed market. And what the speed the ISP should be advertising should be the “minimum” bandwidth allocated to each user under the maximum load.

So, if you are deploying bandwidth policers for your WAN connection, you should consider doing several bandwidth tests throughout the day at different times and get a more accurate reading of your bandwidth. Some of this problem can be alleviated if you have some sort of SLA with your ISP that specifies your bandwidth.