CUWN QoS Configuration and CAC (TSpec)

[Johannes Luther]

Hi Wireless Experts,

hopefully someone can enlighten me regarding wireless QoS and usage of the Voice (AC_VI / Platinum) and Video (AC_VO / Gold) queues.

In your deployments - especially when using smartphones and laptops for voice (e.g. Jabber, Skype for Business etc.), do you enable "Admission Control (ACM)" in the 802.11a/b global radio settings? If yes, the beacons of your WLAN tells the clients that the usage of the voice and video queue is only allowed when using proper CAC techniques (TSpec, ADDTS).

802.11e but not TSpec / ADDTS capable clients should NOT use any voice or video WMM queue as stated in the Mobility Design Guide.

TSpec support is not required by clients. But when a WLAN is configured with call admission control (CAC) for either audio or video that client that is not in support of TSpec is must send the audio and video packets at a Best effort QoS level

I doubt that any Linux, Windows, Android, OSX, iOS client perform proper CAC using TSpec.

Question: Is this correct?

So enabling CAC in the WLC will likely harm the overall voice and video quality in a WLAN, because the clients will likely use the best effort queue

Question: Is this correct?

Bottom line: Enabling CAC makes only sense if you have clients supporting TSpec. As soon as there is one device type, requiring access to the voice or video WMM queue, CAC must be disabled in order to allow this client access to the WMM queue.

Question: Is this correct?

Or do clients (e.g. Windows) just ignore this setting and send frames with the configured QoS level configured in the application / operating system?

How do you deploy your current voice and video deployments? Do you enable CAC or not?

I remember darkly, that a few years ago, enabling CAC was a best practice for voice deployments. I guess they had only Spectralink or Cisco handhelds in mind.

Thanks for your thoughts on this.

Best regards

Johannes

[Rasika Nayanajith]

If you refer this document, you should get more clarity on what is Cisco's recommendation for apple devices. CAC is enabled for voice traffic

http://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-3/Enterprise_Best_Practices_for_Apple_Devices_on_Cisco_Wireless_LAN.pdf

When enabling the fast lane QoS option for a WLAN, the following automatically happens:
1.The 5 GHz and 2.4 GHz networks are temporarily disabled (to allow for the configuration below
to be activated)
2. Non-WMM and multicast traffic is set to Best Effort in the Platinum QoS profile
3. UDP traffic bandwidth limitation is set to 0 (no restriction) in the Platinum QoS profile
4. The Platinum QoS profile is applied to the configured WLAN
5. The Fastlane EDCA profile, matching the recommendations of the new revision of the 802.11
standard, is activated for both hands.
6. Wireless CAC (ACM) is enabled for Voice traffic (for both bands), based on load calculation.
50% of the bandwidth is allocated for voice traffic, and 6% for roaming voice traffic
7. DSCP is trusted upstream, and a custom DSCP-to-UP map is configured, as displayed in figure
9 above.
8. The fast lane feature is enabled on the WLAN. This feature is used in the context of fast lane
profiles explained in the next section.
9. An AUTOQOS-AVC-PROFILE AVC profile is created. This profile ensures that well-known
applications (including voice and video traffic from applications such as jabber, Cisco phones,
Webex, Lync) are marked for QoS appropriately.
10.The 5 GHz and 2.4 GHz networks are re-enabled

Based on above, you should keep CAC enabled for voice services in your wireless environment.

How do you deploy your current voice and video deployments? Do you enable CAC or not?

In my production network, I have enabled CAC for voice traffic. Also ensure only WMM capable client connecting to WLAN (by WMM required under QoS setting). My understanding is "if client is WMM capable, it should support TSpec"

HTH

Rasika

*** Pls rate all useful responses ***

[Johannes Luther]

Hello Rasika,

thank you for your detailed response!

I'm still very unsure about this and will set this up in a lab. In a quick test I discovered, the following:

(WLAN 802.11e/WMM values set with nping in Windows).

