On the Uplink Performance of TCP in
Multi-rate 802.11 WLANs
Naeem Khademi, Michael Welzl and Renato Lo Cigno IFIP Networking’11, 10.05.2011 IEEE 802.11 • Wireless channel characterisFcs: noise, interference, fading, short-­‐term variaFon in channel condiFon (e.g. bursty bit-­‐errors) • Lower PHY transmission rate → More robust to noise due to the lower BER • IEEE 802.11 mulF-­‐rate mechanism to react to channel variaFons: – 802.11b 1~11 Mbps (4 PHY rates) – 802.11g 6~54 Mbps (8 PHY rates) • The Rate Adapta)on (RA) mechanism is leY to the vendor in the standard • Main goal → maximizing system throughput Rate AdaptaFon RA Schemes: a) Use link layer metrics (e.g. ARF family) – ConsecuFve packet successes/losses to increase/decrease rate – Probe packets to assess possible new rate b) Use PHY metrics (e.g. RBAR and OAR) for rate esFmaFon – Signal-­‐to-­‐Noise RaFo (SNR) – Received Signal Strength IndicaFon (RSSI) “Experimental studies show that there is no strong correla.on between SNR and delivery probability at a rate in a general case. SNR variaFons also make the rate esFmaFon highly inaccurate” [J. Bicket. Bit-­‐rate SelecFon in Wireless Networks. MIT Masters Thesis, 2005] Auto-­‐Rate Fallback (ARF) • First rate adaptaFon algorithm designed for WaveLAN II devices (1997) • ARF family: Many today’s widely deployed RA mechanisms in 802.11 WLANs inherit the concept of ARF e.g. AARF, Atheros-­‐based Madwifi driver’s RA suite (ONOE, AMRR , SampleRate and Minstrel) • ARF mechanism: – Agempt to use a higher PHY rate aYer a fixed number of successful transmissions (UP threshold) or Fmer expiraFon; fall back to a lower rate aYer fixed number of consecuFve failures (DOWN threshold) in addiFon to sejng the Fmer. – If the probing frame fails, switch back to the previous rate and restart the Fmer. – UP/DOWN thresholds: in Cisco Aironet 350 cards 5/9/11 4 ARF’s ProblemaFc Issues a) May respond aggressively to MAC-­‐level frame collision caused by contenFon (e.g. ) when noise level is low → rate downshiY (unable to disFnguish collision from noise) – Proposed solu)on: CARA mandates the use of RTS/CTS frames to differenFate frame collisions from frame transmission failures due to noise [J. Kim et al. CARA: Collision-­‐aware rate adaptaFon for IEEE 802.11 WLANs. INFOCOM 2006] b) Tries to use a higher rate every UP threshold (e.g. ) successful transmission on a channel with stable condiFon → retransmission agempts – Proposed solu)on: AdapFve ARF (AARF) uses Binary ExponenFal Backoff (BEB) to adapt its probing threshold by doubling it (with a maximum bound of 50) when a probe packet fails [M. Lacage et al. IEEE 802.11 rate adaptaFon: a pracFcal approach. MSWiM '04] 5/9/11 5 Cross-­‐layer InteracFon of ARF/DCF/TCP Reasons to study the ARF/DCF/TCP interac)on: a) Extensive literature on the cross-­‐layer interacFon of ARF/DCF (though sFll an open issue!) but ARF/DCF/TCP is not well-­‐invesFgated yet b) ARF is easier to model than most ARF-­‐like implemented RA algorithms. On the other hand these algorithms generally inherit the deficiencies of ARF. c) High majority of Internet traffic are TCP flows (e.g. Web, P2P, FTP) d) Below work claims that scalable performance of TCP over DCF miFgates the negaFve impact of ARF in the presence of many contending staFons but it only studies the downlink scenario! [J. Choi et al. Cross-­‐layer analysis of rate adaptaFon, DCF and TCP in mulF-­‐rate WLANs. INFOCOM 2007] Scalable Performance of TCP over DCF • AP access to the channel follows O(1/(N+1)) • Large N → lower probability for AP to succeed in contenFon → increasing the backlog queue of backlogged staFons or increasing the number of backlogged staFons • Under TCP traffic is small even for large numbers of N; fixed approx. around 2-­‐3 in equilibrium for N<100 – Reason: self-­‐clocking mechanism of TCP • Small → lower collision rate → miFgaFng the bad performance when ARF enabled ARF/DCF/Uplink-­‐TCP • More common TCP uplink traffic nowadays! (e.g. torrents, email agachments, Facebook image uploads via 802.11-­‐enabled PDAs) • 1500-­‐bytes Data packet collisions are more severe for TCP than 40-­‐bytes ACK packet collisions • Uplink scenario (with saturated traffic) for N contending sta)ons: – AP sends ACK packets O(1/(N+1)) – Nodes (in contract to downlink) acFvely send data packets O(N/(N+1)) – Collision probability: , Long-­‐term channel access probability: Uplink data packet collisions with enabled ARF Waste of wireless channel bandwidth Lower channel efficiency and system throughput Rate downshiR of the retransmiSed packet (frame) and consequent data packets Higher collision probability and more rate downshiRs Backlogged upstream queues at the sta)ons Longer packet transmission /me and wai)ng )me for other sta)ons (NAV) Performance EvaluaFon (SimulaFon Setup) • ns-­‐2 does not support ARF (or AARF) by default. We did a set of simulaFons using Marco Fiore’s AARF patch and Caltech’s Linux TCP implementaFon for ns-­‐2 with 802.11b/g parameters SimulaFon parameters WLAN topology Performance EvaluaFon (Goodput) 80-­‐85% reducFon Per-­‐second aggregate goodput of 10 staFons in 802.11b (wired delay=50ms, TCP NewReno) 5/9/11 11 Performance EvaluaFon (cwnd vs. PHY rate) Rule-­‐of-­‐thumb: cwnd of a single NewReno upload flow vs. PHY rate 5/9/11 12 Performance EvaluaFon (Impact of PER=0.1) cwnd of a single NewReno upload flow 5/9/11 Packet losses at MAC level cause significant flagening of cwnd in the presence of ARF. 13 Performance EvaluaFon (Impact of PER=0.1) RTT of a single NewReno upload flow 5/9/11 14 Performance of High-­‐speed TCPs • Standard NewReno TCP performs poorly in networks with a large bandwidth×delay • Vast number of proposals for overcoming this limitaFon: – CUBIC (default mechanism in the current Linux kernel) – HTCP (commonly compared to CUBIC) – HSTCP (standardized in RFC 3649) • These variants can all achieve very large cwnd sizes compared to standard NewReno in long distance networks Performance of High-­‐speed TCPs • CUBIC: cwnd is a cubic funcFon of Fme since the last congesFon event with the inflecFon point set to the cwnd prior to the event • HTCP: uses AIMD to control cwnd. It increases its aggressiveness (in parFcular, the rate of addiFve increase) as the Fme since the previous loss increases • HSTCP: when an ACK is received in the CA phase, cwnd is increased by a(w)/w, and when a loss is detected via a triple duplicate ACK, cwnd is decreased by (1-­‐b(w))w; the values of the funcFons a and b get larger and smaller with a growing w. • We evaluated the performance of these TCP variants coupled with ARF using the ns-­‐2 TCP patch (Linux kernel 2.6.16.3 source-­‐code) Performance of High-­‐speed TCPs (ContenFon Effect) Aggregate throughput of TCP variants vs. number of nodes (wired delay=100ms) 1000 seconds FTP upload data transfer 5/9/11 17 Performance of High-­‐speed TCPs (Delay Effect) 5/9/11 Aggregate throughput of TCP variants vs. wired delay (N=10) 1000 seconds FTP upload data transfer 18 Conclusions and Future Work a) The uplink TCP performance in mulF-­‐rate 802.11 WLANs has been studied and evaluated by ns-­‐2 simulaFons b) It has been shown that ARF can significantly impede the TCP performance in uplink scenarios where mostly data packets, not ACKS, collide. Previous works ignored this scenario. c) Real-­‐life experiments should be conducted to validate these results with different varieFes of ARF-­‐like RA mechanisms (e.g. emulab, 802.11 testbed in ND/IFI/UiO) d) Newer 802.11 protocols should be studied (e.g. 802.11n) e) Self-­‐adapFve mechanism(s) should be proposed to solve this deficiency (e.g. AQM, adverFsed window sizing) Thank you! Q&A?