06-04-2015 02:47 PM
The organisation I work for is very soon about to embark on a significant roll-out of Lync 2013/Skype for Business. As I understand, there are several methods that can be used to ensure the correct marking and classification of the various Lync modalities.
From what I have read in this document http://www.arubanetworks.com/assets/tg/SG_Microsof
What I'm unsure of, and need some clarification of is the following:
- how, when a client has both data, voice and video to send, and is contending with its peers, does voice get prioritised? Does WMM need to be enabled on the client. Do I need to do anything else other than define the Policy based QoS so the respective modalities are tagged correctly? If so, what values should be used, I was reading that DSCP 46 doesn't map correctly to WMM and as such I should consider something higher i.e. 48 or 56. Is this correct? and if so should I specify this in the policy based QoS.
- On our WAN we use EF (46) for voice, if I do specify a higher value for the client (48/56) and have the same in the DSCP options on the SSID, how do I then map this to 46 on the controller, or should I look to do this on the upstream switch?
I'm happy to read up more on this myself if anybody can refer me to any best practices. I'm just struggling a little with the two points above. Everything else I get.
Solved! Go to Solution.
06-04-2015 05:50 PM
"how, when a client has both data, voice and video to send, and is contending with its peers, does voice get prioritised?"
On a client device that is WMM capable (Pretty much all modern WLAN clients) when the application (or Windows Group Policy) mark a packet in the IP stack, the wireless driver will take that marking and convert it to a WMM value 7 for voice or 5 for video. As long as the driver is working as it should (Early versions of the MS Surface driver didn't have WMM enabled) the packets will get prioritized. "How?" you ask " can a shared medium prioritize packets?" Well it's all down to how the contention window works in 802.11. Non prioritized packets all work the same way:
- Client has a packet to transmit.
- It listens on the channel
- If no one is transmitting it waits a standard period of time and then listens again (EDCA backoff timer)
- If no one is transmitting, that client transmits.
A voice or video packet has a shorter backoff timer than a standard packet. This gives the voice packet a greater chance of being transmitted on the medium.
"f so, what values should be used, I was reading that DSCP 46 doesn't map correctly to WMM and as such I should consider something higher i.e. 48 or 56. Is this correct?"
What we found was that the WMM drivers in most wireless clients map EF46 to the video queue. Why? Because in 2003 the WiFi Alliance used 802.1p strict mapping rules and ignored Cisco's use of EF 46 for Voice. (There was one samsung phone that DID use WMM voice for EF 46!!)
So what should you do here? Well I recommend you not worry about it. Altering the standard 46 voice, 34 Video DSCP markings mean that you need to re-configure your wired network end-to-end. If you leave it as it is and the voice is mis-marked what will happen is that the heuristics you configured on the controller will re-map the voice traffic mis-marked with 34 back to 46 and send it out correctly. Your only potential congestion point is between the AP and the controller, one not likely to need QOS. (If it is then you could consider re-mapping to something higher)
BTW the only clients that send DSCP for Lync/Skype are windows devices with GPO applied all others send no DSCP to the wireless driver.
One last note: Heuristics is the best choice when you cannot use SDN API (Now called SDN interface) Microsoft, and me, recommend SDN API whenever possible. (Skype for business online does not YET support SDN API)
Hope this helped!
(How do I know all this? I wrote the guides when I worked for Aruba :-)
06-05-2015 01:17 AM - edited 06-05-2015 01:22 AM
What can I say :) thanks a lot, that certainly does help.
I do have one last question regarding this, well hopefully it is depending on your response, I think this is pretty straightforwarded. I've been reviewing some of our client machines, the majority of which are the Dell Latitude E7440. The wireless NIC install is the Intel ac-7260. I was reading the guide regarding WMM for this NIC and it suggests that you enable WMM as shown in the attached. I'm pretty sure the answer is going to be YES regarding this question, but as this would be a significant change (in terms of volume) to the client estate I want to be 100% sure. Do I need to change this from 'Disabled' to 'Enabled' or can I simply leave it 'Disabled'. I ask the question as when I have been tested configuring a GPo on my machine, following the Microsoft and Aruba guides, I can clearly see the packets being marked (DSCP) using Wireshark. This is obviously only showing my local machine though and not any contention I am faced with with peers connected to the same AP. It is my understanding that I should enable this feature as well in this card, and the equivalent in any other cards, to enable WMM on the local device to ensure the traffic is prioritised. Is this correct?
06-05-2015 07:25 AM
Is it a reasoanble assumption that if the WNIC supports/is certified for 802.11e, that WMM is enabled? I've been digging around the Intel site and can't find anywhere where it discusses having to enable this.
06-29-2015 12:22 PM
I was wondering if somebody is able to clear something up for me regarding this topic.
To be able to increase the probability of voice packets being prioritised WMM must be supported on the client and enabled in the Aruba SSID configuration. What I'm struggling somewhat with is how the client decides which WMM_AC to place traffic into. I can see the options for configuring the DSCP->WMM mapping but as I understand this to manage how the controller manages traffic coming into the system and going from the wired LAN to the wireless client. What I'm not sure about is how the client learns how to map this. I've checked the Intel documentation and raised a request with them for more information, and what I'm told is that the client learns this from the AP, which to me would suggest this is from the configuration applied in the SSID configuration and the four ACs. I plan to test this in my lab to see if I can see this in the beacon frame from the AP, but I wanted to check that my understanding was correct or if I'm well wide of the mark here.