Band is CAC (Voice) disabled:

ACM (Access Control Mandatory) is not required in Beacon frames.

nping set with DSCP 48, because Windows uses an incorrect DSCP to UP mapping table.

- Client is not sending a TSpec ADDTS request

- ICMP ping is sent with 802.11e value of 6 (AC_VO)

--> Good

Band is CAC (Voice) enabled:

ACM (Access Control Mandatory) is required in Beacon frames.

nping set with DSCP 48, because Windows uses an incorrect DSCP to UP mapping table.

- Client is not sending a TSpec ADDTS request

- ICMP ping is sent with 802.11e value of 5 (AC_VI)

Not so good - The usage of the Platinum class is not allowed obviously.

My testlab is not very good at the moment and I need some time to do a proper test.

But I guess that enabled Voice CAC will disallow clients not sending TSpec ADDTS requests using the Voice queue. I doubt that Windows, OSX etc. voice applications perform proper TSpec signaling.

I guess you're right... WMM clients must support (and understand) TSpec - but the clients do not necessarily send out ADDTS signaling requests.

Until I tested this in very details my takehome message is to disable CAC if you are unsure whether the clients support proper ADDTS signaling.

I have other sources as well:

Breakout session BRKRST-3015 (QoS Design and Deployment for Wireless LANs)

(Berlin 2016 / Robert Barton)

Voice CAC no longer functions [this is only theoretical – TSpec never
gets in Windows or OSX anyway]

You're quoting the Apple guide above, stating that CAC is enabled for voice traffic, but I found another source stating:

This fast lane enables several beneficial functions:

Your WLC QoS configuration is optimized globally to better support real-time applications such as voice and video.

Apple iOS devices can send upstream voice traffic without the requirement to perform WMM TSPEC/TCLAS negotiation. The infrastructure will honor the voice marking for these devices.

https://dcloud-cms.cisco.com/demo/cisco-fast-lane-integration-on-apple-ios-v1

Also your reference (Apple integration guide) states:

A practical result of enabling ACM with fast lane is that stations performing ADDTS exchange, and devices running iOS 10 sending voice traffic (even if they do not perform ADDTS exchange), can benefit from the UP 6 queue for voice traffic. However, other stations that do not perform ADDTS will have to use another queue (typically Video or Best Effort). In a congested environment, this configuration may result in lower performances for these stations.

This is exactely what I saw in my captures. My station does not perform ADDTS and with enabled CAC, the station does not use the UP value of 6.

Also from what I understand from wireless QoS you might run into problems even if you're not in a congested network. The backoff CWmin, CWmax values are higher in the Video queue. So non-ADDTS devices are handled not as good as ADDTS devices.

The Jabber integration guide is also not stating anything regarding TSpec or CAC.

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/Jabber_in_WLAN/b_Jabber_in_WLAN.html

Again - this is only a theory of mine... but I'm pretty sure that enabled CAC is hurting non-ADDTS devices requiring access to the voice queue. For Apple in combination with "FastLane" this might be a exception because of "FastLane" black magic.

My bottom line is, that in a mixed Windows, Apple, Android environment with voice requirements, I'll disable CAC. These devices do not perform ADDTS and cannot use the voice queue as the consequence.

Please share your thoughts :)

[Rasika Nayanajith]

I think you have done detail research and found lot of valuable info :)

Thanks for sharing all of those, very useful.

I hope someone from Cisco can clarify this bit more in detail until update for those design guides come.

HTH

Rasika

[Jerome Henry · Accepted solution]

A quick word on support of Michael's comments... :-)

Johannes, please make sure to distinguish upstream from downstream, and Voice from Video...

Upstream vs downstream: you are right, Microsoft incorrectly applies the same L3 to L2 QoS mapping regardless of the transmission medium, so EF gets UP 5 or CoS 5. I write "incorrectly", although they would debate that point. But until the whole world changes the recommended mapping, including 802.11, Voice in wireless should be UP 6.

