Time-based Fairness Improves Performance in Multi-rate WLANs Godfrey Tan and John Guttag MIT C omputer Science & Artificial Intelligence L aboratory
Outline Multi-rate WLANs support variable rates Problems with throughput-based fairness Alternate notion: time-based fairness What it is Why it’ s good How to achieve it (Time-based Regulator) Evaluation
WLANs Facilitate Varying Speeds Tradeoff between data rate and loss rate Multiple standards compete in same channel e.g b vs g TCP Throughput with RTS/CTS (Mbps) Sending at 5.5 Mbps is better
AP sees Multiple Rates Card manufactures implement auto-rate protocols Varying channel conditions at clients lead to rate diversity Percentage of Bytes Transmitted
Aggregate Throughput Reduced
Total throughput lower than expected Faster node suffers Slower node benefits Less incentive to upgrade to g
Root Cause: DCF’s “Fairness” Notion Carrier sense multiple access protocol Distributed randomized access Goal: equal number of frame transmissions Aim seems to be throughput-based fairness Assuming equal frame size and loss rate Irrespective of frame transmission time Consequence: Aggregate thruput closer to slower node’s n1 n2’sn1’s transmission time
Throughput-based Fairness (RF) Nodes achieve equal throughputs Suitable for Wired networks Single-rate wireless LANs R i = jIjI jj 1 1 R i : i’s achieved throughput j : j’s maximum achievable throughput I: the set of competing nodes
Not Efficient; Maybe Not Fair Throughput of node i should depend upon Number of competing nodes Transmission strategy used by node i Should not depend upon Transmission strategies used by other nodes Channel time is the shared resource Transmission opportunities are not
Time-based Fairness (TF) Nodes achieve equal channel time shares R i = ii | I || I | R i : i’s achieved throughput i : i’s maximum achievable throughput I: the set of competing nodes Desirable in multi-rate WLANs Node’s throughput depends only upon Its transmission strategy Number of competing nodes n1 n2n1
Throughputs Unchanged in Single-rate WLANs 11vs111vs111vs1 n1 at 11Mbps n2 at 11 Mbps RFTFRFTF 5.5vs5.52vs2
TF Improves Throughput in Multi-rate WLANs 11vs111vs111vs1 Total throughput improves by 115% Faster node achieves 273% more Slower node achieves 42% less
TF does not favor slower nodes 11vs111vs111vs1 Under RF, n1 achieves 84% of channel time Under TF, each node achieves 50%
Outline Multi-rate WLANs support variable rates Problems with throughput-based fairness Alternate notion: time-based fairness What it is Why it’ s good How to achieve it (Time-based Regulator) Results
How to Achieve Time-based Fairness? Is tweaking DCF enough? Each node still achieves equal chance to transmit Number of transmissions depends on data rate Faster node can transmit more in each opportunity No! Not enough for AP-based WLANs! Downlink frames are transmitted at varying data rates Existing queuing schemes lead to thruput-based fairness AP's queuing scheme needs modifications
How to Achieve Time-based Fairness? Is having N queues at the AP enough? One queue for each data rate Faster queue gets dequeued more in each round Dequeue 6 packets from 11-Mbps-queue & 1 from 1-Mbps-queue No! Non-uniform client distribution at queues problematic E.g. 6 users at 11 Mbps and 1 user at 1 Mbps leads to RF Per-client queuing, monitoring and policing necessary
Our Time-based Regulator (TBR) AP shapes traffic to clients, i.e. downlink only Monitors channel time usage of each client Account both downlink and uplink traffic Deal with differing loss rates and varying demands Transmit frames to node i Only if it has not utilized its share of channel time
Is Shaping Downlink Traffic Enough? Yes for feedback-based congestion controlled apps Limiting rate of downlink traffic slows sending rate Regardless of clients’ traffic directions E.g. Applications using TCP, RTCP, etc. No for non-congestion controlled apps Modify clients so that AP can ask them to slow down Drop packets if clients do not react appropriately E.g. Applications using raw UDP TCP makes up 90% of WLAN traffic [Tang02,Kotz02]
A TBR Implementation Only runs at AP; No modifications to clients Uses leaky buckets to shape downlink traffic Sets up a queue for each client Works with DCF Implemented in Linux HostAP Driver
TBR Impelementation Cont. tokens i : available channel time (seconds not bits) rate i : channel time share (e.g. 1/n) bucket i : maximum amount of tokens Policing: Packet to node i is transmitted if tokens i > 0 Tokens are periodically filled at rate i Accounting: For each packet P transmitted, tokens i -= chantime(P)
Example: TBR Operations AP n1 n2 1 Mbps 1 At t = 0, rate 1 = 0.5 rate 2 = 0.5 tokens 1 = tokens 2 = TCP Data 1 Mbps TCP Ack 1 Mbps TCP Data TCP Ack 11 At t = 0.074, tokens 1 = – = 0 tokens 2 = – = 0.05 From this time onwards, n1 can only use 50% of channel time.
Computing Channel Occupancy Time Total time used to transfer each layer-2 frame Take into account retransmissions AP knows lost frames in downlink direction For uplink direction Client marks each header with retry info., or AP estimates based on heuristics layer-2 acklayer-2 frame Idle Per-frame Channel Occupancy Time
Dealing with Varying Traffic Conditions Not all nodes need 1/n of capacity Achieves time-based max-min allocation Smallest rate i must be as large as possible Second smallest rate j must be as large as possible, etc. Periodically adjusts rate i to fully utilize channel If under-utilized, rate i is reduced Excess capacity redistributed among other nodes
TBR Achieves Higher Downlink Throughputs 5.5vs112vs111vs11 TBR achieves higher throughputs as analytically predicted
TBR Achieves Higher Uplink Throughputs 5.5vs112vs111vs11
Related Work Performance anomaly of b [Heusse et al., Infocom03] Opportunistic MAC protocol [Sadeghi et al., Mobicom02] e Qos Support (being drafted)
Conclusions Time-based fairness is desirable Better overall system performance In terms of throughput and completion time Faster nodes see significant improvement More incentive to upgrade to 11g Slower nodes not penalized severely APs shape downlink traffic to achieve TF Uplink & downlink must both be considered No modifications to clients or DCF necessary
TF Improves Wait Time in Multi-rate WLANs n1 transfers X Mbps at t 0 n2 transfers X Mbps at t 0 Under time-based fairness, n2 completes earlier at t 1 n1 completes later at t 2 Under throughput-based fairness Both n1 and n2 complete at t 2 n2 n1 t0t0 t1t1 t2t2 n2 n1 % of channel time used by n1
TBR Keeps Channel Utilization High TCP Throughput (Mbps) Varying sending rates TBR with DCF Max-min Allocation n1 at 11 MbpsAs fast as possible n2 at 11 Mbps Total Achieves max-min allocation Adapts to varying demands Redistributes excess capacity of underutilized nodes
TDMA TDMA provides equal time slots to clients each round Converges to time-based fairness If every node utilizes the entire slot each round Not very suitable for bursty traffic Time-based fairness notion: Provides predictable long-term channel time shares Under bursty traffic, varying demands and loss rates Compatible with any MAC protocol CSMA (e.g. DCF) TDMA (e.g. HiperLAN)
TF does not favor slower nodes 11vs111vs11 1vs1
Traffic Models Fluid Model Finite number of flows transfer infinite streams Efficiency measured by aggregate throughput Corresponds to very busy networks Task Model Finite number of flows transfer finite number of bits Efficiency measured by average & final completion time Corresponds to sometimes congested networks
Comparison CriteriaMeasureThroughput -based Time- based Fairness Throughput Channel Time Better Worse Better Efficiency (fluid) AggrThruput WorseBetter Efficiency (task) FinalTaskTime AvgTaskTime Same Worse Same Better
Long-term Time-share Guarantees Necessary
(d, s, I): baseline throughput Depends on data rate, frame size, contention and channel conditions Maximum total achieved throughput