Wireless QoS Part 1 - Background Information

Read the Entire Wi-Fi Quality of Service 5-Part Series:

1. Part 1 - Background Information
2. Part 2 - IEEE 802.11e Principles
3. Part 3 - User Priorities, Access Categories and Queues
4. Part 4 - Arbitration Interframe Spacing
5. Part 5 - Contention Window and Final Thoughts

Part 1 - Background Information
Prior to the 802.11e amendment, legacy 802.11 wireless network operated under the Distributed Coordinate Function (DCF). DCF is built on the CSMA/CA medium contention protocol to regulate access to a shared medium, wireless airtime. On multiple access networks, a method is required to determine an orderly method for stations to determine whose turn it is to transmit a frame, how to avoid collisions, how to detect collisions, and how to gracefully recover from failed transmissions due to collisions or other errors such as interference. The CSMA/CA protocol fills this need.

The basic principles of CSMA/CA are:

1. Carrier Sense to detect incoming transmissions
2. Clear Channel Assessment (CCA) and Network Allocation Vector (NAV) to determine if the medium is idle and it is acceptable for the station to transmit a frame
3. Positive acknowledgement of frames to pro-actively avoid collisions since wireless receivers cannot passively determine if a collision has occurred as the RF energy is dispersed. This is in contrast to wired Ethernet’s use of CSMA/CD and collision detection where the receiver is able to detect collisions since the energy is reflected through the wire back to the transmitter.

802.11 networks are further built upon two principles to regulate access to the medium:

1. Inter-frame Spacing (IFS)
2. Random Backoff Contention Window

First, inter-frame spacing establishes baseline intervals that certain types of frames are required to wait prior to being able to transmit. These basic IFS values serve as a coarse method of frame prioritization. However, this prioritization is not based on the application priority but rather on frame priority for basic functionality within the 802.11 protocol. Three IFS values are defined in a non-QoS legacy 802.11 basic service set:

1. Short Inter-frame Space (SIFS) is used for frames that need to immediately follow the preceding frame, generally for control purposes. Examples include control frames that are required to positively acknowledge receipt of an immediately pre-ceding frame (ACK), to reserve the medium when an explicit request to send (RTS) has been sent by a station and are responded to with a clear-to-send frame (CTS) frame, data frames immediately following a CTS, and the second or greater fragment of a fragmented frame.
   
   
2. Point-Coordinated Inter-frame Space (PIFS) is used when the BSS is placed into a contention-free period by the access point. This mode of operation uses the AP as a point coordinator to poll capable stations for data frames, rather than let stations contend for access in a distributed fashion. This IFS is dependent on the Point-Coordinated Function (PCF) of the standard being implemented by both the AP and stations. To date, no product implements PCF, so this IFS remains un-used in the marketplace.
   
   
3. Distributed-Coordinated Inter-Frame Space (DIFS) is used when the BSS is operating in DCF mode, where stations contend with one another for access to the medium using the CSMA/CA protocol. DIFS is used for all frames for which SIFS is not applicable, typically data and management frames.

All IFS values are dependent on the physical layer (PHY) implementation. DIFS values are defined with the formula: 1 x SIFS + (2 x Slot Time). The SIFS and DIFS values are as follows:

Note – 802.11g and 802.11n values are specified for both legacy interoperability with 802.11b (long) and greenfield operation (short) in the 2.4 GHz frequency band.

(Figure 2-3 courtesy of “Voice over Wireless LAN 4.1 Design Guide” page 2-5, by Cisco Systems)

Second, the random backoff contention window further specifies how long a station must continue to wait if attempting to transmit a frame after detecting a busy medium. If the medium was busy when the station deferred access and queued a frame for transmission, there is a high likelihood that other stations also deferred access and have frames to transmit as well. Without a random backoff timer, multiple stations would then attempt to transmit frames at the exact same time, leading to a very high probability of collisions and degradation in network performance. The deferral of access due a busy medium serves to align the transmission of subsequent frames and increases the probability of collisions on the network.

By implementing a random backoff contention window on a per-station basis, frame transmissions are no longer aligned in most instances and allow for proper access by only one station to reserve the medium and transmit a frame; all other stations will recognize the beginning of a new transmission and pause their backoff timers and defer access to the new transmission. Additionally, should a collision still occur if two stations pick the same random backoff timer and no positive acknowledgment of the transmitted frame is received, the stations will increase the contention window range allowing for more possible random values to be selected and decrease the likelihood of subsequent collisions.

