QUEUES TO GUARANTEE BANDWIDTH

RouterOS Beginner Basics
1

Dear Gentle Folk,

I am relatively familiar with linux queues but have never fully understood the following.

I understand well how to create queues that limit the size of pipes going to end customers, but I don’t understand how to create a pipe that will guarantee bandwidth.

For example, I have two customers on a mikrotik and an incoming pipe feeding them of 7 megs say.

I want one customer to have 5 megs guaranteed, and the other customer to have whatever
is left over, both customers should be able to use up to the full pipe if the other one is not using it.

Is that even meaningful?

Thanks in advance,

2

Assuming that you have the appropriate packet marks in the mangle rules to identify download traffic:

/queue tree
add max-limit=6500k name="Download Gobal" parent=<LAN interface> queue=default
add max-limit=6500k name=Cus1_Download parent="Download Gobal" queue=default packet-mark=Cus1_Download priority=1 limit-at=5M
add max-limit=6500k name=Cus2_Download parent="Download Gobal" queue=default packet-mark=Cus2_Download priority=2 limit-at=1500k

1.) You need to artificially limit the available bandwidth at arround %90 of what is available so that queues will kick in appropriately and you are not subject to the ISP doing their own queueing and messing up what you want.
2.) Use a global queue as a container for the sub queues so that the router knows how to divy up bandwidth.
3.) The limit-at attribute defines the guaranteed amount of bandwidth available for a user with that given queue
4.) The max-limit defines the ammount of bandwidth that someone is able to recieve from a queue.
5.) The priority attribute defines who can reach the max-limit first if more bandwidth is requested, it’s a strait priority.
6.) The Mirotik can only control traffic sent from itself, it has no control over how traffic is recieved on a given interface.

3

The limit-at parameter has a misleading name in my opinion. This parameter is a guaranteed minimum bandwidth. All queues must be given their minimum bandwidth before any extra is permitted. If queue2 has no traffic, then queue1 will be able to go above the limit-at rate, but if queue2 requests bandwidth and queue1 is consuming more than their guarantee, it will be slowed down to the limit-at rate in order to give more bandwidth to queue2. If there just isn’t enough bandwidth to serve all guarantees, then the priority of each queue will determine who is given service first. (as good practice, you should never guarantee more bandwidth than you actually have available, and you should always guarantee a certain amount to the default queue)

4

Thank you both for your time and efforts.

Is there a white paper that describes queuing more clearly than the linux bandwidth control how to?

I am trying to convert what you have said into ‘linux think’.

I guess my basic problem is a confusion between.

1.) Guaranteeing they won’t get more than 5, i.e granting a limited pipe, and
2.) Guaranteeing they won’t get less than 5, i.e granting a guaranteed pipe or CIR.

CIR means committed information rate.

Normally if one has 100 megs and commits to 25 megs per customers, then you just
put 4 customers on the link and you are done. Each might get more than 25 megs, but
never less barring tcp connection hogging.

But sometimes you just want to make sure that a higher priority customers gets more than
the others when he needs it.

Imagine the following, an ftp server that has a 10 megabit port and can deliver 10 megs
connected to a router on eth0 and 2 customers on eth1, where eth0 and eth1 are 100 meg ports.

The queuing software runs on the router, not the server.

I believe I can create a queue that limits both customers to 7 megs max and that’s
it regardless of what bandwidth is still unused, without having to ‘grab’ the queues by
limiting the envelope queue to 90 percent of 10 megs.

Which customer gets the full 7 megs max would depend on priority, the higher priority one would get it,
and the lower one would get what’s left.

Is that right?

Is that all we are doing here? Or is there really a separate command to guarantee that one
won’t get less than 7?

GRABBING THE QUEUE

As I remember ‘grabbing the queue’ was only necessary when using particular queues like those designed to share bandwidth when the pipe was full.

For example, imagine the same setup above, and again there are two customers, but customer 2 likes
to open up 9 connections to the ftp server to get more bandwidth ahead of customer 1 who has no clue about this, he only opens up one connection.

With both customers drawing full bandwidth, the ftp server is putting out 10 megs, and nothing
is queuing in the router because eth0/eth1 at 100 megs each can handle it easily but customer one is getting 1 meg and customer 2 is getting 9.

So one creates a .90x10 or 9 meg max pipe on eth1 facing the customers which will begin queuing
packets before bandwidth usage gets to 10 megs. Then we apply a esfq algorithm, hashed by customer IP, that gives each customer
50 percent of the bandwidth regardless of how many connections they open up. esfq means extended stochastic fair queuing.

This scheme only works when the pipe is full, but is meaningless anyway if the pipe is not full as
everyone is getting what they are going to get anyhow limited by other factors outside of the control of the router.

Do I have this all right?

Or say the router’s customer port eth1 is a 10 meg port, and the ftp server can deliver 20 megs.
Now with both customers drawing, the 10 meg pipe is full, again one needs to define a queue at 9 megs on eth1 to make sure the queuing software grabs the packets and not the eth1 interface, and one applies the same esqf algorithm
to split the bandwidth fair share between the two customers.

I am almost positive this last one is right.

Homer W. Smith
CEO Lightlink.

5

What you are basically doing with creating the parent queue is setting a hard limit of how much bandwidth is available to all sub queues under it. This is so that the router knows who to divide the bandwidth up between all the children queues.

With the leaf/sub queues, you once again assign a max-limit to each, this will define how much bandwidth is allowed through that specific queue under any circumstances. Then you define a limit-at for each sub queue, this will define how much bandwidth is guaranteed to each child of the parent. Everyone must be allowed their minimum bandwidth before the priority kicks in.

The priority setting defines who gets the left over bandwidth, if any, first out of the pool. Once the one with the higher priority gets what they want out of the left overs, the next person in line gets what is left over, and so on down the line.

This article on the Wiki is what started me down the path to understanding queue’s in the MikroTik a lot better:
http://wiki.mikrotik.com/wiki/Manual:Connection_Rate

6

Yep
limit-at=xxxx is the CIR.
max-limit = the 7Mbps hard speed limit, regardless of any additional bandwidth being available.


guaranteed minimum available to a user = CIR = limit-at.

When servicing queues, ROS will make sure that all queues have been given their minimum bandwidth first. It services higher priority (lower priority number) queues first among queues which are below the guaranteed minimum.

Once all queues are at or above minimum, then the priorities are the tie-breaker for the available bandwidth. Any queue at max-limit is not going to get any more service, even if at higher priority.

If you want to give one user a CIR but not others, then you could classify traffic to the “platinum” customer with packet marks, make the rest of the packets get “default” marks. Then have two simple queues where the basic queue is unlimited but low priority, and the priority queue is limited max and given a CIR. That should give the behavior you want.