Enhancing TCP Fairness in Ad Hoc Wireless Networks Using Neighborhood RED Kaixin Xu, Mario Gerla University of California, Los Angeles {xkx, gerla}@cs.ucla.edu Lantao Qi, Yantai Shu Tianjin University, Tianjin, China {ltqi, ytshu}@tju.edu.cn * This work was supported in part by Office of Naval Research (ONR) "MINUTEMAN“ project under contract N00014-01-C-0016 and TRW under a Graduate Student Fellowship * This research was supported in part by the National Natural Science Foundation of China (NSFC) under grant No. 90104015.
Motivation � TCP is important in ad hoc network applications � Reliable transfer of data/image files and multimedia streaming � Congestion protection � Efficient utilization and fair share of the resources � However, TCP has shown unfair behavior in ad hoc nets 2
TCP Unfairness in Ad Hoc Networks � Fairness index in wireless networks � Weighted MaxMin Fairness Index � Weight(i) = # of flows that compete with flow i (including itself) (100, 100) (600, 100) FTP 1 2 n ∑ ( ) ( ) w t X t i i ( ) = = (350, 350) � i 1 , F X t 2 n ∑ ( ( ) ( ) ) n W t X t i i FTP 2 = (0, 700) (700, 700) i 1 (350, 700) � Simulation in QualNet simulator (350, 1050) � 3 TCP flows contending with each other FTP 3 � Weight of 3 flows, 2:3:2 (600, 1300) (100, 1300) 3
Significant TCP Unfairness � Three flow example � Flow 2 is nearly starved � Original RED fails to improve the fairness � Weighted Fairness Index = 0.67 4
Why RED Does Not Work? � Random Early Detection (RED) � Active queue management scheme ( ) = 1 − ∗ + ∗ � Average queue size: avg w avg w q q q − = max p avg ( min ) � Drop probability: , proportional to buffer p th − b max min th th occupancy � Why RED does not work in ad hoc networks? � Congestion simultaneously affects multiple queues � Queue at a single node cannot completely reflect the state � Extend RED to the entire congested area – Neighborhood of the node 5
Neighborhood and Its Distributed Queue � A node’s neighborhood consists of the node itself 8 and the nodes which can 7 interfere with this node’s 2 3 9 signal 1 � 1-hop neighbors directly A 4 12 interfere 6 � 2-hop neighbors may interfere 5 10 11 � Queue size of the neighborhood reflects the degree of local network congestion 6
Simplified Neighborhood Queue Model � 2-hop neighborhood queue model is not easy to operate � Too much overhead to propagate 2 queue values 2 hops away 1 3 � Simplified model A 4 � Only include 1-hop neighbors 6 � Two queues at each neighbor: � Outgoing queue 5 � “ Incoming queue” = # CTS packets overheard by A Outgoing Queue � Distributed neighborhood queue Incoming Queue – the aggregate of these local queues 7
Characteristics of Neighborhood Queue � Consists of multiple queues located at the neighboring nodes � Not a FIFO queue due to location dependency � Transmission order of sub-queues may change dynamically due to � Topology changes � Traffic pattern changes � TCP flows sharing the same neighborhood may get different feedbacks in terms of packet delay and loss rate 8
Neighborhood Random Early Detection (NRED) � Extending RED to the distributed neighborhood queue � Key Problems � Counting the size of the distributed neighborhood queue � Calculating proper packet drop probability at each node � Components of Neighborhood RED � Neighborhood Congestion Detection (NCD) � Neighborhood Congestion Notification (NCN) � Distributed Neighborhood Packet Drop (DNPD) 9
Neighborhood Congestion Detection � Direct way: Announce queue size upon changes � Too much overhead, exacerbates congestion � Our method: Indirectly estimate an index of instant queue size by monitoring wireless channel − − channel busy time = � Channel utilization ratio U busy − sampling int erval = � Queue size index , K is a constant q K * U busy 2 � Average queue size is calculated 1 3 CTS using RED’s alg. A Channel busy 4 6 � Congestion: queue size exceeds the 5 minimal threshold Outgoing Queue Incoming Queue 10
Neighborhood Congestion Notification & Distributed Neighborhood Packet Drop � Neighborhood Congestion Notification � Congested node computes drop probability following RED’s alg. � It broadcasts the drop probability to all neighbors � Distributed Neighborhood Packet Drop � Neighborhood Drop Prob = Max of all drop probabilities heard from neighbors 11
Verification of Queue Size Estimation TCP 4 TCP 5 TCP 6 (0,0) (350,0) (700,0) � Estimating Node5’s neighborhood 1 2 3 TCP 1 queue size index (0,350) (350,350) (700,350) 4 5 6 � Get real queue size by recording TCP 2 (0,700) (350,700) (700,700) queue size at all nodes 7 8 9 TCP 3 FTP Traffic HTTP Traffic 12
Parameter Tuning: Scenarios � QualNet simulator � Basic but typical scenarios � Hidden terminal situations � Exposed terminal situations � Configuration parameters � Minimum threshold & Maximum threshold � Set to 100 and 240 based on previous experiment � Vary the maximum packet drop probability (max p ) FTP 1 FTP 2 FTP 1 FTP 2 1 2 3 4 1 2 3 4 (100, 0) (100, 700) (100, 1050) (100, 350) (100, 0) (100, 700) (100, 1050) (100, 350) Exposed Terminal Hidden Terminal 13
Parameter Tuning: Hidden Terminal Scenario � Weighted fairness index ∆ D � Instantaneous throughput: , here denotes the = t X ( t ) ∆ t t → + ∆ data successfully received during time period [ t t ] t Fairness index Aggregated throughput 14
Parameter Tuning: Exposed Terminal Scenario Fairness index Aggregated throughput Instant throughput W/ max p = 0.14 15
Performance Evaluation: Simple Scenario (100, 100) (600, 100) FTP 1 � Both long-term and short-term (350, 350) fairness is achieved FTP 2 (0, 700) (700, 700) � Loss of aggregated throughput (350, 700) � Tradeoff between fairness and throughput (350, 1050) � Channel is not fully utilized FTP 3 (600, 1300) (100, 1300) Overall Throughput Instantaneous Throughput 16
Performance Evaluation: Multiple Congested Neighborhood � Multiple congested neighborhoods � FTP2 & FTP 5 have more competing flows, are more likely to be starved FTP 1 FTP 2 FTP 3 FTP 4 FTP 5 FTP 6 Overall Throughput 17
Performance Evaluation: Mobility 1 3 FTP 1 (0, 0) (400, 0) � Node 5 moves up and down (200, 150) 2 � Moving Up: two flow interfere with each 5' (200, 400) � Moving down: No much interference Node 5 moving up and down (200, 600) � NRED can adapt to mobility 5 4 6 FTP 2 (0, 650) (400, 650) Without NRED With NRED 18
Performance Evaluation: Realistic Scenario � 50 nodes randomly deployed in 1000mX1000m field � 5 FTP/TCP connections are randomly selected � AODV routing � No mobility 19
Conclusions � Significant TCP unfairness has been found and reported in ad hoc networks � NRED is a network layer solution � Easy to implement � Incremental deployment � Major Contributions � Model of neighborhood queue � Distributed neighborhood queue � Not FIFO, different and dynamic priorities � Network layer solution for enhancing TCP fairness in ad hoc networks 20
Thanks! 21
Recommend
More recommend