The contention window ranges from zero up to CWmin initially, with the potential to grow and range from zero to CWmax. Each subsequent collision (detected through a lack of acknowledgment in return) results in the station doubling the contention window size, up to the maximum value. Contention window values are decremented by one for every slot time that passes without detecting another station transmitting.

The DCF (non-QoS) contention window values are:

• 802.11b – aCWmin 31, aCWmax 1023
• 802.11g – aCWmin 31, aCWmax 1023 (when 802.11b stations are present)
• 802.11g – aCWmin 15, aCWmax 1023
• 802.11a – aCWmin 15, aCWmax 1023
• 802.11n – aCWmin 15, aCWmax 1023

(Figure 2-4 courtesy of “Voice over Wireless LAN 4.1 Design Guide” page 2-6, by Cisco Systems)

So to recap:

• DCF defines a distributed coordination function whereby all stations contend for access to the medium.
• DCF is governed by the underlying CSMA/CA protocol which requires positive acknowledgment of frames and pro-active collision avoidance.
• Each station defers access to the medium if busy.
• Once the medium is determined to be idle through both CCA and NAV:
• The station waits the appropriate inter-frame space (IFS) value based on the type of frame being sent.
• If the medium was idle prior to the frame being queued, the random backoff timer is skipped.
• If the medium was busy prior to the frame being queued, a random backoff value is selected in the range of 0 to CWmin (for the first transmission attempt), possibly up to 0 to CWmax (after multiple collisions).
• The random backoff value is decremented by one for every slot time that passes without detecting another station transmitting.
• Each slot time that passes, the stations checks CCA and NAV to determine if the medium is still idle, or if it is now busy with a transmission from another station.
• If another station does begin transmitting, the backoff timer is paused until the end of transmission, the appropriate IFS value is waited, then the backoff timer resumes countdown from where it left off.
• The random backoff timer expires (countdown to zero).
• The station transmits the queued frame.

In subsequent posts, I will detail what changes are made as part of the 802.11e amendment to implement Quality of Service (QoS) over wireless networks.

- Andrew

Beamforming, ClientLink, and Disappointing Test Results

With Cisco's release of 802.11n access points, they began touting a package a features marketed as M-Drive. Among those was a feature called ClientLink. As implied, this feature's goal is to improve wireless links for clients :)

ClientLink is an implementation of an optional feature in the 802.11n amendment known as Transmit Beamforming. There are various forms of beamforming, some standards-based, most proprietary to certain vendors. For an overview of different beamforming types, see these articles from Ruckus and Aerohive.

I like to think of these beamforming types as 3 distinct categories:

1. Static Beamforming - think semi-directional or directional antennas. They don't change, or move, or dynamically adjust. They simply focus the signal in a specific direction. Signal gains can potentially be very large (>10dB), based on the dBi rating of the antenna selected.
   
   
2. On-Chip Beamforming - this is 802.11n standards-based transmit beamforming. The radio chipset coordinates the signal processing across multiple transmit radio chains, altering timing and phase alignment of each signal, in an attempt to have multiple signal copies arrive at the receiver "in-phase" to provide passive gain. Signal gains are 3dB maximum, which is quite logical if you think about what's going on at the receiver - two in-phase signals merge, potentially doubling the amplitude of the signal at the receiver.
   
   
3. Antenna Beamforming - this is what Ruckus does best. They have multiple antenna elements (an antenna array if you will), some polarized horizontally and some vertically. The radio chipset sends one signal and a complex formula selects the best possible antenna element combinations to transmit the signal to the client. Signal gains max out around 9dB in the Ruckus implementation, but I suspect it could be higher with different antenna array designs.

ClientLink would fit into the category of "on-chip beamforming"  using standards-based transmit beamforming with implicit feedback, since the client is not required to support beamforming and explicit feedback mechanisms. That's one of their big selling points, improvement of legacy clients by upgrading to 802.11n APs.

Test Setup
I recently had a chance to evaluate ClientLink performance (having done similar testing with Ruckus in the past). My testing consisted of a Dell Latitude D620 laptop with an integrated Dell Wireless 1490 802.11a/g adapter based on a Broadcom chipset, running the Juniper Odyssey supplicant. It is important to use an 802.11a or 802.11g adapter, as ClientLink only works with legacy devices since it uses both transmit radio chains to send the same signal to the client (spatial multiplexing for two-stream 802.11n data rates would use both radio chains, leaving none left for beamforming).

