ZNDP 035 – Wireless QoS Design with Nick Russo

Cisco, Demystifying The Roles, Network Community, Network Design, Podcast, ZNDP One comment

Podcast: Play in new window | Download

Wireless QoSThe Iconic Mr. Nick Russo joins us once again for today’s topic of Wireless QoS Design! Today Nick and I talk about QoS, RFC 4594, Wireless QoS, RFC 8325, WMM, UP values, DCF, TXOP, Wireless High Density, Wireless High Demand, and much more!  We also highlight an issue around vendor endpoints not marking Wireless Voice traffic the way you would expect!  Hold on to your seats folks, we are live in 3…2…1!!!

Guest Expert: Nicholas (Nick) Russo

Today’s guest Expert has become an icon within this industry. He holds Cisco Certified Design Expert (CCDE), and two Cisco Certified Internetwork Expert (CCIE), one in Routing & Switching and the second in Service Provider.  He is a great friend and Marine Brother!  This is now Nick’s fourth podcast episode with Zigbits so he should be well known by now! The other ZNDP episodes that Nick has been involved in are listed below:

Before Wireless QoS, there was QoS!

The purpose of QoS in general is to provide the proper treatment required by an application that results in a positive user experience and business outcome. This typically involves flow classification/marking, SLA compliance, traffic conditioning, and more.

With QoS you can think outside of the box.  Don’t be hampered by a Legacy thought process that Video / Voice traffic always has to be in the Priority Queue or Low Latency Queue. Business requirements and outcomes will always dictate what application is the most important within the organization and it might not be Video or Voice.

RFC 4594 Summary

Sections 3 and 4: It’s an easy read and very important for network designers of any stripe.

1. Network Control: Routing protocols and other traffic holding the network together
2. Signaling: Interactive voice/video signaling (call setup, forwarding, etc)
3. OAM: Network operations: SNMP, SSH, RADIUS, TACACS, Netflow
4. Voice: Very sensitive to latency, jitter, and loss
5. Broadcast Video: Typically has application level buffering. Includes live video feeds, IPTV, CCTV
6. Real-time interactive: Telepresence; similar SLA as VOIP with a little bit more latency but less loss
7. Multimedia Conf: Bidirectional software media, like webex
8. Multimedia Stream: Video on demand, Youtube/Netflix videos, unidirectional video viewing
9. Transaction Data (LL): Interactive foreground applications; users are expecting a response (ERP, CRM)
10. Bulk Data (HT): Non-interactive background applications; database sync, backup jobs
11. Best Effort: Most applications fit here, anything unclassified
12. Scavenger: Explicit low priority, video games, peer to peer traffic

Wireless Multi Media (WMM)

IEEE 802.11e adopted by the Wifi alliance as Wireless Multi Media (WMM). There are four access categories listed below:

  • Background
  • Best effort
  • Video
  • Voice.

Each AC has two specific user priority (UP) values associated with it. These are similar to Ethernet class of service (CoS) in wired networks.

802.11e UP

  • UP 1 – Background (AC BK)
  • UP 2 – Spare (AC BK)
  • UP 0 – Best effort (AC BE)
  • UP 3 – Excellent effort (AC BE)
  • UP 4 – Controlled Load (AC VI)
  • UP 5 – Video (AC VI)
  • UP 6 – Voice (AC VO)
  • UP 7 – Network control (AC VO)

Wireless QoS operation is focused on reducing the likelihood of collisions for high priority traffic. This leads to fewer retransmissions, less wasted time, and improved application performance.

Wireless Traffic is still Half Duplex, and so its a limiting factor on bandwidth / performance. This is why its imperative to have Wireless QoS Implemented on your most critical traffic / Application

Distributed Coordination Function (DCF) at a high level

1. Wait some fixed amount of time (DCF interframe spacing, DIFS)
2. Select a random backoff timer between 0 and the minimum contention window (CWMIN), and wait that time
3. When timer reaches zero, transmit
4. If ack is not received, double the contention window time (expontential backoff approaching CWMAX) and try again

Wireless QoS proposes a variable arbitrated IFS (AIFS) strategy. Higher priority access categories (there are 4) will have shorter AIFS. Additionally, higher priority classes will have smaller CWMIN and CWMAX, allowing them to almost always beat lower priority traffic for wireless media access.

Think of a conference call where everyone but your manager has to wait 2 seconds to talk. Your manager only has to wait 1 second to talk, thus ensuring that if your manager has something to say he/she will say it first and foremost.

TX Opportunity (TXOP)

Last, TX opportunity (TXOP) allows a station to send multiple frames without DCF cycles in between each one. Background and BE TXOP are 0, meaning they only send 1 frame at a time. Video is highest, primarily because voice is benign and predictable, video is greedy and bursty. VOIP sampling is typically 20 ms or so and doesn’t need a large period of time to transit.

Wireless High Density and High Demand

From a Wireless Video design perspective it is paramount to make sure you have enough bandwidth available to support it. This then gets into Wireless High Density and Wireless High Demand design considerations.

For Wireless High Density think of a Theme Park or a Sports Stadium where the number of Wireless clients is high but the bandwidth demands are low (Social media, web browsing, etc…)

For Wireless High Demand think of a K-12 or Higher Education where the instructing methodology is streaming Unicast Video at a very high resolution 4K or higher.

