Almost there on Wireless QoS

[shillings]

I think I understand most of it now but there are still some questions that I am struggling to answer:

1.) If WMM certification is the 802.11e amendments around QoS, then why does the Cisco 8.6 install guide state, "This UP is used to derive the over-the-wire priorities for non-WMM traffic". I thought the 8 UP levels are mapped to 1 of 4 access classes, and only work with WMM compatible clients?

2.) Ref downstream over-the-air traffic, I assume it doesn't matter if the wireless client supports WMM, or not, cos the prioritisation is performed by the AP alone, by using 4 access classes each with different random back-off time windows? Or, is some cooperation required with the wireless client?

3.) Ref upstream network traffic between AP and controller (ignoring fabric enabled for now), my understanding is that, in 8.0+, the packet's DSCP marking is mapped to the CAPWAP header. I've read conflicting info. Is this on a per-SSID basis (i.e. not very granular), or per-packet basis?

[Rasika Nayanajith · Accepted solution]

1.) If WMM certification is the 802.11e amendments around QoS, then why does the Cisco 8.6 install guide state, "This UP is used to derive the over-the-wire priorities for non-WMM traffic". I thought the 8 UP levels are mapped to 1 of 4 access classes, and only work with WMM compatible clients?

That's true, those 8 UP values are map to 4 different Access Categories. It is for WMM clients who are capable of differentiating its traffic based on those categories.

However early days of AireOS (7.x ) if non-WMM client send a frame, it will map to SSID configured QoS profile DSCP/UP value (that is if SSID configured with Platinum, those non-WMM client traffic get EF or UP=6). Therefore even non-WMM clients traffic get QoS treatment at the AP.

2.) Ref downstream over-the-air traffic, I assume it doesn't matter if the wireless client supports WMM, or not, cos the prioritisation is performed by the AP alone, by using 4 access classes each with different random back-off time windows? Or, is some cooperation required with the wireless client?

As per my  understanding, that is true. Packets get prioritized based on APs capability, if that supports WMM, it will have those 4 AC & voice traffic get priority over best effort for a given client. To do that no client cooperation required.

However if given client does not support WMM, it will not understand those QoS control information in wireless frame & might discard that info.

3.) Ref upstream network traffic between AP and controller (ignoring fabric enabled for now), my understanding is that, in 8.0+, the packet's DSCP marking is mapped to the CAPWAP header. I've read conflicting info. Is this on a per-SSID basis (i.e. not very granular), or per-packet basis?

This behavior is not per-SSID, it is a global setting. So it is per-packet basis. Here is a good video from Jerome, explaining those QoS changes introduced since 8.0

Qos: changes between AireOS 7.0 and 8.0

HTH

Rasika

*** Pls rate all useful responses ***

[shillings]

---

@Rasika Nayanajith wrote:

1.) If WMM certification is the 802.11e amendments around QoS, then why does the Cisco 8.6 install guide state, "This UP is used to derive the over-the-wire priorities for non-WMM traffic". I thought the 8 UP levels are mapped to 1 of 4 access classes, and only work with WMM compatible clients?

That's true, those 8 UP values are map to 4 different Access Categories. It is for WMM clients who are capable of differentiating its traffic based on those categories.

However early days of AireOS (7.x ) if non-WMM client send a frame, it will map to SSID configured QoS profile DSCP/UP value (that is if SSID configured with Platinum, those non-WMM client traffic get EF or UP=6). Therefore even non-WMM clients traffic get QoS treatment at the AP.

Great, makes sense, thank you

2.) Ref downstream over-the-air traffic, I assume it doesn't matter if the wireless client supports WMM, or not, cos the prioritisation is performed by the AP alone, by using 4 access classes each with different random back-off time windows? Or, is some cooperation required with the wireless client?

As per my  understanding, that is true. Packets get prioritized based on APs capability, if that supports WMM, it will have those 4 AC & voice traffic get priority over best effort for a given client. To do that no client cooperation required.

However if given client does not support WMM, it will not understand those QoS control information in wireless frame & might discard that info.

