MikroTik

Thanks to your feedback in v6.0RC3 we will have some changes in QoS features.

We made simple queues completely independent from "Global" queue tree. Now simple queues will happen after "Global" queue tree:
So there is no more need to remember who will get traffic first - simple queues or queues in "Global" queue tree. Now traffic can be captured by both separately and independently. This also give you possibility to implement Double QoS again.

1) mark traffic by type in mangle, and apply limitations by traffic type in "Global" queue tree
2) use dynamic simple queues from ppp servers or RADIUS or create simple queues manually and use PCQ for limiting traffic per user, "target" and "dst" options should allow us to make per-user-limitation without any problems

Nice feature; good work.

one global (well, not about global queues, but about ideology ) question: do we still need queue tree at all?

in the light of kernel-level optimizations of Simple Queues and remembering Occam's razor to make queues more homogeneous, maybe it worths to transform Queue Tree to another set of Simple Queues (like Queues Step 1 and Step 2, or something)

currently simple queues are smart enough to install only necessary part of its subqueues (upload/download), so theoretically it won't affect performance. moreover, it will simplify understanding of queueing ("what should I use - queue tree or simple queues?") and you can use all delights of simple queues (like built-in Graphing, so you won't need some dedicated MRTG machine to draw some part of your queues unaffected by standard tools)

To Chupaka:

Well sounds like these are nice ideas for RouterOS v7.x and v8.x. Only thing that is not covered in your idea is Interface HTB, i can't see it completely implemented into simple queues. and Parent that doesn't need to capture all the traffic for children first is very nice queue tree feature.

I for one like this implementation, looks simple and should provide the same set of features. Just in different way.

Can anyone explain to me what's the meaning of the priority parameter in Simple Queues. I do understand what this parameters does when specified on the child queues in a Queue Tree, but that does not quite seem to apply to Simple Queues... Or does it? Any thoughts?

yep, probably it's too late to change Simple Queues for parent=interface in v6...

but changing queues behaviour in every version is not good also %)

the main idea is to generalize work with queues, making it similar for currently separated things, nothing more

for example, allowing parent=ether1 in Simple queues may just disable 'upload' and 'total' options instead of necessity of using extra term 'Queue tree'

and Parent that doesn't need to capture all the traffic for children first is very nice queue tree feature

maybe I don't know something about simple queues and their parents, but I thought it's the same as in queue tree, and ordering of simple queues was due to hidden mangle rules created by simple queues...

Can anyone explain to me what's the meaning of the priority parameter in Simple Queues. I do understand what this parameters does when specified on the child queues in a Queue Tree, but that does not quite seem to apply to Simple Queues... Or does it? Any thoughts?

as far as I (I hope) can (still) understand, Simple Queue with parent=none creates up to three hidden queues of queue tree with parent=global (well, according to this topic, simple queues are now completely separated from queue tree, so let's call it one more queue tree with the name 'global-2' )

Guys, can you test the new queues in the new rc3 on your development download page? Todays build

Can anyone explain to me what's the meaning of the priority parameter in Simple Queues. I do understand what this parameters does when specified on the child queues in a Queue Tree, but that does not quite seem to apply to Simple Queues... Or does it? Any thoughts?

In simple queues you can also make queue structures, with parent and child queues. In that case priority will halp to distribute parents traffic - similar to queue tree. In case you have all your simple queues in same level (no parent queues) you will not be able to see priority in action - as from simple queue perspective there is no bottleneck and no need to drop anything more than its max-limit.

Guys, can you test the new queues in the new rc3 on your development download page? Todays build

when I change max-limit in Queue Tree, the queue catches no more packets, but some 'hidden' queue with old parameters is still working disabling/enabling the queue did not solve the issue, only reboot helps

one global (well, not about global queues, but about ideology ) question: do we still need queue tree at all?

in the light of kernel-level optimizations of Simple Queues and remembering Occam's razor to make queues more homogeneous, maybe it worths to transform Queue Tree to another set of Simple Queues (like Queues Step 1 and Step 2, or something)

currently simple queues are smart enough to install only necessary part of its subqueues (upload/download), so theoretically it won't affect performance. moreover, it will simplify understanding of queueing ("what should I use - queue tree or simple queues?") and you can use all delights of simple queues (like built-in Graphing, so you won't need some dedicated MRTG machine to draw some part of your queues unaffected by standard tools)

My understanding is that simple queues are ordered, therefore evaluated one by one. This is less efficient than queue tree, which is evaluated by packet mark from firewall mangle. Therefore in a very complex setup queue trees are more efficient. Also in lab testing it appears simple queues don't adhere strictly to HTB rules for bandwidth re-distribution

My understanding is that simple queues are ordered, therefore evaluated one by one. This is less efficient than queue tree, which is evaluated by packet mark from firewall mangle. Therefore in a very complex setup queue trees are more efficient. Also in lab testing it appears simple queues don't adhere strictly to HTB rules for bandwidth re-distribution

have you seen v6 presentation from MUM? they redesigned simple queues, so now thousands of simple queues are not problem. and if that new "Ex-Tree Simple" queues will create just hidden queue tree queues, without performance loss, it will be more obvoius than having two separate interfaces. that's it

I have not seen it yet. If what you are saying is accurate then I agree, queue tree should not be required.

one global (well, not about global queues, but about ideology ) question: do we still need queue tree at all?