Cisco's documentation states that a maximum of 15 clients per radio can be supported using ClientLink at the same time. Any additional clients can connect, but won't get beamforming. Additionally, beamforming is supposed to kick into gear once a client's signal strength drops below a threshold (there's no point in attempting to improve SNR if the client already has a great signal). Those thresholds are -50 dBm or weaker for 802.11g, and -60 dBm or weaker for 802.11a.

Testing was performed in two locations. Location 1 is a production environment in a large multi-story downtown office building, with competing wireless networks and a large amount of client traffic. Location 2 is an isolated lab environment with no competing wireless networks, no clients, and no interference present in the environment. In each location, metrics were measured at increasing distances from the AP, including signal strength in dBm, data rate chose by the client, and iperf throughput to a gigabit wired host. Three iperf throughput tests were run at each distance and the average was taken.

All testing was performed on Cisco's latest code version 7.0.98.0 with 3502 access points.

Test Results
Location 1 (Production Environment):

Location 2 (Lab):

Overall, I found ClientLink to be highly inconsistent. It actually appears to have hurt client performance in most situations. In the production environment, client performance was significantly worse in 5 out of the 6 locations when ClientLink was enabled. The lab environment faired somewhat better, but performance was still worse half of the time when ClientLink was enabled. High variations in performance like these will lead to very hard-to-diagnose issues in a real-world scenario.

This is the double-edged sword of monkeying with multiple copies of the same signal. If you get it right and phase alignment occurs at the receiver, performance improves. By that same token, if you get it wrong and the signals are out of phase, then you've hurt performance for the client.

Ultimately, I cannot recommend that Cisco customers use ClientLink as it stands today. I have to conclude that Cisco's current implementation will result in inconsistent network performance, an increase in network support incidents, and overall a less stable network connection for users.

Perhaps they'll fix these performance issues in a future release.

-Andrew

WiFi Tip: Upgrade Autonomous to LWAPP without the Upgrade Tool

Did you know that Cisco Autonomous access points can be upgraded directly to LWAPP access points without using the Upgrade Tool? It's true. Use this command:

archive download-sw /leave-old-sw /force tftp://ip-address/image

Then verify the system boot image was set correctly, which should happen automatically with the command above:

show boot


Then simply reboot the access point. The controller discovery mechanisms also need to be in place for the AP to find a controller over a layer 3 boundary.

The only real reason to use the Upgrade Tool is if you have a really old access point that was manufactured without a MIC (manufacturer installed certificate). In that case, the Upgrade Tool issues commands during the upgrade process to generate a Self-Signed Certificate (SSC) on the AP.

-Andrew

WiFi Tip: Boost 802.11n Performance with H-REAP

To boost 802.11n performance by 5-10%, put 1250 APs in H-REAP mode and enable locally switched WLANs! http://bit.ly/8Yodmi

Knowledge Sharing and Social Media

Recently, over the past year or so, I have begun diving deeper and deeper into social media outlets. One of the truly great values that I've come to appreciate from these services is the ability to share knowledge with other people, and to receive their insights as well. As with most things in life, one person cannot know "everything." By creating dynamic communities of like-minded individuals, we can each contribute our knowledge into a collective pool of information.

I have found a tremendous amount of information relevant to the wireless industry. This collection of information serves as a tremendous resource for new and experienced wireless engineers alike.

I've found Google Reader and RSS feeds to be among the most useful tools to remain current on WiFi technology. Since WiFi is still a rapidly evolving technology, innovation is occurring at a very fast pace. You need tools like RSS feed aggregation to stay relevant. I like Google Reader because it allows me to read news while on the go. Hey, we work in wireless, mobility should be second-hat for us right?

In the spirit of this collaboration, I would like to share some of my favorite WiFi information sources. I hope you find some of these links useful. I am constantly updating these sources as I find new and interesting content, so check back regularly or add the direct sources to your own lists.

My Google Reader Shared Items:

http://www.google.com/reader/shared/Andrew.vonNagy

My Google Reader Bundle of WiFi Sources:

http://www.google.com/reader/bundle/user/08090207253557082847/bundle/Revolution%20Wi-Fi

My Twitter List for WiFi Sources:
https://twitter.com/revolutionwifi/wifitweeps

My You Tube WiFi Playlist:
http://www.youtube.com/view_play_list?p=9EBE21B124E30FC3

Aruba Networks Whitepapers:
http://www.arubanetworks.com/technology/whitepapers.php

Aerohive Multimedia and Whitepapers:
http://www.aerohive.com/resources/multimedia.html

WLAN Professionals Podcast:
http://wlanpros.com/

CWNP Resources:
http://www.cwnp.com/index/training/freeresources

