Wireless Access

Reply
Occasional Contributor II
Posts: 31
Registered: ‎05-04-2011

WMM and DSCP for voice, wireless and wired

I've seen several posts on DSCP markings related to the translation to wmm categories.  I'm looking for a confirmation from anyone that has deployed voice on both wired and wireless, and how they handle integrating them both.

 

From reading technical articles from Aruba, the DSCP to 802.1d UP is mapped using the first 3 bits of the last 6 bits of the DSCP.  DSCP 46 = 0X2e =  0010 1110 = use 101 = 5

 

So a traditional wired voice tag of DSCP 46 is 802.1d UP of 5.  

Issue is that the 802.1d UP value of 5 is classified in wmm as video.  

7/6 is voice 

4/5 is video

 

Here are some behaviors I've seen with default settings on AOS 6.4

WLAN Phones tagged with wmm 6, DSCP 46 get remarked with wmm 6, DCSP 48

Incoming packets to the controller from wired devices with DSCP 46 get marked with wmm 5 

 

FYI... the above is using WLAN phones (not soft phones) on a Voice specific SSID.  WLAN phones being used tag the wmm value at the phone

 

This follows the conversion method above.

 

Other posts recommend just leaving the default settings.  I wasn't sure if they are considering the affect it has on wireless to wired.  

If there are custom mapping configurations to assign wired DSCP of 46 to queues on all switches in the network, why would it be good to have wireless using DSCP of 48 or higher?  I would think that in using that, you would need to have another special mapping on the wired side to handle DSCP 48 to the same queue as your using for DSCP 46.  Issue is that there are more switches to config than WLAN controllers.

 

I'm using the option in AOS 6.4 to create a custom DSCP to wmm mapping, assigning  DSCP of 46 to wmm Voice category.  This seems to work.  I can keep a simpler mapping on my wired, with no bad behaviors from wireless

 

Question is: given the standard of DSCP 46 for wired voice, why wouldn't the standard wireless AOS recommendation be to always override the defaults and create the custom mapping (as mentioned above)?

 

I don't see any kind of recommendation for any WLAN voice integration relating to these default mappings for any other vendor either. If I missed a post and this is already out there, my apologies. 

 

Regards,

Colin

 

 

 

 

 

 

 

 

 

Guru Elite
Posts: 21,018
Registered: ‎03-29-2007

Re: WMM and DSCP for voice, wireless and wired

Colin_King,

 

The short answer is it can be whatever you want it to be and the SSID profile gives you control over that in both directions.  Please see the Arubapedia Article here:  https://arubapedia.arubanetworks.com/arubapedia/index.php/Quality_of_Service#Scenario_3:_WMM-based_prioritization

 

You can also monitor the WMM packets that are being sent to/from the client by using the following command repeatedly:

(Aruba7005-US) #show ap debug client-stats <mac address> | include WMM
Tx WMM [BE]                      550
Rx WMM [BE]                      781
Rx WMM [VO]                      18

You can either rely on whether or not network actually is tagging the VOIP traffic to have the traffic be put in the correct queues, or you can use PEF ACLs to identify and tag the traffic.  We are dependent at minimum on the client sending the traffic with WMM for prioritization to work from the client to the access point.  If it is not tagged by the client, it is sent, received and processed at the same priority as data and will not be prioritized.  The link between the client and the access point by far is the most important portion where the traffic should be prioritized, because that is where delay can happen.

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor II
Posts: 31
Registered: ‎05-04-2011

Re: WMM and DSCP for voice, wireless and wired

Colin Joseph,

 

Thanks for the information.  Unfortunately it's opened up some issues that I'm still trying to validate.

 

Previously we have been sniffing wireless and confirmed that traffic both originating at the device and traffic being received was all being classified as voice.  (this was for any type of wireless-to-wireless or wireless-to-wired)

 

I assumed that the QoS control priority 6 (voice) was the equivalent of wmm VO.

Here is a portion of a screenshot from wireshark on a wireless packet capture: 

WiresharkQOS.png

 

Running some filters in wireshark showed that the vast majority >99% of packets during a call were being classified as 6 (Voice)  

 

However, using the command:

show ap debug client-stats <mac address> | include WMM

show_cmd_crop.png

on the same call, we see some Rx WMM [BE], for half the packets.

 

It's not clear to me what I'm seeing through this client-stats command.  It's not matching with the wireless packet capture.

 

The above device is a WLAN Cisco phone, so no other data expected.

 

 

Regards,

Colin King

 

 

 

 

Guru Elite
Posts: 21,018
Registered: ‎03-29-2007

Re: WMM and DSCP for voice, wireless and wired

Colin_King,

 

It is probably best that you either work with TAC or your Aruba SE on your specific issue, so that your whole issue can be addressed.  A forum is probably not the best place to get complete answers for such an involved issue.

 

If you want to make sure that the traffic is tagged correctly, you can do this with a wired and wireless packet capture inside and outside the controller.  The output of the command looks like the traffic is only being put into the voip queue in one direction, which could either be (1) a historical issue - the counter is for the total number of packets and not a single conversation, (2) DSCP is not being set outbounds, (3) or the counter itself is completely wrong.  A wired vs. wireless packet capture is probably the best way to ensure that everything is being set properly.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Aruba Employee
Posts: 19
Registered: ‎11-10-2015

Re: WMM and DSCP for voice, wireless and wired

Hi Colin,

 

I know this is an old thread but very relevant to me.  I'm trying to ensure that voice (skype for business, specifically) traffic associated with wireless clients is prioritized appropriately.  When I look at the SSID profile for my corporate wifi network, I see the following:

 