1. I want to shape uplink/downlink traffic, and doesn't want to shape local traffic - simple queue shape all traffic going to/from interface and don't look it if local (low-price) or external (expensive).

2. I want use all features of HTB and hierarchical queues is one of them. For example I want to make 2 groups of users and give for 1st group guaranteed bandwidth and for 2nd all other bandwidth. Usually it help us in critical situations then one of uplinks is down.

1. I want to shape uplink/downlink traffic, and doesn't want to shape local traffic - simple queue shape all traffic going to/from interface and don't look it if local (low-price) or external (expensive).

isn't it possible with simple queues?

ros code

/queue type
add kind=pcq name=up-1m   pcq-classifier=src-address pcq-rate=1M
add kind=pcq name=down-1m pcq-classifier=dst-address pcq-rate=1M
/queue simple
add name=queue1 target=LAN dst=WAN queue=up-1m/down-1m

2. I want use all features of HTB and hierarchical queues is one of them. For example I want to make 2 groups of users and give for 1st group guaranteed bandwidth and for 2nd all other bandwidth. Usually it help us in critical situations then one of uplinks is down.

do you know that simple queues do have 'parent' property? it's for hierarchy creation

again, I do NOT wat to remove some functionality, I want to make single powerful interface instead of splitting it on tabs with two _similar_ functions, and current state of v6 simple queues gives great possibilities for that

1. I want to shape uplink/downlink traffic, and doesn't want to shape local traffic - simple queue shape all traffic going to/from interface and don't look it if local (low-price) or external (expensive).

isn't it possible with simple queues?

ros code

/queue type
add kind=pcq name=up-1m   pcq-classifier=src-address pcq-rate=1M
add kind=pcq name=down-1m pcq-classifier=dst-address pcq-rate=1M
/queue simple
add name=queue1 target=LAN dst=WAN queue=up-1m/down-1m

Simple queues are simple only for simple tasks. It is difficult for me to understand if this code solves my problem.
Ok, for example
1. ether-wan is uplink (expensive traffic)
2. vlan1 is first client
3. vlan2 is second client
4. vlan3_1 is first office of third client
5. vlan3_2 is second office of third client

First our server should shape in such way:
* first client have 1mbit of uplink traffic
* second client have 2mit of uplink traffic
* traffic between first and second client should not go through queue, i.e. first and second client can communicate at wire speed.
and we have about 1200 users per server

Second our server should shape in such way:
* first office of third client have 3mbit of uplink traffic
* second office of third client have 4mbit of uplink traffic
* traffic from first office to second office need shape to 10mbit
* traffic from second office to first office need shape also to 10mbit

SQ seems to work good and solved problem with btest over nv2 link....
Can you tell me in shortage meaning of double qos?
What is the point of ip settings(why is that good for?)

Guys, can you test the new queues in the new rc3 on your development download page? Todays build

when I change max-limit in Queue Tree, the queue catches no more packets, but some 'hidden' queue with old parameters is still working disabling/enabling the queue did not solve the issue, only reboot helps

this is fixed in the new rc3 build

Simple queues are simple only for simple tasks.

simple queues are named this way due to historic reasons, at the start they where simple, but now, these can be considered simple only because you look at the name and if you use only basic features - set target and upload/download limit. And now here are so much more options what can be done with simple queues.

From looking at the diagram it appears that Queue Trees hit first, then simple queues are applied?

From looking at the diagram it appears that Queue Trees hit first, then simple queues are applied?

yep, now both are completely separate things.

From looking at the diagram it appears that Queue Trees hit first, then simple queues are applied?

yep, now both are completely separate things.

Excellent!

I played with this last night and still could not get it to work, so had to roll back to V5. I suppose I have made things more complicated for myself by expanding my network and using 2 more local interfaces on my RB1100ah.

Anyhow, I was using double QOS with NAT.

My ether1 is public facing (multiple public Ip's)
My ether 2 is Local facing (Public Ip's Natted across to customers who are grouped by service level) [ 6 groups so 6 public Ip's]

I only QOS upload using Tree with the parent being the Ether1, since its not possible to QOS download if you cant tell in what order packets are arriving anyway.

And I use address lists for the groups of customers.

I nearly understood the modified block diagram of Normis (nice), but it all seemed to go wrong (in my head) as soon as I started to consider the Nat.

And I am a fan of PCQ, I looked at the double qos method suggested before using SQ, but that would have meant 8 SQ's per client ( I use 8 levels of traffic priority) multiplied by the number of clients.

Is there an update to wiki for these changes.

I've seen plenty of comments on various threads regarding examples that don't "fit the bill", but I think that there are a few thousand of us with the same "stock set-ups" that need more clearer guidance and examples for double qos with the NAT scenario.

EG: an example that we can play around with, based on:

Qos upload against 1 public interface by traffic type
Bandwidth distribution to clients that are natted .

I have a basic grasp of PCQ now, and I really liked it, but I have to say that without a wiki things are becoming more confused especially when the packet flow through the interfaces are changing between ROS versions.

Nobody using NAT??

What's the reason for having SQ and QTree on INPUT? DDoS? VPN Tunnel shaping?

Also, what does it mean that PCQ is NAT aware? Is it so the pre src-NAT IP is used as source IP to classify a stream?

Well I think the silence is worrying and so is the lack of help.

MT, why do you "dump" these new ROS or changed things in our lap without adequate support.

Even the wiki is out of date and of no use.

Where have all the "old timers" gone, is no one using NAT and doing double QOS with version 6???

Thanks to your feedback in v6.0RC3 we will have some changes in QoS features.

We made simple queues completely independent from "Global" queue tree. Now simple queues will happen after "Global" queue tree:

packetflowv6.png

So there is no more need to remember who will get traffic first - simple queues or queues in "Global" queue tree. Now traffic can be captured by both separately and independently. This also give you possibility to implement Double QoS again.

1) mark traffic by type in mangle, and apply limitations by traffic type in "Global" queue tree
2) use dynamic simple queues from ppp servers or RADIUS or create simple queues manually and use PCQ for limiting traffic per user, "target" and "dst" options should allow us to make per-user-limitation without any problems

