Late 2015 I joined a task force group at a customer. The task force was created to troubleshoot global performance issues with Microsoft Lync. The customer is mainly using wired connections and the task force had already solved 10-15 findings to raise to overall user experience using Ms-Lync.
One of the findings included QoS. The wired QoS policy was aligned with Microsoft and Cisco white papers to use GPO to assign specific UDP port ranges with the DSCP value 46 and assign med MS-Lync audio to utilize this port range.
Both Microsoft and Cisco’s best practices states that DSCP EF (46) is the way to go.
Unfortunately no one bothered to think the wireless part into their solution of the missing QoS for Lync.
Microsoft has been so kind to hardcode their DSCP to 802.11e UP value into the OS. And they decided to do it wrong compared with they own best practice white paper. As Microsoft is using the first 3 bits of the 6 bit field, the DSCP decimal value of 46 (101110 in binary) gets mapped to UP 5 (101 in binary). So DSCP EF Voice Best Practice traffic is placed in the *brumroll* Video Access Category.
So if you do everything by the book your QoS will be broken. I still can’t figure out why Microsoft can’t include the mapping in a Registration Database value.
Cisco wants you to use AVC to match each packet to a signature and remark the packet to DSCP EF. This ensures that the QoS is only broken from the client to the AP and from the AP to the WLC (when using central switching).
Upstream the packet leaves the client with the DSCP EF and User Priority 5. When the access-points get a UP 5 frame it creates a CAPWAP packet with the DSCP decimal value of 34 and forwards to the WLC. At the WLC the CAPWAP is removed and the original IP packet with a DSCP of 46 is processed. The AVC engine will remark the packet as it is a match to ms-lync-audio to DSCP … 46 … (same same).
Downstream the QoS looks great. DSCP EF from the wired side hits the controller and the ms-lync-audio packet is remarked to … EF using AVC. When leaving the WLC the CAPWAP packet remains EF and at the AP the DSCP EF mappes to the Voice Access Category.
Can this be solved? Sure, but it ain’t pretty. So lets go ahead and kill best practice.
There is really only one system that can’t be modified. The Windows OS. So we need to adapt everything to fit around that. We want the Windows machine to map the audio packet to UP 6 and Voice Access Category. To do so we need to use a DSCP value of 48 or higher. Using the 48 would work fine, but as we might want to match the audio packets and only the audio packets using the DSCP value 48 might not be optimal. My idea was to go with 51. I know, I know. It isn’t a pretty even normally used value. There is no AF or EF. But again it is just a combination of bits.
The value will only be used on the clients in their Lync to UDP ports to DSCP setting.
Upstream flow using DSCP 51 on the client:
When the packet leaves the client using DSCP value 51 the default Windows map will ensure that it gets a UP 6 and hits the Voice Access Category. When the frame hits the access-point with the UP 6 the access-points forwards it in a CAPWAP packet with the DSCP of 46. When the CAPWAP packet hits the WLC the CAPWAP is decapsulated and the original audio packet with the DSCP 51 is left. Before forwarding this to the wired side the AVC engine matches the packet as a ms-lync-audio packet and remarks the 51 -> 46. The DSCP EF order is restored.
The downstream flow will use DSCP 46 from end to end as normal. Remember that only the end clients know about the 51.
So is everything great? Well, not quite. What happens when a client uses wired. Then we don’t have the AVC engine to do the remarking. The solution could be to do DSCP mutation/remarking on all access switches in the network. Simply match 51 and rewrite to 46. This is why 51 is a great value. No one else uses it.
So this the customer implement the solution. No. They decided to reserve the Voice and Video Access Categories to the Lync audio and send video as best effort.
It worked perfectly fine on white board.
Will there be a more elegant solution in the future? Hopefully. The 802.11u protocol includes a feature to dictate the DSCP to UP mapping per client. In other words the Infrastructure device (the access-point) can inform the STA (client) of where each DSCP should be mapped to. Right now the 802.11u client support seems fairly limited, but there is stil hope.