Enhancing TCP Fairness in Ad Hoc Wireless Networks Using Neighborhood RED

1. 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

2. Motivation • TCP is important in ad hoc network apps • 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

3. TCP Unfairness in Ad Hoc Networks • 3 TCP flows contending with each other • Flow 2 is nearly starved • Original RED fails to improve the fairness

4. Why RED Does Not Work? • Random Early Detection (RED) to improve fairness • Active queue management scheme • 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 – Neighborhoodof the node • Average queue size: • Drop probability: , proportional to buffer occupancy

5. Neighborhood and Its Distributed Queue • A node’s neighborhood consists of the node itself and the nodes which can interfere with this node’s signal • 1-hop neighbors directly interfere • 2-hop neighbors may interfere • 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 queue values 2 hops away • Simplified model • Only include 1-hop neighbors • Two Qs at each neighbor: • Outgoing queue • “Incoming queue”= # CTS packets OH by A • Distributed neighborhood queue – the aggregate of these local queues

7. Neighborhood Random Early Detection (NRED) • Extending RED to the distributed neighborhood queue (Virtual) • 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)

8. CTS Channel busy Neighborhood Congestion Detection • Direct way: Announce queue size upon changes • Too much overhead, queue location problem? • Our method: Indirectly estimate an index of instant queue size by monitoring wireless channel • Average queue size is calculated using RED’s alg. • Congestion: queue size exceeds the minimal threshold • Channel utilization ratio • Queue size index K is a constant

9. Neighborhood Congestion Notification & Distributed Neighborhood Packet Drop • Neighborhood Congestion Notification • Congested node computes drop probability following RED’s alg. • It broadcaststhe drop probability to all neighbors • Distributed Neighborhood Packet Drop • Neighborhood Drop Prob = Max of all drop probabilities heard from neighbors

10. Performance Evaluation: Simple Scenario • Both long-term and short-term fairness is achieved • Loss of aggregated throughput • Tradeoff between fairness and throughput • Channel is not fully utilized Overall Throughput Instantaneous Throughput

11. Performance Evaluation: Multiple Congested Neighborhood • Multiple congested neighborhoods • FTP2 & FTP 5 have more competing flows, are more likely to be starved Overall Throughput

12. Lessons learned • TCP unfairness has been found in ad hoc networks • Notion of “wireless neighborhood” key to solve the “capture” problem -- > • NRED for enhancing TCP fairness in ad hoc nets • Good example of “cross layer” interaction (network drops packets to let TCP know..) • Network layer solution ??? • Easy to implement ??? • Work in progress: • Implementation of proposed schemes in the Linux testbed • Measuring channel utilization rate is an over-layer solution and hardly to implement in practice • Performance measurement

13. MAC Delay Based NRED Scheme Node with the maximum MAC delay (Q size) is not the congestion center node, but the previous hop of the congestion center Fig. 6. Congestion detection and notification

14. Packet drop probability for MAC delay based NRED

15. Simulation results optimal parameters: maxp = 0.5 maxth = 0.12 minth = 0.07 Fig. 8. Performances at different parameters

16. Adaptive Pause scheme • Queue length based NRED and MAC Delay Based NRED schemes • can not directly find congestion center • congestion notification - hard • RED: optimal parameters setting ? • 被动：等待受压制节点发出通知才开始控制发包，对网络中的不公平现象反应慢，而且发送消息造成额外的带宽开销。 • 主动：获得竞争无线信道优势的节点要自律 •  Adaptive Pause

17. Adaptive Pause scheme • Each node monitors its bandwidth occupation and the number of its active neighbor nodes • Instead of detecting congestion, the nodes which occupy too much bandwidth, will reduce their sending rate by themselves • If the bandwidth exceeds the threshold, the node will pause an interval to stop sending

18. Markov model for Adaptive_Pause scheme

19. Simulation result Throughput of Adaptive_Pause and D_NRED (Adaptive_Pause parameters: Tp=1.5 s，R=0.5)

20. Simulation result (Adaptive_Pause) Flow 2 throughput ~ parameters: Tp，R

21. Simulation result (Adaptive_Pause) Flow 2 throughput ~ parameters: Tp，R

22. Experiment result on TJU testbed f