Wireless Multimedia (WMM)                         Enabled
Wireless Multimedia U-APSD (WMM-UAPSD) Powersave  Disabled
WMM TSPEC Min Inactivity Interval                 0 msec
Override DSCP mappings for WMM clients            Disabled
DSCP mapping for WMM voice AC (0-63)              46
DSCP mapping for WMM video AC (0-63)              24
DSCP mapping for WMM best-effort AC (0-63)        0
DSCP mapping for WMM background AC (0-63)         8

I confirmed via wireshark that voice traffic from Skype clients is indeed tagged with DSCP 46 so does the above confirm that when connected to this SSID, voice traffic tagged with DSCP 46 is mapped to the WMM voice queue and prioritized as best as possible?

 

Thank you.

Guru Elite
Posts: 21,018
Registered: ‎03-29-2007

Re: WMM and DSCP for voice, wireless and wired

Correct...in both directions....

 

To confirm it is happening, you would just have to do an AirCapture on that client, open in Wireshark and add a colum that tracks wlan.qos.priority:

wlan-qos-priority.png



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Highlighted
Contributor I
Posts: 38
Registered: ‎01-03-2014

Re: WMM and DSCP for voice, wireless and wired

jeff

 

You may want to reference the Lync/Skype VRD's as they do have alot of helpful info in regards to this. 

 

 

It can vary depending on the device support and application support for WMM. I personally use some applications on my OSX for UCC services where WMM and DSCP values are applied when traffic leaves my machine. I also use Skype4B with office 365, and I dont have WMM / DSCP values sent from my client to controller. Of course once the ALG detects the type of traffic and rewrites the values, they will be applied when egresing the controller going towards PBX, and also when returning to the client. 

 

Another helpful way to quickly look at the wmm/dscp values is by using the UCC commands to view the session-details. This does require the Lync / Skype ALG to be active and in use. I have found this is pretty accurate and can be used as a quick baseline. Since one of the purposes of leveraging the ALG's is to adjust / rewrite the 802.1p and dscp values. You should be able to tell what the origional and modified values are. 

 

show ucc configuration

show ucc client-info

show ucc call-info cdrs (show a list of the recent calls)
show ucc call-info cdrs cid 16 (review details on a specific call)

Under the session-details, you will see an Orig-WMM and Orig-DSCP, these will be the values that are coming from the client (Client -> AP -> Controller). Once the traffic arrivies at the controller, it will be re-written according to your setup. When traffic is being sent from the controller back to client, it will utilize the values that are being adjusted via the ALG. If you are not using the ALG, traffic will have to be rewritten by the ACL's. 

 

Once you have confirmed how your markings are applied and in each direction, you should have enough information on whats required to enforce a proper COS policy on the wired side. In the case that your egress traffic from client -> controller is not marked. This traffic will not be honnored in your data network from the AP -> controller. Only when saturation occurs you may have the potential to disrupt some egress voice traffic.

 

In windows deployments of Lync / Skype, its also recommended to apply a GPO to ensure the packets are being tagged with the necessary DSCP values when leaving the client machines. 

 

 

Justin Kwasnik | ACMX# 598 | ACCX# 638
Aruba Employee
Posts: 19
Registered: ‎11-10-2015

Re: WMM and DSCP for voice, wireless and wired

[ Edited ]

Thanks Colin.  I'll consider your "correct" to be definitive for my purposes.  

Aruba Employee
Posts: 19
Registered: ‎11-10-2015

Re: WMM and DSCP for voice, wireless and wired

Justin,

 

Just fantasic information.  Using the ucc commands you mentioned, I see the following:

DSCP  Orig-DSCP  WMM-AC  Orig WMM-AC
----  ---------  ------  -----------
46    46         6       5

This tells me that the default mapping of DSCP 46 is WMM 5, which would be video.  However, the mapping in the SSID profile remaps it to WMM 6, which is voice.

 

Is that correct?

Contributor I
Posts: 38
Registered: ‎01-03-2014

Re: WMM and DSCP for voice, wireless and wired

Jeff,

 

Your more then welcome, glad this was able to help!

 

If you really want that 802.11 capture and have issues with doing this on the client device. You can get a very simliar output from the controller packet capture. Of course there could be a difference of a couple frames via the air capture vs controller datapath, although its at least a start.

 

packet-capture datapath mac 00:00:00:00:00:00 all

tar logs (export logs.tar after and review the datapath captures)

 

In response to your question with recieivng WMM 5 from the client. This is typically due to how the application is egressing traffic from the device. The Lync VRD does cover different setups with what to expect from Heuristic Mode, API, or WMM only. 

 

When referencing API mode and DSCP Considerations Pg 37, it does talk about how the wireless driver interprets DSCP and converts to WMM-AC. It does note that the DSCP values of 48-63 do get mapped to VO, where as 32-47 gets mapped as VI. It is also recommended to adjust a group policy for that device to be a DSCP of 56, in order to overcome this problem. 

 

Also note that only the WMM-AC value of 5 could only affect traffic going from Client -> Controller when saturation occurs. Once traffic is reclassified by the controller and its sent back to the client, it will be classified as WMM-AC 6.

 

The VRD for 802.11n has a great overview on how the QoS tokens are used. As long as the WMM VI queue is not oversaturated, I would think you may be able to get away with leaving WMM at 5. It will be much more efficient at 5 vs 0. 

 

In most cases end users are mostly downloading, so having the WMM vlaues corrected by the contorller will be most helpful in this situation. There are some cases that end users are performing high upload speeds, although its going to be much smaller groups that are sending large amounts of data vs downloading large amounts of data. 

Justin Kwasnik | ACMX# 598 | ACCX# 638
Search Airheads
Showing results for 
Search instead for 
Did you mean: