1. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 1 Unavoidable Packet Loss Issue in 802.11a/g PHY 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, 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 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.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: September, 2006 Authors:

2. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 2 Introduction Problem statement Calculation of probability of loss Recommendations

3. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 3 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

4. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 4 ERP-OFDM PLCP Header & Bit Errors 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% RATE, LENGTH define PHY packet time Header protected by 1 parity bit

5. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 5 Loss Mechanism 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 PKTRETRY1RETRY2RETRYn RXTX Wireless Medium PLCP header with bit errors Retries during RX “blind” time RX back to normal Actual Packet Duration RX “blind” time due to PLCP header error

6. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 6 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)

7. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 7 Estimated Loss Probability Factors contributing to loss probability: –Small “actual” packet length and high “actual” PHY bit rate That is, a the actual packet takes very little time to transmit or to retry –PLCP error changes to large “apparent” packet length, low “apparent” PHY bit rate That is, the receiver is blinded for a very long period of time –High FER on link Compliant PHY can have 10% FER; good-quality cabled setups have as much as 1% FER Assumptions for calculation: –100 byte data packet @ 54 Mb/s –1% FER, uniform error distribution over the PLCP frame Probability calculation: –Probability of frame error: 0.01 –Probability error will occur in PLCP header (100-byte MAC 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

8. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 8 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

9. doc.: IEEE 802.11-06/1388r1 Submission Sept 06 Tom Alexander, VeriWaveSlide 9 Recommendations Set acceptable loss tolerance for throughput tests >0 –0.1% acceptable loss is recommended Minimize FER during throughput, VoIP or roaming tests –Higher FER => higher probability of intrinsic packet loss –Cabled setups, properly adjusted signal levels, well-matched 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 (mixed mode) –It is unusual for key elements of low-level protocol headers to be protected by something as weak as a parity bit! –802.11b does not see this issue 32-bit PLCP header is protected with a 16-bit CRC => excellent protection –802.11n in mixed mode will also have this problem HT-SIG has an 8-bit CRC protecting SIGNAL field => good protection L-SIG has exactly the same structure as 802.11a/g (1 parity bit) => weak