This means that if your STA does not do TSPEC (ADDTS request) for its upstream traffic, it is not allowed to send in the UP 6 queue if ACM is enabled. iOS 10 are an exception, because we know that what they send in UP 6 is indeed going to be voice traffic (and not a "home made" marking for a bittorrent app ;-)).

If the STA still sends in UP 6 (without ADDTS, and despite ACM being enabled), this is a violation of 802.11, and we respond with return traffic marked down to BE.

Okay. Now if your Windows machine sends upstream traffic with EF/UP5, it will not fall into the ACM restriction. The return traffic will be marked according to your QoS policy, so there is no issue there.

In general, specialized phones (Cisco, Vocera etc) do TSPEC. General use stations (laptops, tablets, etc) do not do TSPEC, simply because each app developer is unable to provide clean description of wifi TSPEc requirements for their voice flows...

So in my opinion, your policy should depend on your voice device population. One risk without ACM, like Michael pointed out, is that if you have too many calls in your cell, all calls suffer, not just the "additional ones", so it is healthy for voice quality to have a mechanism to limit the number of calls in the cell. If none of your clients do TSPEC, then of course ACM is not very useful. If you have a mix of iOS 10 devices, or specialized phones, and more general devices, ACM is going to protect part of your cell airtime, forcing the non-compliant devices to get into UP 5 (which is not as good, but still good).

Voice vs video:

Almost no device (I write "almost", but in fact I have never seen any) supports ACM for Video traffic. We have the option in the WLC because it is present in 802.11 and WFA,  but I do not see value in turning it on.

So if you use ACM for Voice (I turn it on in all my networks where iOS or specialized phones are present, even if I have a large population of Windows machines with Skype), the other machines have a lot of space to use the Video queue...

hope this helps

Jerome

[Rasika Nayanajith · Accepted solution]

Hi Jerome,

Thank you very much for precise and detailed insight about ACM.

Please check this CSC forum time to time and provide your expert advice. Many of us (including me) learning a lot from this sort of responses.

Rasika

[Jerome Henry]

Thank you Rasika, will monitor more!

Take care

J

[Johannes Luther]

Again, you are great guys. I never dreamed of getting such a detailed answer to my question. Thank you so much for sharing!

Talk to you soon (when my next silly question arises)

Cheers

Johannes

[Rasika Nayanajith · Accepted solution]

Hi Johannes,

 I never dreamed of getting such a detailed answer to my question. Thank you so much for sharing!

I agree with you. Jerome's & Michael's responses to this thread are invaluable.

You have taken great effort to test these thing in proper way (capturing packets, go through most of cisco documents,etc). If someone invest their time and effort like this to study, you will get rewarded by this sort of responses.

So take all these as result of your hardwork.

Rasika

[Johannes Luther]

Hey Jerome,

by the way - RFC 8325 is now in the standards track. I guess you are aware of that ;) (congrats for the great document by the way). So maybe MS will follow this RFC in a few years :)

[dcpolgar1]

Looking for some assistance in troubleshooting an issue I am having with a Android tablet on our plant floor. Seems when the WiFi is connected to our Wlan it keeps giving a log message VoIP Call Failure: '40:83:xx:x:xx:xx' client, detected by AP on radio type '802.11a'. Reason: 'Call failed: TSPEC QOS Policy does not match'.. on our WLC

I have located the device and tried turning off the hangout feature without any success. I ran a debug on the mac address and everything is setup correctly. The device is connected to the correct Wlan and it is showing it connected to QoS as Silver. This Wlan is setup for all of our scanners and is 5GHz only. We have another tablet that is the exact same model that doesn't cause this issue.I am not very Android savvy so any help would be appreciated. Looking for a way to shut off the app on this tablet that is trying to do the calling or making a change on the Wlan to resolve the issue.

I have added a portion of the debug that shows it connecting to the correct QoS. 

