WMM with NStreme

phendry · Sat Oct 06, 2007 12:38 pm

Hi all. A while back in another thread (http://forum.mikrotik.com/viewtopic.php ... wmm#p86132) 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.

Alessio Garavano · Tue Oct 09, 2007 6:39 pm

Very good question... We will have to wait and see who respond...

Regards!

Wed Oct 10, 2007 4:57 pm

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

phendry · Wed Oct 10, 2007 5:08 pm

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

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?

BrianHiggins · Wed Oct 10, 2007 6:06 pm

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

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?

rpingar · Thu Oct 11, 2007 12:05 am

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..............

Fri Oct 12, 2007 2:19 pm

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

rpingar · Fri Oct 12, 2007 3:26 pm

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

phendry · Fri Oct 12, 2007 6:01 pm

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

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???

BrianHiggins · Fri Oct 12, 2007 8:09 pm

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.

rpingar · Sun Nov 04, 2007 10:51 am

Speed is noting without control...............

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

Regards
Rosario

BrianHiggins · Sun Nov 04, 2007 8:35 pm

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

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.

phendry · Tue Nov 20, 2007 11:46 pm

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?

rpingar · Thu Nov 22, 2007 6:22 pm

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

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

BrianHiggins · Wed Nov 28, 2007 5:44 pm

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/viewtopic.php ... 383&hilit=

phendry · Wed Nov 28, 2007 10:36 pm

for Nstreme to achieve it's high speeds, it has to ignore a lot of stuff, including WMM priorities.

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

rpingar · Thu Nov 29, 2007 12:52 am

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/viewtopic.php ... 383&hilit=

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

phendry · Thu Nov 29, 2007 3:23 am

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

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

rpingar · Thu Nov 29, 2007 9:10 am

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

BrianHiggins · Mon Dec 03, 2007 11:43 pm

yes you can trasport the priority up to the Ap but then you can't mark the packet about it.

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...

rpingar · Tue Dec 04, 2007 9:21 am

yes you can trasport the priority up to the Ap but then you can't mark the packet about it.
you are correct that with v2.9 you can not, but v3.0 you can...
Code: Select all
/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...

Sorry to say you that the packets entering the bridge by vlan interface are not vlan incapsualted anymore.
So you can't catch anything with that rule. We extensively test it with mt guys.

Regards
Ros

rpingar · Tue Dec 25, 2007 10:31 pm

any update from MT about this issue?

How to mark packets by ingress priority or by priority??????

regards
Ros

BrianHiggins · Thu Jan 17, 2008 1:06 am

Sorry to say you that the packets entering the bridge by vlan interface are not vlan incapsualted anymore.
So you can't catch anything with that rule. We extensively test it with mt guys.

Regards
Ros

I have only tested this enough to know that it showed the counters were incrementing, so it sure seems to be catching things...

rpingar · Thu Jan 17, 2008 9:15 am

Mikrotik implemented priority matcher in the latest rc release to solve the problem I reported.

Regards
Ros

fbaffoni · Sun Jun 15, 2008 1:54 am

What about the M3P protocol, to give QoS? work with Nstreme Dual, in bridged networks?

Someone test it? How is working?

Thank You

airnet · Fri May 22, 2009 5:46 am

List

There is already a standardised protocol that everyone here is requesting.
The Wi-Fi Alliance has drawn on some of the more advanced elements of 802.11e to create WMM-SA, or WMM Scheduled Access.

WMM-SA is a finely tuned enhancement to WMM
To the best of my knowledge WMM-SA is a software enhancement to platforms that already support WMM.
This assumption is based on the fact that the Proxim MP11a family utilise WMM-SA and that they use the same Atheros cards/chipset that support WMM that we use in MT

WMM (non SA) enabled on MT works beautifully at ensuring a guaranteed voice service.

What WMM (non SA) lacks is that it is very inefficient and that more-than-required low priority data packets are dropped when there are only a handful of voice calls active on the MT AP at one time.
A rough theory that we have concluded is that with WMM enabled, ALL your voice calls will be perfect quality, but for every call in progress, kiss good bye to 500-700kbps of overall AP UPLOAD (client to AP) capacity.
DOWNLOAD (AP to Client) capacity is not sacrificed much at all with WMM enabled.

WMM-SA fixes this problem whereby 1 x voice call will only 'reserve' the equivalent of that calls' traffic.
eg for each concurrent call you only lose that concurrent calls' worth of upload and download capacity eg 35kbps x 2 etc.

Note: NSTREME must be disabled for WMM to work. And overall, our intensive testing has concluded that in a multipoint environment with voice services, WMM is FAR superior at guaranteeing voice quality than NSTREME.

I suggest that eveyone reading this goes here and votes for WMM-SA: http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Cheers

Fri May 22, 2009 2:23 pm

Have also added to the v4 feature request list http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Fingers crossed on this one though, this would benefit a lot of WISP's

WMM with NStreme

WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Re: WMM with NStreme

Who is online