Unavoidable Packet Loss Issue in 802.11a/g PHY doc.: IEEE 802.11-06/xxxxr0 Sept 06 Unavoidable Packet Loss Issue in 802.11a/g PHY Date: September, 2006 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Tom Alexander, VeriWave Tom Alexander, VeriWave

Introduction Problem statement Calculation of probability of loss doc.: IEEE 802.11-06/xxxxr0 Sept 06 Introduction Problem statement Calculation of probability of loss Recommendations Tom Alexander, VeriWave Tom Alexander, VeriWave

doc.: IEEE 802.11-06/xxxxr0 Sept 06 Summary of Problem An 802.11 compliant device should have zero actual packet loss on the wireless medium “Packet loss” is not the same as “frame errors” A high frame error rate (e.g., 10%) should still result in zero packet loss; retries will compensate, and data will eventually get through However, while running throughput tests on standards compliant devices, non-zero packet loss was found Packets were being lost in spite of retries! Packet loss was extremely small (0.001%) but never went away, even with quite small offered loads The loss was traced to an inherent deficiency in the 802.11 a/g PLCP header This has implications for performance tests Tom Alexander, VeriWave Tom Alexander, VeriWave

ERP-OFDM PLCP Header & Bit Errors doc.: IEEE 802.11-06/xxxxr0 Sept 06 ERP-OFDM PLCP Header & Bit Errors Header protected by 1 parity bit RATE, LENGTH define PHY packet time PLCP RATE & LENGTH fields are key Used by OFDM PHY to calculate duration of packet Calculation result takes precedence over actual carrier sense See subclause 17.3.12 PLCP header protected only by a single parity bit Probability of undetected header corruption: 50% Tom Alexander, VeriWave Tom Alexander, VeriWave

Loss Mechanism Example: 100 byte OFDM packet sent at 54 Mb/s doc.: IEEE 802.11-06/xxxxr0 Sept 06 Loss Mechanism RX PLCP header with bit errors TX Wireless Medium PKT RETRY1 RETRY2 RETRYn Actual Packet Duration RX back to normal RX “blind” time due to PLCP header error Retries during RX “blind” time Example: 100 byte OFDM packet sent at 54 Mb/s Bit errors occur in PLCP header due to channel noise The bit errors “convert” the packet into 4095 bytes @ 6 Mb/s Bit errors in PLCP header not detected because parity check is very weak The receiver is “blinded” for up to 5.5 milliseconds Per Clause 17, RX must use calculated time from PLCP header, not actual All of the retries occur during the “blind” period After last retry, the TX marks packet as failed and drops it Result: packet is permanently lost Tom Alexander, VeriWave Tom Alexander, VeriWave

doc.: IEEE 802.11-06/xxxxr0 Sept 06 IEEE 802.11 (2003) 17.3.12 Subclause 17.3.12, IEEE 802.11-1999 (2003 Edition) "In the event that a change in the RSSI causes the status of the CCA to return to the IDLE state before the complete reception of the PSDU, as indicated by the PLCP LENGTH field, the error condition PHY-RXEND.indicate(CarrierLost) shall be reported to the MAC. The OFDM PHY will ensure that the CCA indicates a busy medium for the intended duration of the transmitted packet." PLCP RX state machine (Fig 129) confirms RX must be held in busy state until “intended end of PSDU” Next frame cannot be received until RX goes back to IDLE state Result: anything received after corrupted PLCP is lost Depending on retry limit, this could be up to 3 consecutive MSDUs Retry limits for APs & VoIP handsets are usually aggressive Typically, 2-4 retries max (APs), 1-2 retries max (handsets) Tom Alexander, VeriWave Tom Alexander, VeriWave

Estimated Loss Probability doc.: IEEE 802.11-06/xxxxr0 Sept 06 Estimated Loss Probability Factors contributing to loss probability: Small “actual” packet and high “actual” PHY bit rate PLCP error changes to large “apparent” packet and low “apparent” PHY bit rate High FER on link Compliant PHY can have as much as 10% FER Good-quality cabled setups have shown as much as 1% FER Assumptions for calculation: 100 byte data packet @ 54 Mb/s 1% FER Uniform error distribution Probability calculation: Probability of frame error: 0.01 Probability of error in PLCP header (100-byte frame @ 54 Mb/s): 0.2 Probability that parity check will miss error: 0.5 Overall probability of corrupted PLCP header = 0.001 Worst-case probability of packet loss due to this mechanism: 0.1% The distribution of RATE/LENGTH values in corrupted header balances out with the fact that multiple packets can be lost at one time, especially if retry limits are low Tom Alexander, VeriWave Tom Alexander, VeriWave

Effect On Performance Tests doc.: IEEE 802.11-06/xxxxr0 Sept 06 Effect On Performance Tests RFC 2544 throughput tests are usually run with loss tolerance of zero Loss of even one frame will cause throughput search algorithm to hunt for a lower throughput Due to retries, wireless media would normally be assumed lossless However, a constant frame loss probability regardless of offered load means that throughput tests can hunt right down to zero Roaming times are significantly affected by such loss Lose an EAP/4-way HS packet completely, and handshake will stall It can be 30 seconds before RADIUS times out and restarts handshake R-value scores are also an issue VoIP traffic is affected more by packet loss than by delay/jitter Tom Alexander, VeriWave Tom Alexander, VeriWave

doc.: IEEE 802.11-06/xxxxr0 Sept 06 Recommendations Set acceptable loss tolerance for throughput tests >0 0.1% acceptable loss is recommended Minimize FER during performance tests Higher FER => higher probability of intrinsic packet loss Cabled setups, properly adjusted signal levels, good radios … Set RADIUS client/server handshake retry times low Restart quickly if an EAP or 4-way handshake packet is lost Add a section in 802.11.2 warning of this issue? Keep people from chasing ghosts Ensure problem does not occur in 802.11n PHY 802.11b does not see this issue because 32-bit PLCP header is protected with a 16-bit CRC => excellent header protection It is unusual for key elements of low-level protocol headers to be protected by something as weak as a parity bit! Tom Alexander, VeriWave Tom Alexander, VeriWave