*Dot1x_NW_MsgTask_4: Feb 14 14:00:18.102: 40:83:xx:xx:xx:xx  RUN (20) Reached PLUMBFASTPATH: from line 6761

*Dot1x_NW_MsgTask_4: Feb 14 14:00:18.102: 40:83:xx:xx:xx:xx 10.x.x.x RUN (20) Adding Fast Path rule

  type = Airespace AP Client

  on AP 1c:xx:xx:xx:xx:xx, slot 1, interface = 13, QOS = 0

  IPv4 ACL ID = 255, IPv6 ACL ID = 25 40:83:xx:xx:xx:xx 10.x.x.x *Dot1x_NW_MsgTask_4: Feb 14 14:00:18.102: RUN (20) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 15206, IntfId = 13  Local Bridging Vlan = 40, Local Bridging intf id = 13 40:83:xx:xx:xx:xx *10.x.x.x: Feb 14 14:00:18.102: RUN (20) Fast Path rule (contd...) AVC Ratelimit:  AppID = 0 ,AppAction = 0, AppToken = 15206  AverageRate = 0, BurstRate = 0

[Michael Combs · Accepted solution]

Hi Johannes,

It all comes down to your specific wireless network, diversity of client devices, and use-cases of interest to your particular organization in question. Only in taking all of these factors and potentially more into careful consideration, can one say thereafter whether CAC is best left disabled or enabled accordingly.

Call Admission Control (CAC) in the wireless sense invokes Admission Control Mandatory (ACM) for the particular access category (AC) in question as you detail. In your case and for our example, that would be the voice AC (AC_VO) which is traditionally mapped to the metallic Platinum QoS profile on the AireOS WLCs. The method by which ACM is negotiated is indeed via ADDTS action frames and similar which include TSPEC and TCLAS parameters, to ultimately control both access to and use of AC_VO. This is an additional means of preserving capacity for calls and reserving bandwidth in AC_VO for mission and/or business critical communications and similar real-time applications. Though this is mechanism is of course in addition to, and by no means a substitute for proper wireless network design that takes both coverage and capacity into account.

If your primary voice deployment/use-case involves dedicated and purpose built VoWLAN phones (i.e. Cisco 7925G or 8821, Ascom i62/Myco, SpectraLink 84xx, etc.) which support CAC/ACM then enabling it is often a good option as it reserves the voice access category as detailed above. Thereby ensuring that less important applications that still mark their traffic as UP 6 / EF (46) or similar do not detract any more airtime and bandwidth than is absolutely necessary from those devices or applications deemed more critical in a given environment.

If instead the primary voice applications in use are soft clients running on a mix of various devices, whether Android, iOS, macOS, Windows laptops, or a combination of most or all the above. Then you are correct, there has always been a disappointing lack of client support for ADDTS/TSPEC/TCLAS, etc. If these voice soft clients are considered mission/business critical then given the lack of support for CAC/ACM in this instance, the decision is apparent that CAC should likely be disabled in this particular environment.

Though the 802.11e standard upon which WMM is based does indeed include these mechanisms. As with most things, client manufacturers often pick and choose what they wish to actually support and this is a prime example of an aspect that rarely made the cut (debatable as to the validity of those decisions from case to case). It should be noted that CAC is not unique to wireless (merely the mechanisms by which it operates), but can also be implemented for preserving and controlling call bandwidth for WAN links, etc., as well.

Fastlane introduced in AireOS 8.3 and iOS 10 on Apple devices introduces greater flexibility to extend the benefits of CAC to additional mobile devices that don't implement ADDTS but can still be granted access to the voice AC as needed. Given the granularity of QoS control that Fastlane introduces for compatible iOS 10 apps and use cases.

TL/DR = one size does not fit all. CAC/ACM can be utilized to great effect in some environments, but might not add as much value or even be a hindrance for others based on their device types and capabilities, and corresponding use cases.

/Michael

[Rasika Nayanajith]

Hi Michael,

