Wireless Access

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

Re: WMM and DSCP for voice, wireless and wired

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).  

 

WMM-Upstream_Downstream.png

 

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)

Justin Kwasnik | ACMX# 598 | ACCX# 638
Contributor I
Posts: 38
Registered: ‎01-03-2014

Re: WMM and DSCP for voice, wireless and wired

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

Justin Kwasnik | ACMX# 598 | ACCX# 638
Contributor I
Posts: 38
Registered: ‎01-03-2014

Re: WMM and DSCP for voice, wireless and wired

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. 

 

DSCP-Consideration.png

 

 

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

 

 

Justin Kwasnik | ACMX# 598 | ACCX# 638