A great use case for both a High Demand and a High Density Wireless Design would be a Higher Education starting to incorporate Virtual Reality and Augmented Reality solutions over Wireless. The density and demand implications start to get exponentially high.

Four things to consider:

  1. The DSCP of the original packet entering the WLC and being encapsulated in CAPWAP impacts the CAPWAP DSCP header (downstream wired transport to  AP).
  2. The UP imposed by the AP after removing the CAPWAP encapsulation and translating the Ethernet header to 802.11. The UP value is derived from the CAPWAP DSCP value (downstream wireless transport from AP to client).
  3. The UP imposed by the client (locally originated) and sent over the air to the AP. This value is often determined by the DSCP of the original packet being sent, similar to how Ethernet CoS is derived from DSCP in wired networks.
  4. The CAPWAP DSCP imposed by the AP after translating 802.11 to Ethernet and encapsulating it in CAPWAP towards the WLC. This is determined by the UP value, typically NOT the inner DSCP (this can be adjusted on some vendor equipment).

An example: A wired user places a VOIP call to a wireless client using an Apply iPhone 6. The wired phone sets DSCP EF (46) which is commonly used.

Downstream Flow:

1. Wired phone traffic enters the WLC with DSCP EF (decimal 46) and is encapsulated in CAPWAP.

2. The CAPWAP DSCP is copied from inner DSCP, resulting in DSCP EF being transported down to the AP. So far, so good.

Wireless QoS - ZNDP35 - WLAN 1

3. The AP translates CAPWAP DSCP EF to UP 6 which is used for voice across wireless networks. Again, good.

Wireless QoS - ZNDP35 - WLAN 2

Upstream Flow:

4. The iPhone 6 sends traffic up to the AP using UP 5 which is used for video traffic. Why? Because Apple has a business driver to promote Facetime, its interactive video/video application, which uses UP 6.

Wireless QoS - ZNDP35 - WLAN 3

5. The AP thinks this is video traffic since it’s marked UP 5. AP maps this to a CAPWAP DSCP of AF41 (34) which is an appropriate video marking. Inner is DSCP EF, set by the phone, but the transport between AP and WLC will see only CAPWAP DSCP 34.

Wireless QoS - ZNDP35 - WLAN 4

6. The WLC decapsulates CAPWAP and sends the inner IP packet with DSCP EF into the wired network.

Trusting DSCP is the newer and more effective method. That at least protects the wired network.

If you’re stuck trusting UP:

1. Statically mutate DSCP at the ingress switchport where the AP connects. Might work where you know there is a lot of BYOD voice but little/no video, so you can map AF41 to EF with high certainty that its actually voice. Coupled with rate limiting/ACLs to block video, this could work.

2. Try to match based on packet sizes. This might work OK for voice most of the time since packet sizes are fixed, but will have false positives.

3. Run your APs in FlexConnect with local switching, or whatever non-Cisco vendors call it. This eliminates CAPWAP data plane entirely, but comes with many other challenges in a high-scale environment (mobility, IPAM, etc)

4. If CAPWAP data plane is not encrypted, DPI could be used on the switch, if supported, to copy the inner DSCP to CAPWAP DSCP. I’ve never seen this before in production.

Note that trusting DSCP (versus UP) at the AP does not help the WLAN in these cases. The client could use worse AIFS and CWMIN/CWMAX timers.

Takeaways:

  • Expect asymmetric and inconsistent QoS within your network, especially when BYOD is deployed (large variation of devices)! Fortunately, RFC 8325 addresses this by proposing a DSCP/UP mapping standard. Section 4.3 provides a good summary. Released in February 2018, so its fresh, and likely not build into many products today.
  • One phone manufacturer’s business driver could affect your entire campus QoS strategy. A single voice flow could have inconsistent QoS inside and outside of the CAPWAP tunnel, and also upstream and downstream from the AP. Be aware!
  • Nick has tested this on many mobile devices across all RFC 4594 recommended DSCP values and recorded the results, including plain English conclusions. The direct links to these resources are in the below reference material section. Nick has provided all of this 100% free!

Reference material:

  • Wireshark filter used in this the discussion:
    ip.id == 0x2e6d || ip.id == 0xcd77
  • Use the filter above on the following files:

1. qos/marking/qos_marking_appleiphone6_alloy_wired.pcapng
2. qos/marking/qos_marking_appleiphone6_alloy_wlan.pcapng

  • Cisco Live Presentation: QoS Design and Deployment for Wireless LANs – BRKRST-2515
    • Presenter – Robert Barton, Principal Systems Engineer @ Cisco

 

How to stay engaged with Nick:

Work with me:

Through your participation in a healthy mentoring and coaching relationship, you will benefit greatly from the education, the experiences, the influences, leadership and even the resources provided. Learn how you can accomplish more, in one year, than you could accomplish in your career…in your business…and in your life.

Accomplish More Now!!

Provide Feedback

 

Transparency:

This post may contain affiliate links to products or services were I may receive a level of compensation from your actions by following those links. This is seamless to you and does not add any additional cost to the products or services in question. In addition, I do not let any affiliate relationship cloud my judgement or my recommendation of a product or service. My recommendations will always be above reproach.  This is my commitment to you Ziglets!

One comment

  1. Zig – this was GREAT! EXACTLY the kind of information I need, exactly the right level I’m looking for and overflowing with reference material and other sources of even more details.

    Technical. Immediately useful. Pertinent information in a current topic I need to address.

    Please keep doing what you’re doing!

Comments are closed.