I usually do double qos by prioritizing traffic in prerouting section and shape in postrouting.
In a routing scenario i mark packets in prerouting to address them in a prioritizing queue (eg. using global-in) and then
remark them in fw-postrouting to be able to shape on global-out or interface queue.
this is straightforward because i can mark twice by using 2 separate and independant stage.
how can i apply the same logic in v6 if queueing section must uses only fw-postrouting marks ??
i guess in the near future someone implements the possibility to make multiple mark for packet, eg. new-packet-mark=mcr1,bes1,blablamark in this case more flexibility is added into qos...

What's the reason for having SQ and QTree on INPUT? DDoS? VPN Tunnel shaping?

customers' upload when using WebProxy?

What's the reason for having SQ and QTree on INPUT? DDoS? VPN Tunnel shaping?

customers' upload when using WebProxy?

i think you Talk about cause of Change in QOS Packet Flow ( Flowchart ) ( Queue in Input Direction ) This is True ?

But , In Which Scenario and Situation You Want to Classify Customers Upload , Usage , Cause ?

Do you Have a Scenario ?

sure. when I limit customer's upload and download speed, I want it to be limited even in case of WebProxy usage

sure. when I limit customer's upload and download speed, I want it to be limited even in case of WebProxy usage

Yes This is True , But Proles Is Here , in Almost all network users does not need Proxy for Upload .

Actually Proxy is Used for Decrease BW Usage and also Traffic Usage ( Internet Connection or ... )

So , Cache and Web Proxy in Common is Use for Inbound Traffic ( Download For Users & Customers )

So , Can be Use Input Chain , But its not Necessary for Web Proxy or ...

Anyway , Thank You !

Any successful configurations in high PPS multi-WAN multi-LAN environments? Do not brag - just post the config.

Please add the parameter "address-list" for the simple queue in ROS v6 ! it is not a dificult, but very usefull for many users
thanks ;p

Please add the parameter "address-list" for the simple queue in ROS v6 ! it is not a dificult, but very usefull for many users
thanks ;p

That would be a useful feature indeed. I would really like to see it.

you just mark necessary address-list in Mangle, then set packet-mark in Simple Queue

you just mark necessary address-list in Mangle, then set packet-mark in Simple Queue

Yes of course. But wouldn't be better to not have mangle rules at all? Simpler configuration.

you just mark necessary address-list in Mangle, then set packet-mark in Simple Queue

Yes of course. But wouldn't be better to not have mangle rules at all? Simpler configuration.

however, it makes the rules itselve "a bit" harder to implement. and, less transparent.

you just mark necessary address-list in Mangle, then set packet-mark in Simple Queue

but then you can't build double queueing ;p ...
because you mark services... then you do remark (address-list) ... so you lost mark for services without queueing ...
in this situation ...this is not a solution ....

PS.
I was ask question to support and I have got answer:

Hello,

Yes, we know about this feature request, but currently we don't have a way to do
it without slowing down performance significantly. Using mangle and packet mark
will be much faster than direct address-list approach. That is the only reason we
are not implementing this feature.

Regards,
Janis Megis

abandonment idea of double qos by mikrotik in v6 is very failed me....

Cheer up. If there are no crashes and the queues actually work, when v6 final is realease, - you should be able to use the new design to do what you need

ok but I write again
for double queueing v6 must use something for group users... packet mark or address-list to be suitable and scalable
in this moment for double queue I have to use indyvidual queues for every user ... and in this situation I cant use pcq for dynamic rates...


address-lists is wonderful tool for grouping users....I can't imagine simple queues without this option ;

Dynamic rates? Setting another queue as the parent of a simple queue will not work for you ?

Looks like the big number of simple queues can safely replace PCQ especially for big number of packets per second?

Dynamic rates? Setting another queue as the parent of a simple queue will not work for you ?

I dont understand... so I have to manualy create parent for group of users (group of simple queues) ... what about automatic creates simple queue... (for example from pppoe) I cant change the parent... so I have to create this queue manualy..
now my php/api software only add IP to address list... and thats all ....
now in v6 I have to creates complicated trees in simple queue for every client/group to do the same...
this is not a improvement !.....

I have two trees one for client limitation and one for services (when I have heavy network load ... peak load) queue tree guards the good level of services,

in firewall mangle before packet mark of client groups, I have mangle dns traffic, icmp etc... and this is in another queue (not in client limitation) ...
I have a couple of lists to dynamic limitation .....

I use address-list to many things...

with double queueing idea from v3,v4,5v this is very simple to do ... in v6 I can't do this ...

