With so many applications going to the cloud and not operating inside your data center, you should consider how that traffic is being handled throughout your network. Are the important packets getting to go first? Are your video calls getting priority but not enough to overwhelm the system? And, are you ensuring that all the rest of the traffic doesn’t create other issues?
If you’re thinking to yourself that this all sounds like Quality of Service (QoS), you’re right. Networks have used QoS for years to ensure that traffic is getting where it needs to be going in the order that it should be getting there. QoS is pretty universal now. However, if you’re a wireless engineer you may have found some issues getting everything matched up. That’s because 802.11 has User Priority (UP) instead of DSCP, which is what is used by wired networking.
Fear no longer! Rasika Nayanajith has written up a great post about RFC 8325 to help. It’s almost four years old at this point but it does help bridge the gap between 802.11 UP and DSCP. The diagrams alone are worth reading the post but Rasika does a great job of covering the details behind how things line up. Here’s a great example:
When it comes to WiFi, you will have limited QoS capabilities. Primarily you classify traffic into 4 different Access Categories (Voice, Video, Best Effort & Background). When a QoS capable STA/AP transmit a data frame they will include QoS control field in WiFi header that include TID (Traffic Identifier) field. 3 bits of that field known as User Priority (or UP) value and determine the priority a WiFi frame get over the air. Since WiFi got 4 different traffic classes, two UP values map into each Access Category. Note that UP value 0 map to Best Effort (BE) in order to treat packet with no QoS marking with Best Effort Priority.
Read more of this great blog and make sure you bookmark it here: RFC 8325 – WiFi QoS Mappings
Thank you Tom for sharing my blog post and the appreciation given.
Rasika