Wireless Access

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

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,

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: 

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

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

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.

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.

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:

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

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,

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?

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. 

Jeff,

After reviewing some additional info, Strict Queueing is only performed for clients that are receiving transmissions. When looking at WMM Token queuing documentation it does state that Voice traffic bypasses the fairness algorithm alltogether (802.11n VRD).  

To be honest you may run into more issues by not prioritizing DSCP 46 on your wired side between the AP -> Controller, vs placing the traffic in WMM-AC 6. I am also seeing alot of Unified customers that dont beleive in using COS on their LAN side and they sware FIFO works just fine on 10 gig fiber back to their core.

In my mind any time I have small time sensitive packets that are being delayed or placed behind larger frames. This can cause additional overhead, which will lead to latency. 

My honest recommendation would be to run some bandwidth tests bi-directionally when using a voice call to provide a large payload on the radio to ensure voice quality sounds clear and optimal. (iperf can be used for bandwidth tests)

Jeff,

I was able to test the DSCP mappings with a windows machine via Local Group Policy. What the VRD states is correct with how the driver handles the DSCP to WMM mappings. 

I have included my test results below with GPO for UDP 50,000-65000 with both DSCP of 46 and 48. I also included my client-stats for WMM, and you can confirm that when the DSCP of 48 is applied, this is getting processed as WMM-AC 6 (VO). When using a DSCP value of 46 on the windows machine, I never actually see any Rx WMM-VO packets received, and this could cause packets to be dropped due to queing problems. 

Ill submit antoher post that actually breaks down the 802.11 and 802.3 frames for the capture with hard coding a DSCP of 48. 

Session-Details:

----------------

Src IP               Src Port           Dst IP          Dst Port  Codec  DSCP  Orig-DSCP  WMM-AC  Orig WMM-AC

------                    --------              ------           --------      -----       ----      ---------          ------          -----------

192.168.13.139  50042     x.x.x.x                55513     G711      46         48                 6                 6

show ap debug client-stats 74:da:38:8e:ac:c9 | include WMM

Tx WMM [BK]                      3

Tx WMM [BE]                      1

Tx WMM [VO]                      1095

Rx WMM [BE]                      5

Rx WMM [VO]                      439

Session-Details:

----------------

Src IP               Src Port           Dst IP          Dst Port  Codec  DSCP  Orig-DSCP  WMM-AC  Orig WMM-AC

------                    --------              ------           --------      -----       ----      ---------          ------          -----------

192.168.13.139  50054     x.x.x.x                50113     G711      46         46                 6                 5

show ap debug client-stats 74:da:38:8e:ac:c9 | include WMM

Tx WMM [BK]                      1

Tx WMM [BE]                      6

Tx WMM [VO]                      721

Rx WMM [BE]                      11

Rx WMM [VI]                      286

Here is the break down with recommeneded DSCP values coresponding to wireshsark captures. Only difference is I used a DSCP of 48 on client, where diagram is 56. 

Even though you are tagging as DSCP of 48, this should not have any affect on the LAN side QoS. The reason why is that the 802.11 frames between the AP and Controller (GRE Tunnel) will be updated with DSCP 46 when they are processed by AP. Once the traffic is received by the controller and converted to 802.3 frames it will adjust the DSCP of 48 to 46, before egressing controller. 

In the UCC Stats we would expect to see the following values in order for this to work correctly. 

DSCP: 46

Orig-DSCP: 48

WMM-AC: 6

Orig WMM-AC: 6

————— 802.11 frames (Controller -> AP) ——————

Internet Protocol Version 4, Src: 172.16.22.21, Dst: 192.168.67.101

    0100 .... = Version: 4

    .... 0101 = Header Length: 20 bytes (5)

    Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)

        1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)

IEEE 802.11 QoS Data, Flags: .p....F.

    Qos Control: 0x0006

        .... .... .... 0110 = TID: 6

        [.... .... .... .110 = Priority: Voice (Voice) (6)]

————— 802.11 frames (AP -> Controller) ——————

Internet Protocol Version 4, Src: 192.168.67.101, Dst: 172.16.22.21

    0100 .... = Version: 4

    .... 0101 = Header Length: 20 bytes (5)

    Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)

        1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)

IEEE 802.11 QoS Data, Flags: .p....F.

    Qos Control: 0x0006

        .... .... .... 0110 = TID: 6

        [.... .... .... .110 = Priority: Voice (Voice) (6)]

————— 802.3 frames (AP -> Controller) ——————

Internet Protocol Version 4, Src: 192.168.13.139, Dst: x.x.x.x

    0100 .... = Version: 4

    .... 0101 = Header Length: 20 bytes (5)

    Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)

        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)

User Datagram Protocol, Src Port: 50057, Dst Port: 53574

    Source Port: 50057

    Destination Port: 53574

————— 802.3 frames (Controller -> Firewall) ——————

Internet Protocol Version 4, Src: 192.168.13.139, Dst: x.x.x.x

    0100 .... = Version: 4

    .... 0101 = Header Length: 20 bytes

    Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)

        1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)

User Datagram Protocol, Src Port: 50057 (50057), Dst Port: 53574 (53574)

    Source Port: 50057

    Destination Port: 53574

————— 802.3 frames (Controller -> AP) ——————

* This is return traffic from the firewall in transit going back to client.

Internet Protocol Version 4, Src: x.x.x.x, Dst: 192.168.13.139

    0100 .... = Version: 4

    .... 0101 = Header Length: 20 bytes (5)

    Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)

        1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)

User Datagram Protocol, Src Port: 53574, Dst Port: 50057

    Source Port: 53574

    Destination Port: 50057