if I will be able use address-list in simple queue I will be able to do this, or if I can use packet-mark from mangle (but curently I cant because before I prioritize services ...i lost packet-mark ... )
this is a big problem so no I dont use v6...

I have a information from several networks with the same problem ...


the only advantage in v6 in traffic control is faster simple queue.... but I dont think that faster simple queues is more important than double qos idea....
especially that queue tree is the same fast ... and in v5 I can use mangle + tree to do simple client limitation (for example address-list in pppoe profile ...so I mark and create simple tree, the same situation in hotspot profile)... so were is the plus of simple queues ...when I can create the same in a simpler and faster way with queue tree + address-list (or dynamic address-list for pppoe or hot-spot profiles).... IN V6 I CAN'T DO MANY IDEAS !!!! .. andI lost the pros double queueing idea....

so I dont understand what is so important in faster simple queue at the expense of double queues idea .....

Sorry, I can not understand with simple rules. How will these rules with version 5 to 6:

/ip firewall mangle
add action=mark-packet chain=prerouting comment="Pam_Unlim_500_x2 SRC" disabled=no \
new-packet-mark=Pam_Unlim_500_x2-OUT passthrough=yes src-address-list=Pam_Unlim_500_x2
add action=mark-packet chain=postrouting comment="Pam_Unlim_500_x2 DST" disabled=no \
dst-address-list=Pam_Unlim_500_x2 new-packet-mark=Pam_Unlim_500_x2-IN passthrough=yes

/queue type
add kind=pcq name=Pam_Unlim_500_x2-IN pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=\
10s pcq-classifier=dst-address pcq-dst-address-mask=32 \
pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=512k pcq-src-address-mask=\
32 pcq-src-address6-mask=64 pcq-total-limit=2000
add kind=pcq name=Pam_Unlim_500_x2-OUT pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=\
10s pcq-classifier=src-address pcq-dst-address-mask=32 \
pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=512k pcq-src-address-mask=\
32 pcq-src-address6-mask=64 pcq-total-limit=2000

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=0 name=Pam_Unlim_500_x2-IN packet-mark=Pam_Unlim_500_x2-IN parent=global-out priority=1 \
queue=Pam_Unlim_500_x2-IN
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=0 name=Pam_Unlim_500_x2-OUT packet-mark=Pam_Unlim_500_x2-OUT parent=global-in priority=1 \
queue=Pam_Unlim_500_x2-OUT

what's problem with those rules?..

There is a problem with queue simple and tree in v6 and we had to downgrade to keep running our network.


We have a hotspot that create dinamics simple queues for each user.
Web have a proxy cache.

in v5.x we have a mangle that all traffic coming from cache get mark and pass to a queue tree with more bandwidth to client than the hotspot queue.

But now with v6 the packets get mark, the packets go through queue tree but the final bandwidth is given by simple queue.

Any idea?

as queue tree and simple queues are independent now, you need to create simple queue for cache traffic

so i can forgot queue tree and must do all simple queues :/

what's problem with that? what's significant difference? either you create a queue in the same place you limit your customers (what is actually more logical), or you use some other facility for that

no, no problem at all with that, just need get used to think it other way.

anyway is working now with simple queues.

my last question is about the priority in queue list, i mean, the dynamic ones always are in top of the list.

how works the execution order in simple queue list? by order list? or by priority?

by order, top to bottom. so if dynamic queues are added at the top, write to support@mikrotik.com so that they fix it. otherwise you won't be able to use your queue for cache hits after customer reconnect

now seems work even with the cache simple queues at the bottom of list.

im trying with v6.0 now, maybe they change the order of execution.

arrrgh, you're marking the traffic, that's why dynamic queues do not catch it

anyway, if somebody do the same without marking, it will affect him...

actuallly not work as should do :/

use both queues at same time so the hotspot queue still limit the final bandwith of the client.


any way to avoid use both queues ? just the first with priority or other kind of order it ?

system restart every 1 hour.....


..
..
..

Send the support file generated when reboot happens to support ppl, they will give you details about it.

What would then need to change with a current v5 Queue tree setup when upgrading to v6? As there is only a global queue do you specify a parent queue for up and download bandwidth and set the child queues to their specific parent as marked in the mangle (post & prerouting for in and outbound traffic) I tried this and it works but the router (TILE) crashes every hour also. What am I missing?

So there is no more need to remember who will get traffic first - simple queues or queues in "Global" queue tree. Now traffic can be captured by both separately and independently.

So there is no more need to remember who will get traffic first - simple queues or queues in "Global" queue tree. Now traffic can be captured by both separately and independently.

yep, but you need to remember: first queue tree, then simple queues

Can anyone explain to me what's the meaning of the priority parameter in Simple Queues. I do understand what this parameters does when specified on the child queues in a Queue Tree, but that does not quite seem to apply to Simple Queues... Or does it? Any thoughts?