But even if the receiving wireless client doesn't support WMM and discards the marking, then it doesn't really matter, does it? Hasn't it already done its job and provided some basic form of prioritisation of over-the-air downstream traffic back to the wireless endpoint?

3.) Ref upstream network traffic between AP and controller (ignoring fabric enabled for now), my understanding is that, in 8.0+, the packet's DSCP marking is mapped to the CAPWAP header. I've read conflicting info. Is this on a per-SSID basis (i.e. not very granular), or per-packet basis?

This behavior is not per-SSID, it is a global setting. So it is per-packet basis. Here is a good video from Jerome, explaining those QoS changes introduced since 8.0

Qos: changes between AireOS 7.0 and 8.0

It's a bit late here now but I will watch this in the morning.

---

Many thanks for your thorough reply.

I have one more question if you, or anyone, is able to help.

4.) On a WMM-compatible wireless client, my understanding is that the application developer will set the DSCP marking appropriate to the type of application, but perhaps this is Apple devices only. Either way, how is the DSCP marking translated to an access class? I assume some form of mapping table. Do you know much about this side of things and whether or not vendors vary much in their implementation approach? I assume some, like Cisco, closely follow RFC 4594? The only bits I've picked up on this side of things is from Jerome's video on Apple Fastlane but that didn't quite cover this.

[Rasika Nayanajith]

4.) On a WMM-compatible wireless client, my understanding is that the application developer will set the DSCP marking appropriate to the type of application, but perhaps this is Apple devices only. Either way, how is the DSCP marking translated to an access class? I assume some form of mapping table. Do you know much about this side of things and whether or not vendors vary much in their implementation approach? I assume some, like Cisco, closely follow RFC 4594? The only bits I've picked up on this side of things is from Jerome's video on Apple Fastlane but that didn't quite cover this.

WMM UP value set by wireless drivers of the client. So it require those wireless drivers aware of those applications to correctly classify it in appropriate category. It is not done by Apple devices, other devices doing that. I do not know exact details how each vendor implement it.

In general, those application developers may not aware of those classification /priority requirement & not care to develop each applications to work well with those wireless drivers. So you will not see lots of devices correctly classifying UP values (sometime you see packets got some DSCP values, but UP set to 0)

Due to Cisco/Apple partnership, they have worked closely over last 2-3 years and able to detect certain applications to prioritize (again it is proprietary to Cisco/Apple) with some trust those are the application that in deed require QoS within enterprise.

I hope you had a look on some of CLUS presenations on this topic. Here is one from 2017 Las Vegas.

QoS Design and Deployment for Wireless LANs - BRKRST-2515

HTH

Rasika 

[Jerome Henry]

Thanks a lot Rasika for this great explanation! 

A few more nuggets, in case they might be useful...

When you client associates, its association request should contain the QoS capability field, this is how the AP knows that it is WMM. Then, downstream, the AP receives a packet from the wire, looks at the client destination, and if it is a WMM client, the AP uses the EDCA (WMM) procedure, sending frames with higher priority at statistically faster interval, etc. If the client is not WMM, then the AP switches to the DCF procedure (non WMM transmission method, with fixed DIFS). No UP value is then present in the header (and no frame is sent faster than others for that client, even if the wired incoming packet had a QoS value). 

Please also note, as Rasika mentions, that the UP value in the 8.x guide text refers to the QoS profile. If the incoming packet (from the wire) is untagged (no QoS), and the target client supports WMM, what should the QoS value be for that packet over the air? The QoS profile determines the marking for non WMM packets. This marking used to be the same as the profile (e.g. Platinum, i.e. UP 6, for Platinum profile), but this was back in the days where we would create SSIDs for traffic types (e.g. "voice" SSID), so we would assume that unmarked traffic for this type of SSID would also be voice, so should be marked the same. Since then, phones got themselves a screen and a web browser! So we don't do specialized SSIDs much anymore, and this unmarked traffic QoS value is configurable.