Cisco DesignZone for Mobility:
http://www.cisco.com/en/US/netsol/ns820/networking_solutions_program_home.html

Cisco Support Documentation (look under Products - Wireless):
http://www.cisco.com/cisco/web/psa/default.html?mode=prod&level0=278875243

Cisco TechWise TV Broadcasts:
http://www.cisco.com/en/US/netsol/ns914/networking_solutions_program_home.html

Cisco Mobility TV Broadcasts:
http://www.cisco.com/en/US/solutions/ns340/ns394/ns348/networking_solutions_products_genericcontent0900aecd8056b097.html

Cisco Seminars and Webcasts:
http://www.cisco.com/go/seminars/


I'm sure that I'm missing plenty of great content that's out on the interwebs, but feel free to drop me a line in the comments, on twitter, or via email to let me know of any wireless sources you find useful.

-Andrew

Fragmentation in Controller Architectures

*Updated Dec. 2010 - Added CAPWAP information.


Why IP Fragmentation is a Concern on Wireless Networks

A big concern with controller-based architectures is reduced performance due to IP fragmentation due to tunnel overhead between the AP and controller. Typically, most lightweight APs tunnel all client traffic back to the controller through a layer 3 tunnel. This tunnel adds overhead, as the AP has to encapsulate the original client frame within a new IP packet.

Almost all vendors now offer options to locally switch (or bridge) the client frames into the wired network from the AP, without tunneling the frame back to the controller. Lookup Cisco H-REAP, Aruba RAP, Ruckus does this by default on all APs, Aerohive doesn’t even have a physical controller, you get my point.

Tunnel overhead reduces the amount of data available in the packet payload that can carry client data. If the client sends frames that are above a certain threshold, then adding the additional tunnel headers increases the packet size beyond the Ethernet MTU (1500 bytes unless using jumbo frames), resulting in IP fragmentation. Ultimately, this results in increased network latency and jitter, and decreased throughput.

Bad for data, worse for voice!

LWAPP Overhead

In Layer 3 LWAPP mode, additional IP, UDP, and LWAPP headers are added to encapsulate the original client 802.11 frame between the access point and controller.

LWAPP overhead for tunneled client frames is 52 bytes due to these additional frame headers which encapsulate the original frame taken out of the air:

§  18 – Ethernet header and checksum

§  20 – IP header (without IP options)

§  8 – UDP header

§  6 – LWAPP header (CAPWAP header is 8 bytes)

The contents of the LWAPP frame also contain the original 802.11 client data frame, with a few notable portions that are stripped out. Let’s add these into the tunneled frame contents:

§  24 – Original 802.11 MAC header, without QoS, encryption, or checksum fields

§  8 – 802.2 LLC and SNAP headers (3 LLC, 5 SNAP)

§  20 – Original IP header

§  Variable – Transport layer header (20 TCP, 8 UDP, 8 ICMP, etc.) and data payload

Notice that I said the whole 802.11 frame, not just the client’s data payload, get’s tunneled. The 802.11 MAC header is tunneled in order for the controller to be able to de-multiplex the original client frame, determine source and destination MAC addresses, forward the frame to appropriate destination host, and perform the non-real-time 802.11 MAC functions in the Split-MAC architecture.

Split-MAC Responsibilities

In Cisco’s LWAPP architecture, split-MAC is the term coined to differentiate what MAC functions get handled by the controller versus the access point.

Since the controller needs to handle some MAC functions, it needs the client’s 802.11 MAC header tunneled back to it to perform its responsibilities. Since the AP handles real-time MAC functions, such as QoS and encryption/decryption, those fields are stripped out of the header before tunneling the packet to the controller.

Controller Responsibilities:

§  Security management (policy enforcement, rogue detection, etc.)

§  Configuration and firmware management

§  Northbound management interfaces

§  Non real-time 802.11 MAC functions

o   Association, dis-association, re-association

o   802.11e/WMM resource reservation (CAC, TSPEC, etc.)

o   802.1x/EAP authentication

o   Key management

§  802.11 distribution services

§  Wired and wireless integration services

Lightweight Access Point Responsibilities:

§  Real-time 802.11 MAC Functions

o   Beacon generation

o   Probe responses

o   Informs WLC of probe requests via LWAPP control channel

o   Power management and packet buffering

o   802.11e/WMM scheduling and queuing

o   MAC layer data encryption and decryption

o   802.11 control messages (ACK, RTS/CTS)

§  Data encapsulation and de-capsulation to LWAPP

§  Fragmentation and re-assembly

