View
221
Download
1
Embed Size (px)
Citation preview
1
How to apply Adaptation principle: case study in 802.11
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 802.11
• 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
54MbpsSignal is goodSignal becomes weaker
12Mbps
6
IEEE 802.11 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 802.11 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– 802.11 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 guidelines1. Decrease rate upon severe loss2. Use deterministic success/loss patterns3. Use long-term statistics4. Use probe packets5. Use PHY-layer metrics
• Can they adapt well in all cases?
11
Guideline #1: Decrease transmission rate upon severe packet loss
ARF AARF SampleRate Fixed Rate
UDP Goodput (Mbps)
0.65 0.56 0.58 1.46
SenderReceiverHiddenStation
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
Severeloss
DecreaseTx
rateIncrease
Txtime
Increasecollision
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
PHYfeedba
ck
802.11 MAC
AdaptiveRTS
Loss EstimationRate Selection send
RTSOption
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 > PMTL → rate decrease
– if loss ratio < PORI → rate increase
– Otherwise, retain the current rate and continue sliding window
21
Illustrative Example• For 9Mbps
– ewnd = 10, PMTL = 39.32%, PORI = 14.34%
s s s s s s s X s s
s X s X X s s Xs
s s X X s s s s s X
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
RTScounter RTSwnd
0 0
DATA1 1
0 1DATA
2 2
1 1
0 1
0 0
0 0
DATA
DATA
DATA
DATA
DATA
No collision
No collision
Collision may occur
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