Thank you very much for the in detail response to clarify this.

Regards

Rasika

[Johannes Luther]

Hi Michael,

thank you for the detailed response. I'll consider this in my deployments.

Most of my deployments have mixed clients in the corporate environment - most of them don't perform ADDTS... so I'll stick with disabled CAC (but required WMM to get rid of those old slow trucks on the road).

Upstream (from the wireless client) for non-ADDTS clients

However with Windows clients and enabled Voice ACM you won't see any difference whether ACM is enabled or not. Windows (7,8,10) and my Linux client here always mark Voice (DSCP EF) traffic with an UP of 5 (AC_VI queue) :(

If you want to enforce UP 6 (AC_VO) a DSCP marking of CS6 is required

--> So upstream is not really relevant, because most clients use UP5 anyway

Downstream (to the wireless client) for non-ADDTS clients

With enabled Voice ACM: UP is set to 0 (Best effort) - therefore voice traffic gets a really, really bad treatment (no TXOP, high AIFSN, high and large CW).

With disabled Voice ACM: UP is set to 6 (AC_VO) for voice traffic (EF). So voice get's treated the correct way (at least in one direction - the one we can influence as networking guys :) )

The problem with all the deployment guide and technotes is, that that simple behavior is described at different places with different detail level and sometimes different information.

For wireless pros like you guys, this is quite simple and understandable. But a normal networking guy, who needs to deploy Skype or Jabber this is a nightmare.

I guess it's time for a new "Voice over Wireless Design Guide" (the old 4.1 was/is brilliant) covering all these new clients and deployment best practices.

Anyway - I'm getting lost again in babbling .... thanks for helping to bring light into this topic!

Have a great weekend

Joe

[Michael Combs]

Hi Johannes,

Sounds good, and keep in mind that ACM can be implemented for both the voice (AC_VO) and video (AC_VI) access categories (though for same considerations, likely wouldn't want to enable for AC_VI in your use-case).

You are also correct that the QoS mappings from DSCP to UP has been inconsistent among a large number of wireless infrastructure and client vendors alike. Thankfully, this was addressed in the latest IEEE 802.11-2016 EDCA specification. By enabling Fastlane (even in the presence or absence of iOS 10 clients) on a WLC running AireOS 8.3 or later, you implement these latest EDCA parameters on the WLC. Naturally, iOS 10 clients also support them. Though the uplink UP mapping behavior will still vary (sometimes wildly) for other client devices, but hopefully in time these manufacturers shall also implement the latest EDCA specifications.

The 4.1 Voice over Wireless Design Guide is indeed long in the tooth, though still applicable, and was drafted at a time that the overwhelming majority of VoWLAN use-cases involved purpose built wireless IP phones. There has been a more recent, similar document in the form of the Real-Time Traffic over Wireless LAN Solution Reference Network Design Guide (say that three times fast). I've provided a link to the WLAN QoS section of that document below, which touches upon ACM/CAC/TSPEC and other considerations:

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/RToWLAN/CCVP_BK_R7805F20_00_rtowlan-srnd/CCVP_BK_R7805F20_00_rtowlan-srnd_chapter_011.html

One final comment on the use of CAC/ACM is to consider that preserving bandwidth in the AC_VO is to not only ensure the highest number of possible calls (depending on local environmental factors, etc.) are preserved per AP radio cell, and that the quality of these calls is preserved as much as possible therein. Also consider that in doing so you also help reserve sufficient bandwidth for a E911 call or similar as well, even if the AP radio cell is saturated with client activity. Again, simply an additional mechanism and by no means a substitute for proper RF network design that properly addresses both coverage and capacity in a given environment.

However, due to the disappointing lack of ACM/TSPEC support among most client vendors today, outside of purpose-built VoWLAN wireless IP phones and similar. It is simply not in the cards for a number of voice deployments that rely upon soft clients on a diverse suite of client devices, for all of the considerations you and I have discussed and more.

/Michael