§  RF spectral analysis

§  WLAN IDS signature analysis

LWAPP Fragmentation

Let’s take a look at how Cisco’s LWAPP protocol handles IP fragmentation in code versions prior to 5.2, when the switch to CAPWAP is made.

Layer 3 LWAPP is able to perform full fragmentation and reassembly of tunnel packets using standard IP fragmentation, thereby allowing client traffic to make use of a full 1500 byte MTU and not to have to adjust for any tunnel overhead. This simplifies administration of wireless clients, since you don’t have to touch them to modify MTU settings for the wireless adapter. Clients simply assume their IP packets have an MTU of 1500 bytes and move happily along. It’s not until the frame reaches the AP that fragmentation needs to occur because of the tunnel overhead.


* Note - CAPWAP includes fragmentation and re-assembly support and does not rely on the standard IP fragmentation. Therefore, in fragmented CAPWAP tunnel packets, fragmentation will be performed on the CAPWAP data, with each fragment duplicating the outer IP, UDP, and CAPWAP headers.

Adding up the tunnel overhead, we find that the threshold for the original client’s IP packet that causes fragmentation of the LWAPP IP packet on an Ethernet segment with a 1500 byte MTU is at a size of 1434 bytes. We get this by adding the tunnel headers (IP, UDP, LWAPP) and the tunneled 802.11 frame headers (802.11, LLC, SNAP), and subtracting those amounts from the 1500 byte MTU. This leaves only the original client IP packet which must be under a 1434 byte threshold to prevent fragmentation. The outer Ethernet header is not included because the MTU size does not consider the layer 2 MAC header, which is appended later.


(Threshold is 1432 bytes for CAPWAP encapsulated frames)

Here is a packet capture to illustrate this fragmentation. Remember, the outer IP header for the tunnel will handle the fragmentation, so the UDP and LWAPP headers will only be found in the first fragment.

Testing LWAPP Fragmentation

An easy way to test LWAPP fragmentation is to connect to the wireless network and ping the subnet gateway above and below the maximum ICMP payload size of 1406 bytes assuming a 1500 byte MTU. How we get to 1406 bytes for this test:

1500 byte MTU

     Subtract 34 bytes for LWAPP encapsulation (subtract 36 bytes for CAPWAP)

     Subtract 24 bytes for the tunneled 802.11 header

     Subtract 8 bytes for the tunneled 802.2 LLC/SNAP header

     Subtract 20 bytes for the tunneled IP header (without options)

     Subtract 8 bytes for the ICMP header

= 1406 bytes remaining for ICMP payload (use 1404 bytes for CAPWAP)

Setup a tap or port mirror on the switch port attached to the access point. Connect a workstation running a protocol analyzer to the mirrored port or tap, filter on port UDP 12,222 (LWAPP Data) or UDP 5247 (CAPWAP Data), and start capturing packets. 

From the wireless client, try out these commands and watch the results in the protocol analyzer.

Test 1

ping –f –l 1406 ip-address

Result will be successful, no fragmentation.

Test 2

ping –f –l 1407 ip-address

Result will be successful, but LWAPP tunnel packets will be fragmented. LWAPP tunnel packets do not carry over the original packet’s don’t fragment flag.

Test 3

ping –f –l 1473 ip-address

Result will fail, as original IP packet needs to be fragmented by the client but the don’t fragment flag is set.

Note

Many VPN client software packages will change the default interface MTU to a lower value. Verify the interface MTU to adjust test payload size properly. For example the Cisco Systems VPN client software for Windows XP modifies the MTU from 1500 bytes to 1300 bytes.

To view the current interface MTU:

§  Windows XP regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface-id\MTU

(if the key does not exist, it uses the default MTU of 1500 bytes)

§  Windows Vista/7 view interface MTU command is “netsh interfaces ipv4 show subinterfaces”

Preventing Fragmentation

Unfortunately, there is no method to prevent LWAPP fragmentation in the controller or access points until code version 6.0 with the CAPWAP protocol.

To avoid fragmentation of client packets enable TCP Maximum Segment Size (MSS) control on the controller and lightweight access points in code versions 6.0 and later.

This feature allows connected CAPWAP access points to re-write client TCP SYN packets with the configured maximum segment size to optimize large data transfers and prevent fragmentation when CAPWAP encapsulated. The valid range is from 536 to 1363 bytes, and it is recommended to use a 1363 byte value.

Configure it from the CLI using this command:

config ap tcp-adjust-mss { enable | disable } { all | ap-name } tcp_mss_value

- Andrew