Last bit, inside the phone, the OS describes a socket call (as a programmer, for every packet you want your app to send to the network, you build a socket call, with an instruction to send 'somewhere'). Each call will be associated to a type, and each type to a DSCP value. For example, in iOS, SO_NET_SERVICE_TYPE_RV is Real time interactive media (gaming etc.), and is mapped to DSCP CS4. Then, inside the Wi-Fi driver, each DSCP value is mapped to a UP value (in iOS, CS4 is mapped to UP5). Each vendor is free to use their own map, but we published RFC 8325 a few months back to set a common map that starts being adopted by most m major vendors.

Please note that RFC4594 describes traffic categories (as in 'their sensitivity to jitter, loss and delay'), and suggest a DSCP marking for each of the 12 categories (we call this the 12 classes model), it does not describe the UP value (that's RFC 8325's job).

hth

Jerome

[Rasika Nayanajith]

Hi Jerome,

Thank you very much for such a detailed response. We are lucky to have someone like you who is happily share your knowledge on CSC forum time to time.

From response you have given, I learnt something new about WiFi which I did not know before.

Pls come back to CSC more regularly & share your wisdom.

KIT

Rasika

[shillings]

---

@Rasika Nayanajith wrote:

Hi Jerome,

Thank you very much for such a detailed response. We are lucky to have someone like you who is happily share your knowledge on CSC forum time to time.

From response you have given, I learnt something new about WiFi which I did not know before.

Pls come back to CSC more regularly & share your wisdom.

KIT

Rasika

---

Thank you both. This has been very helpful.

Sorry, but more holes keep appearing.

Did they use 3-bits for the UP value to future proof the standard? Can't think why else when there's only 4 access categories used by EDCF? And if the packet's DSCP is mapped to one of 8 UP levels by the WiFi driver, then does the same WiFi driver also map a second time from UP level to an access category? Or maybe I've misunderstood something along the way.

Also, if the client supports WMM but the application has not applied a DSCP marking to the packet then I assume the frame ends up in the AC_BK category, is that right?

I've watched the Jerome's AireOS 7.0 and 8.0 video and also had a read through some of the RFC. Not got to the Cisco Live video yet though :)

[Jerome Henry]

Hey Shillings,

When QoS was brought to WiFi, we started with other L2 technologies class models, and chose to align to 802.1, which in those days had an 8 class model, with 802.1D-1998 (UP 0 to 7). So 802.11 aligned to this model with 8 UPs, (among other reasons) to allow for an easier translation mechanism when moving packets from one medium to the other (802.1 to 802.11 for example).

Then, experimenting with the priority system, people from various companies found that 8 queues were hard to manage cleanly over 802.11 (keep in mind that we had only 802.11a and 11.b/g back then). There was not a big difference between these 8 queues, and a lot of collisions were messing up the priorities. So the 802.11 group reverted to 4 access categories. 4 classes gave enough differentiation between classes, and a reasonable compatibility with prior (non WMM) traffic type. 

Now, inside your device, you can arbitrate the 2 UPs inside a given AC (this is what Cisco does), so, for example, UPs 4 and 5 both get the same statistical access over the air, but the internal queue gives a statistical preference to 5 over 4, so overall you recreate a clean hierarchy system without disrupting too much the air space.

Now, that is where we stand today, With RFC 8325, we expressed that it is silly anyway to want to translate an L2 into another L2 without first looking at the global intent of the packet (L3 marking). Now that this is instantiated, our next job is to look at 802.11 to examine if 802.1D is the best reference point to start from (in my view, we should align with 802.,1Q-2014 instead, not much change from the outside, still 8 queues, but it would change a bit the internal sauce).

If the client is WMM, and the packet comes with no DSCP, then the policy depends of your QoS profile config. If you have Platinum, and you set the "non WMM" to best effort (which we recommend), the packet gets sent into the BE (UP0) queue. You would get BK only if you configured the 'non WMM' to background.

hth

Jerome 

[shillings]

Very interesting how these things evolve. 

Many thanks for your responses.

Regards,