1 How to apply Adaptation principle: case study in

2 How to apply adaptation?? Roadmap of a successful adaptive solution –What to adapt to? → problem space –How to adapt? → solution –How well it can adapt ? → evaluation

3 Steps What should an adaptive solution adapt to? –Identify all possible scenarios How to adapt ? –Handle different scenarios one by one How to evaluate the solution? –Evaluations that can accurately reflect normal usage

4 Case study: Rate Adaptation in What to adapt to? –Identify all possible scenarios How to adapt ? –Handle all possible scenarios accordingly How to evaluate?

5 What is Rate Adaptation? The PHY-layer transmission rate is adjusted to the channel condition in real-time Sender Receiver 54Mbps Signal is good Signal becomes weaker 12Mbps

6 IEEE Rate Adaptation Discrete PHY rate options in the standard –802.11b, 4 rate options –802.11a, 8 rate options –802.11g, 12 rate options Unspecified by the standards –Vendors have freedom

7 Why Rate Adaptation? Better exploit the PHY multi-rate capability Rate adaptation affects the throughput performance! –Rate too high → loss ratio increases → throughput decreases –Rate too low → under-utilize the capacity → throughput decreases

8 Step 1: What to adapt? Identify different channel conditions –#1: Collision loss (hidden terminal, contention) –#2: Non-collision losses: #1: random channel error #2: mobility loss

9 Existing Solutions? Performance-driven solutions – Standard compliant ARF, AARF, SampleRate, Onoe, AMRR, CARA, … –Non-Standard compliant RBAR, OAR, etc. Can they adapt to all scenarios ? –Work well in some cases –Not so well in other cases

10 Design Guidelines in Existing Rate Adaptation Examine 10+ existing algorithms Performance-driven guidelines 1.Decrease rate upon severe loss 2.Use deterministic success/loss patterns 3.Use long-term statistics 4.Use probe packets 5.Use PHY-layer metrics Can they adapt well in all cases?

11 Guideline #1: Decrease transmission rate upon severe packet loss ARFAARFSampleRateFixed Rate UDP Goodput (Mbps) SenderReceiver Hidden Station A sender should switch to lower rates when it faces severe loss Logic: severe loss indicates bad channel hidden-station case? The sender performs worse with Rate Adaptation!

12 The sender should not decrease the rate upon collision losses –Decreasing rate increases collisions ! Guideline #1: Decrease transmission rate upon severe packet loss Severe loss Decrease Tx rate Increase Tx time Increase collision Prob. Fail to handle hidden-station!

13 Guideline #2: Use deterministic patterns to increase/decrease rate Case 1: 10 consecutive successes → increase rate –ARF, AARF 48Mbps 54Mbps increase rate!

14 Guideline #2: Use deterministic patterns to increase/decrease rate –The probability of a success transmission followed by 10 consecutive successes is only 28.5% Result: The rule has 71.5% chance to fail! 28.5%

15 Guideline #2: Use deterministic patterns to increase/decrease rate Case 2: 2 consecutive failures → decrease rate –ARF, AARF 54Mbps 48Mbps 36Mbps

16 Guideline #2: Use deterministic patterns to increase/decrease rate –The probability of a failure transmission followed by 2 consecutive failures is only 36.8% Result: The rule has 63.2% chance to fail! 36.8% Fail to handle random channel loss!

17 Guideline #3: Long-term statistics produces the best average performance Example: Use 10 seconds as sampling period –ONOE, SampleRate ONOE Performance Fail to handle short-term channel variations (include mobility)!

18 Design guidelines (cont’d) Other guidelines: –#4: Use probe packets to assess possible new rates –#5: Use PHY metrics like SNR to infer new transmission rate None of them can handle all possible scenarios

19 Step 2: How to adapt? RRAA solution components: Loss Estimation –Short-term statistics –Handle random loss mobility Adaptive RTS –Infer collision level –Handle collision Software Hardware PHY feedback MAC Adaptive RTS Loss Estimation Rate Selection send RTS Option RRAA

20 Loss Estimation Short-term statistics: –Loss ratio over short estimation window (20~100ms) –Channel coherence time –Exploit short-term opportunistic gain Threshold-based rate change: –if loss ratio > P MTL → rate decrease –if loss ratio < P ORI → rate increase –Otherwise, retain the current rate and continue sliding window

21 Illustrative Example For 9Mbps –ewnd = 10, P MTL = 39.32%, P ORI = 14.34% sssss s sXss sXsXXss X s ssXXsssssX 1 failure, loss ratio = 10% Increase rate 4 failures, loss ratio = 40% decrease rate 3 failures, loss ratio = 30% Rate unchanged s s s s 1.Robust to random channel loss - No deterministic pattern 2.Responsive to mobility - Short estimation window How to set these thresholds? (see Mobicom’06)

22 RTS/CTS Background Short control messages to protect lengthy data tx. RTS-CTS makes the yellow node back off during DATA-ACK Transmission RTS CTS Data Ack Step 1: Step 2: Backoff a b c a b c

23 Adaptive RTS Use RTS to handle collisions –Tradeoff between overhead and benefits of RTS Infer collision level –(1) Packet loss without RTS Possibly due to collisions Additively increase # of packets sent with RTS –(2) success without RTS, or (3) packet loss with RTS Most likely no collisions, or RTS doesn’t help Exponentially decrease # of packets sent with RTS

24 Illustrative Example RTScounterRTSwnd 00 DATA No collision Collision may occur More packets are sent with RTS if the collision level is high

25 Implementation Programmable AP using with embedded OS –Real-time tracing and feedback, per-frame control functionalities, etc

26 Implementation Challenges No floating point calculation in embedded AP –Translate increase/decrease thresholds to packet count No explicit signal for RTS loss –Check time duration of transmission Transmission time of a RTS frame is much shorter than that of a typical DATA frame

27 Step 3: Evaluate adaptation Experimental Setup –Controlled experiments: Midnight over clear channels on 11a/g –Field Trials: 4pm - 10pm weekdays in campus buildings, Channel 6, 7~11 other APs, 77~151 other clients, people walking around Enterprise setting –Stationary clients, mobile clients, hidden terminals Comparison with 4 other algorithms –ARF, AARF, SampleRate, Cisco

28 Field Trials Campus Environment –Compare with ARF, AARF, SampleRate –With realistic flow models –Results Statistic clients: will put later Mobile clients: will put later Enterprise setting –Compare with Cisco AP –Results: Average 70%, range 32.6%~212.3%

29 Summary Existing adaptive solutions tend to optimize performance in some scenarios, but overlooked others –Adaptation has to be done in the right form at the right time in the right way Need to identify all possible scenarios before develop a solution

30 Another look at Step 3 How well can it adapt? –Do existing evaluation approaches accurate enough over time ?

31 Revisiting wireless traffic flows A flow is a stream of packets –i.e. TCP flows (~90% of traffic) Internet

32 Findings Wireless traffic behaviors can be well captured by existing modeling approaches –But parameters also change over time ! Flow models need to be updated over time –Wireless networks are evolving over time –Study the evolution help us to understand better

33 Lesson Learnt Adaptations need to be used in correct way –Before develop a solution, we need to know “what to adapt to” –Otherwise it may hurt the performance Evaluation plans need to be updated over time –Static setting does not work –Outdated dynamic setting does not work too