The WMM Wiki entry is a good start but I’ll be kind and say whoever wrote it clearly didn’t finish it.
It’s pretty clear to me now that if you want good performance with Mikrotik and CAPSMAN in an organisation with way more mobile and portable devices than plugged-into-a-gigabit-eth devices you probably need to make sure that:
Full Multicast helper is enabled.
Local forwarding and client-to-client is enabled.
As WMM is on by default in CAPSMAN you need some mangling rules. Aha, but what exactly?
The Wiki mentions to use set-priority and this is what I want to get right. Are these 2 rules shown below set on an an access point sufficient, redundant or even correct to maximise WMM performance for all data coming in over an WLAN, Eth and Bridge interface?
add action=set-priority chain=postrouting comment=“Set priority for WMM” new-priority=
from-dscp-high-3-bits passthrough=yes
add action=set-priority chain=postrouting comment=“Set priority for WMM” new-priority=from-ingress
passthrough=yes
I posted on another thread about IPv6 and set-priority that I noticed Airplay was using an IPv6 address fe80: with DSCP set to 32 to send Airplay data from a Macbook to an AppleTV. There is no set-priority action for IPv6 which is a shame in 2017!
As an aside I have found AppleTV3/4 devices work much better with Airplay if they are plugged into ethernet. A wAP-AC set only to 5GHz a Macbook Air and AppleTV all running on Wifi have abysmal performance even if in the same room.
It depends. On SMB environments you may want to allow users to connect to each other in L2. But on most scenarios, don’t; in any case it may actually degrade performance, not the reverse.
As WMM is on by default in CAPSMAN you need some mangling rules. Aha, but what exactly?
Again, it depends. WMM is used between AP ↔ Station. If cAPs use PTPs towards the CAPsMAN, then it may make sense on the PTPs in case the CAPsMAN tunnels didn’t already carry out such information. If they’re wired, I cannot see what would doing that would bring as benefit but actually the opposite as every single packet will have to go through the mangle manipulation.
As an aside I have found AppleTV3/4 devices work much better with Airplay if they are plugged into ethernet. A wAP-AC set only to 5GHz a Macbook Air and AppleTV all running on Wifi have abysmal performance even if in the same room.
Haven’t experienced that, I actually use on a daily basis an AppleTV3 connected wirelessly to a Hap AC, no problems streaming more than 10 meters away either from a iphone 5c (both on same 5GHz radio), ipad mini 2 or ipad… only “special” setting being multicast helper set to full.
In this form and sequence they are redundant. You need to use only one of them, or use the second one first and extend the other one with a “prority=0” condition.
The “from-ingress” setting takes the priority from info on the input interface, where it is only present for certain situations (VLAN interfaces, WLAN).
The “from dscp” setting takes the priority from a field in the IP packet. This always works, but it relies on the proper DSCP value being present in the traffic.
This will usually be the case for internal traffic from devices like IP telephones (dscp 46) but traffic incoming from internet may have its dscp reset to zeroes by admins of routers along the way.
You can then re-create a proper dscp value when you can recongnize the traffic e.g. by protocol/port, and then use the above rules to copy the priority to WMM.
I understand now - the best rule to use the one with DSCP bits, that way all traffic will get promoted to the appropriate WMM queue whether it comes in on WLAN or ETH. The ingress case I was thinking that it would preserve WMM priority of incoming packets in cases of client-to-client on the same AP without needing to look at DSCP. But as you suggest it’s 2x the work for no benefit.
The place I am testing all this is a school with lots of iPads, Macbook Airs and AppleTV’s so Airplay Mirror gets used a lot. The Apple TV’s are all cabled in to reduce Wifi use and improve reliability.
The killer is discovering the other day that the OSX devices are pushing Airplay Mirror on IPv6 (using fe80: addresses) and the IPv6 mangler is missing the set-priority action which makes WMM useless in this case!
So far I have chosen local forwarding to keep things as lean and fast as possible and allow high speeds for laptops connecting to local smb:// shares - WAPAC to my laptop transfers at 35MB/s no problem. The CAPSMAN controller is an RB2011 and I haven’t thought about doing all encapsulated CAPSMAN and which more expensive Mikrotik router could handle the load.