as far as I (I hope) can (still) understand, Simple Queue with parent=none creates up to three hidden queues of queue tree with parent=global (well, according to this topic, simple queues are now completely separated from queue tree, so let's call it one more queue tree with the name 'global-2' )

Best Answer

I think you should add thumbs up icons for most appropriate answer.

no, no problem at all with that, just need get used to think it other way.

anyway is working now with simple queues.

my last question is about the priority in queue list, i mean, the dynamic ones always are in top of the list.

how works the execution order in simple queue list? by order list? or by priority?

why dont you use this script to move the desired queue to top
script :

/queue simple print
/queue simple move [find name="queue name"] 0


schedule it to run every 2 sec

Can someone please clarify this for me. I'm trialing ROS 6.x and got confused regarding QoS.

I was running double QoS on 5.x
- mangle prerouting + global-in to prioritise traffic
- mangle forwarding + global-out for PCQ to give each client equal bw
Just like found on many MT presentations and documents..

Now in 6.x there's no global-in/out but only 'global'.
The first post here suggests that double QoS can be achieved by combining simple queues and qtree.
That's fine, but isn't a packet in v6 now pulled though 'global' queue twice? Can't I reuse the principle from before v6 by using only 'global' for both prioritising and shaping?

If a packet gets marked differently before each pass through 'global', isn't that the same as if going first through 'global-in' and then 'global-out'?

Am I missing something?

Thanks!

isn't a packet in v6 now pulled though 'global' queue twice?

no, it's not

Can someone please clarify this for me. I'm trialing ROS 6.x and got confused regarding QoS.

I was running double QoS on 5.x
- mangle prerouting + global-in to prioritise traffic
- mangle forwarding + global-out for PCQ to give each client equal bw
Just like found on many MT presentations and documents..

Now in 6.x there's no global-in/out but only 'global'.
The first post here suggests that double QoS can be achieved by combining simple queues and qtree.
That's fine, but isn't a packet in v6 now pulled though 'global' queue twice? Can't I reuse the principle from before v6 by using only 'global' for both prioritising and shaping?

If a packet gets marked differently before each pass through 'global', isn't that the same as if going first through 'global-in' and then 'global-out'?

Am I missing something?

Thanks!

I exactly have a scenario like this.
with Ros 6 is not possible anymore, packet pass through first in queue tree (with parent on global) then in simple queue.
First i used to do qos in 2 independent stages, in prerouting and in postrouting. now its impossible.
The way you can achieve the same results is doing same marks in prerouting and make a simple queue for any IP you have to shape.
Since simple queue are quite faster the only problem is write the configuration.

Hello everybody.
I have a question that may help many people.
I´m working with RouterOS 3.xx and I have strong difficulty for implement QOS (double WAN) in version 6.xx. So I'll describe a small scene and would like to give a example of how would be only one rule in each row for understain the new concept table.

I'll use an example of a RB450G to facilitate understanding of the concepts of many users.

Interface Ether 1 = WAN-A ( Dedicated 1 IP Link FULL ) - ( Bandwidth 5mb /5mb ) <-Default Route.
Interface Ether 2 = WAN-B ( Link ADSL with 1 Dynamic IP PPPoE ) - ( Bandwidth 30mb / 3mb ) <-Second Link FailOver.
Interface Ether 3, 4 , 5 = (LAN Bridged and NATed).

I have two situations :
1 - All users are in the same group (shre range internal ips bridged) .
2 - All share the same internet link WAN-A with 5 MB FULL upload / download and WAN-B with 30mb(dw) e 3mb(up).
3 - There fail over WAN links between WAN-A and B. If the WAN-A goes down, the router will take navigate with WAN-B.
4 - I have just Queue HTB -Tree for all links but bandwidth speeds are different.

In this situation , anyone can give an example of how to create queue-three HTB in the mangle table for the WAN-A ( 5mb/5mb ) and WAN-B ( 30mb /3mb ), to control the upload and download traffic of these two interfaces and also in the ranks of queue table.

It is important to say. I have 8 HTB priorities example :
1 = DNS , ICMP ,other .
2 = SIP
3,4,5,6,7,8 = other...

I believe that answer of this example can help a lot of people, including after on Wiki.

Thank you all.

I believe that no one can answer this question. Not even in training is possible for someone to answer this question clearly.
Thnx

So what is the question exactly and why didn't you make a new thread since this one is for v6?

QoS for Dual-Wan should control the max tx and rx of each WAN.

I don't have time to pay more attention to this at the moment so good luck from me.

Regards.

this explains a lot regarding new QoS - how and where
http://forum.mikrotik.com/viewtopic.php?f=2&t=72736

Can someone please clarify this for me. I'm trialing ROS 6.x and got confused regarding QoS.

I was running double QoS on 5.x
- mangle prerouting + global-in to prioritise traffic
- mangle forwarding + global-out for PCQ to give each client equal bw
Just like found on many MT presentations and documents..

Now in 6.x there's no global-in/out but only 'global'.
The first post here suggests that double QoS can be achieved by combining simple queues and qtree.
That's fine, but isn't a packet in v6 now pulled though 'global' queue twice? Can't I reuse the principle from before v6 by using only 'global' for both prioritising and shaping?

If a packet gets marked differently before each pass through 'global', isn't that the same as if going first through 'global-in' and then 'global-out'?

I have the same problem with 6.7, I use global-in to prioritise traffic and global-out for PCQ to give each client equal bw
I upgraded my MT to 6.7 but the double qos doesn't work well and I had to reverted to 5.26
I had tried use dynamic simple queue + queue tree but it doesn't work well when clients are watching video

when can we expect that this will be improved?

In my experience such problems are due to performance limitations in the design but mostly configuration issues.

I believe RouterOS is quite the miracle already. "QoS" code have been recently improved.

You may post your specific configuration in a separate thread if you are comfortable with some configuration disclosure. Someone from the forums should be able to point out one or two things.

Regards.

Hello Guru,

You can give only one mangle exemple for the two tables (double WAN with QOS HTB) in version 6.7 ?

Interface Ether 1 = WAN-A ( IP-1 10.10.10.10 ) <-Default Route.
Interface Ether 2 = WAN-B ( IP-2 20.20.20.20 ) <-Second Link (With LOAD BALANCE WEB CONN PORT 80)
Interface Ether 3, 4 , 5 = (LAN Bridged and NATed).

I need after all mangle marked set those on QOS HTB with exemples to upload e download.

You can exemplify ?

Thank you very much.

You can give only one mangle exemple for the two tables (double WAN with QOS HTB) in version 6.7 ?

Interface Ether 1 = WAN-A ( IP-1 10.10.10.10 ) <-Default Route.
Interface Ether 2 = WAN-B ( IP-2 20.20.20.20 ) <-Second Link (With LOAD BALANCE WEB CONN PORT 80)
Interface Ether 3, 4 , 5 = (LAN Bridged and NATed).

I need after all mangle marked set those on QOS HTB with exemples to upload e download. You can exemplify?

Maybe my configuration can help you to resolve this problem:

ros code

#================================================
# For RB750GL and ROS v6.x
# WAN connect to Internet:
#  - eth1-ISP1 from ISP1 (FE:Down-100Mbps/Up-100Mbps/static IP)
#  - eth1-ISP2 from ISP2 (DOCSIS3.0>GE:Down-150Mbps/Up-5Mbps/dynamic IP)
# LAN switch:
# - eth3-LAN-master
# - eth4-LAN-slave
# - eth5-LAN-slave
# Address List:
# - LAN - define IP ranges for Local network
# - to-ISP1 - Addresses accessible through ISP1
# - to-ISP2 - Addresses accessible through ISP2
#================================================
/ip firewall mangle
add chain=prerouting action=jump jump-target=in-ISP1 in-interface=eth1-ISP1 \
    comment="Trafic incoming ISP1"
add chain=prerouting action=jump jump-target=in-ISP2 in-interface=eth2-ISP2 \
    comment="Trafic incoming ISP2"
add chain=prerouting action=jump jump-target=connect-new connection-state=new \
    comment="Call mark 'new-connection' for prerouting"
add chain=prerouting action=jump jump-target=connect-related connection-state=related \
    comment="Call mark 'related-connection' for prerouting"
add chain=output action=jump jump-target=connect-new connection-state=new \
    comment="Call mark 'new-connection' for output"
add chain=output action=jump jump-target=connect-related connection-state=related \
    comment="Call mark 'related-connection' for output"
add chain=prerouting action=mark-routing new-routing-mark=R:balans-ISP1 connection-mark=C:balans-ISP1 \
    passthrough=no comment="Routing balanced ISP1"
add chain=prerouting action=mark-routing new-routing-mark=R:balans-ISP2 connection-mark=C:balans-ISP2 \
    passthrough=no comment="Routing balanced ISP2"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP1 connection-mark=C:Admin \
    passthrough=no comment="Routing outgoing-Admin packets to ISP1"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP1 connection-mark=C:WebSurf \
    passthrough=no comment="Routing outgoing-WebSurf packets to ISP1"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP1 connection-mark=C:static-ISP1 \
    passthrough=no comment="Routing packet statically outgoing ISP1"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP2 connection-mark=C:static-ISP2 \
    passthrough=no comment="Routing packet statically outgoing ISP2"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP1 connection-mark=C:in-ISP1-Admin \
    passthrough=no comment="Routing Admin-packet returning to ISP1 from LAN"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP2 connection-mark=C:in-ISP2-Admin \
    passthrough=no comment="Routing Admin-packet returning to ISP2 from LAN"
add chain=output action=mark-routing new-routing-mark=R:static-ISP1 connection-mark=C:in-ISP1-Admin \
    passthrough=no comment="Routing Admin-packet returning to ISP1 from ROS"
add chain=output action=mark-routing new-routing-mark=R:static-ISP2 connection-mark=C:in-ISP2-Admin \
    passthrough=no comment="Routing Admin-packet returning to ISP2 from ROS"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP1 connection-mark=C:in-ISP1 \
    passthrough=no comment="Routing packet returning to ISP1 from LAN"
add chain=prerouting action=mark-routing new-routing-mark=R:static-ISP2 connection-mark=C:in-ISP2 \
    passthrough=no comment="Routing packet returning to ISP2 from LAN"
add chain=output action=mark-routing new-routing-mark=R:static-ISP1 connection-mark=C:in-ISP1 \
    passthrough=no comment="Routing packet returning to ISP1 from ROS"
add chain=output action=mark-routing new-routing-mark=R:static-ISP2 connection-mark=C:in-ISP2 \
    passthrough=no comment="Routing packet returning to ISP2 from ROS"
add chain=in-ISP1 connection-mark=!no-mark comment="Accept marked connection incoming ISP1"
add chain=in-ISP1 action=mark-connection new-connection-mark=C:in-ISP1-Admin connection-state=new \
    protocol=tcp dst-port=22,3389,8291 \
    passthrough=no comment="New Admin (SSH/RDP/WinBox) connection incoming ISP1" 
add chain=in-ISP1 action=mark-connection new-connection-mark=C:in-ISP1 connection-state=new \
    passthrough=no comment="New connection incoming ISP1" \
add chain=in-ISP1 action=mark-connection new-connection-mark=C:in-ISP1 connection-state=related \
    passthrough=no comment="Related connection incoming ISP1" \
add chain=in-ISP2 connection-mark=!no-mark comment="Accept marked connection incoming ISP2"
add chain=in-ISP2 action=mark-connection new-connection-mark=C:in-ISP2-Admin connection-state=new \
    protocol=tcp dst-port=22,3389,8291 \
    passthrough=no comment="New Admin (SSH/RDP/WinBox) connection incoming ISP2" 
add chain=in-ISP2 action=mark-connection new-connection-mark=C:in-ISP2 connection-state=new \
    passthrough=no comment="New connection incoming ISP2"
add chain=in-ISP2 action=mark-connection new-connection-mark=C:in-ISP2 connection-state=related \
    passthrough=no comment="Related connection incoming ISP2"
add chain=connect-new action=mark-connection new-connection-mark=C:LAN-ROS src-address-list=LAN dst-address-type=local \
    passthrough=no comment="New connection from LAN to ROS"
add chain=connect-related action=mark-connection new-connection-mark=C:LAN-ROS src-address-list=LAN dst-address-type=local \
    passthrough=no comment="Related connection from LAN to ROS"
add chain=connect-new action=mark-connection new-connection-mark=C:ROS-LAN src-address-type=local dst-address-list=LAN \
    passthrough=no comment="New connection from ROS to LAN"
add chain=connect-related action=mark-connection new-connection-mark=C:ROS-LAN src-address-type=local dst-address-list=LAN \
    passthrough=no comment="Related connection from ROS to LAN"
add chain=connect-new action=mark-connection new-connection-mark=C:ROS-WAN src-address-type=local dst-address-list=!LAN \
    passthrough=no comment="New connection from ROS to WAN"
add chain=connect-related action=mark-connection new-connection-mark=C:ROS-WAN src-address-type=local dst-address-list=!LAN \
    passthrough=no comment="Related connection from ROS to WAN"
add chain=connect-new action=mark-connection new-connection-mark=C:Admin \
    src-address-list=LAN protocol=tcp dst-port=22,3389,8291 \
    comment="New connection Admin (SSH/RDP/WinBox) LAN>WAN"
add chain=connect-new action=mark-connection new-connection-mark=C:WebSurf \
    src-address-list=LAN protocol=tcp dst-port=80,443 \
    comment="New connection WebSurf (HTTP/HTTPS) LAN>WAN"
add chain=connect-new action=mark-connection new-connection-mark=C:static-ISP1 connection-mark=no-mark \
    dst-address-list=to-ISP1 src-address-list=LAN \
    comment="New connection LAN>AdrList:to-ISP1"
add chain=connect-new action=mark-connection new-connection-mark=C:static-ISP2 connection-mark=no-mark \
    dst-address-list=to-ISP2 src-address-list=LAN \
    comment="New connection LAN>AdrList:to-ISP2"
add chain=connect-related action=mark-connection new-connection-mark=C:static-ISP1 connection-mark=no-mark \
    dst-address-list=to-ISP1 src-address-list=LAN \
    comment="Related connection LAN>AdrList:to-ISP1"
add chain=connect-related action=mark-connection new-connection-mark=C:static-ISP2 connection-mark=no-mark \
    dst-address-list=to-ISP2 src-address-list=LAN \
    comment="Related connection LAN>AdrList:to-ISP2"
add chain=connect-new action=mark-connection new-connection-mark=C:balans-ISP1 connection-mark=no-mark src-address-list=LAN \
    comment="New connection to WAN with balancing PCC-2/1" per-connection-classifier=both-addresses:2/0
add chain=connect-new action=mark-connection new-connection-mark=C:balans-ISP2 connection-mark=no-mark src-address-list=LAN \
    comment="New connection to WAN with balancing PCC-2/2" per-connection-classifier=both-addresses:2/1
add chain=connect-related action=mark-connection new-connection-mark=C:balans-ISP1 connection-mark=no-mark src-address-list=LAN \
    comment="Related connection to WAN with balancing PCC-2/1" per-connection-classifier=both-addresses:2/0
add chain=connect-related action=mark-connection new-connection-mark=C:balans-ISP2 connection-mark=no-mark src-address-list=LAN \
    comment="Related connection to WAN with balancing PCC-2/2" per-connection-classifier=both-addresses:2/1
add chain=postrouting action=mark-packet new-packet-mark=P:LAN-WAN-Admin_out connection-mark=C:Admin src-address-list=LAN \
    passthrough=no comment="Packet-out Admin LAN>WAN"
add chain=postrouting action=mark-packet new-packet-mark=P:LAN-WAN-Admin_in connection-mark=C:Admin dst-address-list=LAN \
    passthrough=no comment="Packet-in Admin LAN>WAN"
add chain=input action=mark-packet new-packet-mark=P:ISP1-ROS-Admin_in connection-mark=C:in-ISP1-Admin dst-address-type=local \
    passthrough=no comment="Packet-in Admin via ISP1>ROS"
add chain=postrouting action=mark-packet new-packet-mark=P:ISP1-ROS-Admin_out connection-mark=C:in-ISP1-Admin src-address-type=local \
    passthrough=no comment="Packet-out Admin via ISP1>ROS"
add chain=postrouting action=mark-packet new-packet-mark=P:ISP1-LAN-Admin_in connection-mark=C:in-ISP1-Admin dst-address-list=LAN \
    passthrough=no comment="Packet-in Admin via ISP1>LAN"
add chain=postrouting action=mark-packet new-packet-mark=P:ISP1-LAN-Admin_out connection-mark=C:in-ISP1-Admin src-address-type=local \
    passthrough=no comment="Packet-out Admin via ISP1>LAN"
add chain=input action=mark-packet new-packet-mark=P:ISP2-ROS-Admin_in connection-mark=C:in-ISP2-Admin dst-address-type=local \
    passthrough=no comment="Packet-in Admin via ISP2>ROS"
add chain=postrouting action=mark-packet new-packet-mark=P:ISP2-ROS-Admin_out connection-mark=C:in-ISP2-Admin src-address-type=local \
    passthrough=no comment="Packet-out Admin via ISP2>ROS"
add chain=postrouting action=mark-packet new-packet-mark=P:ISP2-LAN-Admin_in connection-mark=C:in-ISP2-Admin dst-address-list=LAN \
    passthrough=no comment="Packet-in Admin via ISP2>LAN"
add chain=postrouting action=mark-packet new-packet-mark=P:ISP2-LAN-Admin_out connection-mark=C:in-ISP2-Admin src-address-list=LAN \
    passthrough=no comment="Packet-out Admin via ISP2>LAN"
add chain=postrouting action=mark-packet new-packet-mark=P:LAN-WAN-WebSurf_out connection-mark=C:WebSurf src-address-list=LAN \
    passthrough=no comment="Packet-out WebSurf LAN>WAN"
add chain=postrouting action=mark-packet new-packet-mark=P:LAN-WAN-WebSurf_in connection-mark=C:WebSurf dst-address-list=LAN \
    passthrough=no comment="Packet-in WebSurf LAN>WAN"

Please add the parameter "address-list" for the simple queue in ROS v6 ! it is not a dificult, but very usefull for many users
thanks ;p

+1 for that!

Example of a hotspot configuration:
- Dual wan (ISP1, ISP2).
- PCC load balancing based on src-address. This means, I'm load balancing users, not the traffic.
- Traffic prioritization with mangle rules and queue tree.
- Per user limitation in Simple Queues.

With the dual wan + automated load balancing, the user limiting in IP-> Hotspot-> User profiles is useless. I can't use the parent option (Hotspot-> User Profile-> Queue-> Parent Queue). I don't know who will be the parent, because of the automated load balancing.
The mangle rules are also not an option. They are already reserved for traffic prioritization and PCC.

So, I configured the per user limitation with Simple Queues. The method is PCQ. The limitation is based on interfaces.
Example1:
All users going from LAN to ISP1 will be put in the Simple PCQ Queue1.
All users going from LAN to ISP2 will be put in the Simple PCQ Queue2.

I need to create 2 PCQ rules, because I have 2 ISPs. The PCQ will not function properly if I have not specified the total upload/download limit for each ISP.

With PCQ rules I can only specify 1 user limit for all my users. Let's say, this is 1M upload/5M download. PCQ will give each user maximum 1M upload / 5M download. All users are equal. I can't give some users 2M upload / 10M download.

The address-list option in Simple Queues would solve this problem. ROS gives me in IP-> Hotspot -> User profiles the option to assign users to a dynamic address list.

Example2:
I would create 2 hotspot user profiles. One profile for 1M/5M user limit, the other for 2M/10M user limit. I would not specify the limits in these profiles. They are for my configuration useless. I would create them, in order to create 2 dynamic address lists. For each profile 1 address list.

In the Simple Queues I would create 4 PCQ rules + 2 parent rules.
4 PCQ rules, because I have automated load balancing. I don't know to which ISP every user has been assigned. Remember, ROS reads the Simple Queue rules from top to bottom. Like the firewall rules.
In the previous example a PCQ rule was also the parent, because there was only 1 rule per interface. In this example there are 2 rules per interface. That is why we now need separate parent rules.

Parent rule1 - ISP1
1.a Give users from address-list1 and going to ISP1 1M/5M user limit.
1.b Give users from address-list2 and going to ISP1 2M/10M user limit.
Parent rule2 - ISP2
2.a Give users from address-list1 and going to ISP2 1M/5M user limit.
2.b Give users from address-list2 and going to ISP2 2M/10M user limit.

A user who pays for 2M upload / 10M download authenticates. His ip address would be put in the dynamic address-list2. Load balancing puts him to, let’s say, ISP1. ROS would read this information and put him in the appropriate rule.
When he logs off, his dynamic ip address would be removed from the address list. Next time he logs in, maybe the PCC will put him to ISP2. No problem. For that reason I created 4 PCQ rules.

With this option, limiting users in Simple Queues would be based on usernames, not on ip addresses. Usernames are always the same. Ip addresses change. When a user connects with laptop, username is the same. Ip address is, example, "192.168.20.1". When he connects with the smartphone, username is again the same, ip address is not (example: 192.168.20.42). The dynamic ip addresses of this user would be always put in the same address list, because the address list is directly connected with the hotspot user profile.