WMM with NStreme

Hi all. A while back in another thread (http://forum.mikrotik.com/t/when-new-beta-when-wireless-qos/11740/29) I asked WMM and NStreme but never received a reply so thought I’d start a new post on the subject. Basically, I want to know:

  1. Do all clients on the AP need to support WMM for it to be active on the ap?
  2. If WMM and Nstreme are being run together are there any conflicts with both protocols trying to control the traffic or do they enhance each other?
  3. If NStreme packs a load of small packets together to make 1 large packet how does it know which packets priority to use for the large packet?

Many thanks,

P.

Very good question… We will have to wait and see who respond… :slight_smile:

Regards!

  1. No, but this can be enforced using “wmm-support=required”

  2. WMM does not work together with nstreme, nstreme ensures high speed
    in-order packet delivery. To prioritize packets over nstreme link use queues.

  3. see above

The problem with queues is you have to know what bandwidth your link is capable of then set the parent queue to be slightly less than that figure. If you then get some poor weather that reduces the maximum throughput of the link you then find the queuing doesn’t work and small priority packets like VoIP get buffered. I was hoping WMM would at least provide a fall back in the event of this happening but as we ensure both AP and CPE are Mikrotik we need NStreme for small packets again like VoIP.

Are there any plans to add QoS into NStreme to priorities packets at the wireless mac level?

does this mean that enableing WMM on a link that is running NStream, will have zero effect? on the status it shows it as WMM enabled at the same time as NStream…

why can they not work together?

extremely disappointed!!!

hope they are working on a qos nstream version…

how to use queue when using pppoe traffic and ipoe tunnel up to the ap???

I think i have to start to look around…

for Nstreme to achieve it’s high speeds, it has to ignore a lot of stuff, including WMM priorities. If you want WMM to work with it, it will not be fast anymore, so it will have no purpose. Nstreme is so fast because it doesn’t listen to anything.

IMPORTANT! with WMM can do exactly the same what you can do with queue and priorities.

please read what WMM does here: http://wiki.mikrotik.com/wiki/WMM

so using v3, we can follow all the instruction on the wiki about pppoe server and ap, but then on the ap we have trasparently shaping the traffic on the bridge using queue?

right?
regards
Ros

That’s not true. With WMM enabled at the wireless level your traffic shaping should adjust to poor weather conditions automatically but with static queues this is not possible. This means that you have to set your static queuing as if the wireless link is running in worse case scenario to prevent poor weather affecting high priority traffic like VoIP on a busy network.

Normis, is there a way to have queues that adapter with the quality of a wireless link other than enabling WMM???

or how about a special WMM version for NStream? there has got to be some way in which you can couple the concept of WMM into the polling engine (or maybe framing policy)…

If the AP has 5 packets with various TOS values set (P1-TOS1, P2-TOS8, P3-TOS16, P4-TOS2 and P5-TOS4) queued for delivery to 5 differnt CPEs with NStream + Polling enabled, then the AP should transmit them to the CPEs in order of TOS, (P3, P2, P5, P4, P1), then once it has cleared that queue and polled all CPEs for their transmissions, look at the new packets queued for delivery and transmit them based on TOS values.

Or if framing policy is enabled, then if 4 packets arrive on the ethernet interface destined for a wireless client, 2 with a high TOS value, and the other 2 with a low TOS value, assuming the framing policy can only transmit 3 packets at this time due to size limits, it will transmit the 2 higher priority packets, plus the lower priority packet that arrived first, then on the next transmission interval, transmit the queued lower priority packet held from the previous transmission, plus any high priority packets that have arrived, and if there is still room, any lower priority ones waiting as well.

and while you’re at it, if there is anything that can be done to stablize the latency a little when there are 30 stations connected to the AP (nstream+polling) that would be great, even if it means the latency is slightly little higher then average now, as long as it’s more stable it would be better (that would definitly help VoIP traffic)

the logic behind this is pretty easy, however implementing it may not be, but I think most people here would agree that they would be happy with some delays in v3 if this or something similar could be added…

I would like to hear thoughts and ideas on this from everyone else, If there is enough support for it, I’m sure we can convince Normis and Tully to get the programmers to start working on it. :slight_smile:

Speed is noting without control…

So I hope Mt will start to think about nstream-qos version

Regards
Rosario

qos over nstream is really about the only thing that alverion has mikrotik beat on right now, and the only thing that is stopping us from being able to offer a high quality voip service to our customers.

If I had full end to end qos, I would start selling a branded voip service (I already have a fiber connection to the provider…) and easily increase my monthly revinue at least 20%, without signing on a single additional customer, this would in turn allow me to afford to build out to new areas even faster (hint hint, means more sales)…

not to mention our existing customers would notice a slight improvment in regular performance.

Another question I have is if you can’t use NStreme with WMM which will give the best results? I’m guessing stick with NStreme for the high speed backhaul but use WMM on P-T-M? Of course it will depend on the traffic but if it is mainly business internet combined with VoIP? Thoughts?

It still not possible to build a queue if you use PPPoE over Vlan ncapsulated into EoIP tunnell. In fact in this scenrio only possible to get priority from ingess inside the bridge filter, but then you don’t have any tools to mark the packet by priority.

I discussed at the MUM with Dimitri and hope you fill find a solution soon…

Regards
Ros

it depends on where if it is the vlan or the EoIP tunnel that connects to the AP, if it is the VLAN then yes you can:
http://forum.mikrotik.com/t/wmm-and-pppoe-incompatibility/15852/1

Are you guys planning on implementing any MAC layer QoS that will work with NStreme?

yes you can trasport the priority up to the Ap but then you can’t mark the packet about it.
So if you have all around configured your customers with nstream you can’t use queue to simulate something near wmm.

We discussed with all the MT guy and they argued that they have to work about it.

Regards
Ros

So they will try and look into it? That’s great news. Wish I had had the time to meet the guys at one of the Mum’s. Maybe when they are next in Europe I will have time :wink:

working on add a mangling rule based on priority in ingress.
But not on a qos version of nstream. This is not a great news.

I think that the customers base of all of us is growing very fast and it is not possible to ignore the nstream problem in a crowd enviroment.
My idea is to ha a new version of nstream more configurable by us where we can decide to pu in qos where we need it (loosing some performance in throughput) and disabling where we don’t need it.

Regards
Ros

you are correct that with v2.9 you can not, but v3.0 you can…

/interface bridge filter 
add action=mark-packet chain=forward comment="" disabled=no in-interface=vlan1 \
    mac-protocol=vlan new-packet-mark=pri1 vlan-priority=1

at that point you’ve marked the packet and can assign it to regular queue’s as normal.

it doesn’t solve the QOS problem, but I guess it’s better then nothing. I’d much rather have a functioning version WMM as opposed to staticlly setting simple queue’s…