Congestion Control in Multi-hop Wireless Mesh Networks

1. Congestion Control in Multi-hop Wireless Mesh Networks Ihsan Ayyub Qazi

2. Background: Congestion Control • What is congestion? • A network state where the arrival rate exceeds the service rate • Throughput starts decreasing (due to packet losses) • Delay increases fast (queues build up) • Why does congestion occur? • No admission control • Where does congestion control take? • At the end hosts • congestion inferred from end-system observed loss and delay

3. Goals of Congestion Control • Avoid congestion • Avoid packet losses, keep delays low • Efficient use of resources • Given some demand, resource must be utilizable • Fair use of resources • Allocate resources according to a fairness criteria • Max-Min fairness • allocation is max-min fair if no rates can be increased without decreasing an already smaller rate

4. Transmission Control Protocol (TCP) Rule for adjusting W • If an ACK is received: W ← W+1/W • If a packet is lost: W ← W/2 Only Wpackets may be outstanding ihsan@cs.pitt.edu

5. Understanding Congestion Control in Multi-hop Wireless Mesh NetworksSumitRangwala, Apoorva Jindal, Ki-Young Jang, KonstantinosPsounis and RameshGovindan (MobiCom’08)Acknowledgement: following slides taken from SumitRangwala, USC.

6. Mesh Networks • Static multi-hop mesh networks have been proposed as an alternative to wired connectivity • User’s satisfaction hinges on transport performance • TCP’s performance on 802.11 mesh networks is known to be poor • Starvation Is poor transport performance inherent to multi-hop mesh networks? Can a correctly designed transport help make mesh networks a viable alternative?

7. TCP’s Performance 1 3 2 4 5 6 8 • TCP only signals flows traversing the congested link • Link centric view of congestion • Fails to account for neighborhood congestion 7 9 What mechanisms can help us achieve near-optimal rates? Optimal (Max Min) TCP

8. Approach Neighborhood-centric Transport AIMD Based Design Explicit Rate Notification WCP WCPCap

9. Neighborhood of a Link Link →sender receiver pair • Neighborhood of a link • All incoming and outgoing links of • Sender • Receiver • One hop neighbors of the sender • One hop neighbors of the receiver 9 1 7 2 5 6 8 4 10 3 Prohibits channel capture at the sender or causes collision at the receiver Ensuing ACK prohibits channel capture at the sender or causes collision at the receiver Prohibits channel capture Neighbors (overhearing)

10. WCP: AIMD Based Design Multiplicative Decrease When a link is congested, signal all flows traversing the neighborhood of a link to reduce their rate by half, i.e., rf = rf / 2 React to congestion after RTTneighborhood Key Insight: Congestion is signaled to all flows traversing neighborhood of a congested link

11. WCP Additive Increase During no congestion increase a flow’s rate as rf = rf + α Every RTTneighborhood RTTneighborhood : Largest flow RTT within the neighborhood Key Insight: Rate adaptation is clocked at the largest flow RTT in a neighborhood

12. Simulations: Stack Topology • Simulation setup • Qualnet 3.9.5 • 802.11b MAC with default parameters • TCP SACK • Auto rate adaptation is off • WCP achieves near optimal performance • Through congestion sharing in the neighborhood 1 3 2 4 5 6 8 7 9

13. Approach Neighborhood-centric Transport AIMD Based Design Explicit Rate Notification WCP WCPCap

14. WCPCap: Explicit Rate Feedback • Estimate residual capacity in a neighborhood • Need to know the achievable rate region for 802.11-scheduledmesh networks • Using only local information • Challenge: Is a given set of rates achievable in a neighborhood?

15. Calculating Achievable Rates Check feasibility, i.e., for each link, Packet arrival rate × E[service time of a packet] ≤ U, 0 ≤ U ≤ 1 Compute expected packet service time for a link from collision and idle probability of the link Decompose the neighborhood topology of a link into canonical two-link topologies Find collision and idle time probability of the link in every two-link topology Combine, incorporating local link dependencies, individual probabilities to find net collision and idle probabilities for the link Combine, incorporatinglink dependencies, individual probabilities to find net collision and idle probabilities of the link Using only local information Requires global information Jindal et. al., “The Achievable Rate Region of 802.11 Scheduled Multi-hop Networks”.

16. WCPCap: Explicit Rate Feedback • Every epoch • Find, by binary search, the largest increment or smallest decrement, δ, such that the new rates are achievable yet fair • Increase/decrease rate of each flow by δ U=1 (100% utilization) would yield large delays, we target U=0.7

17. Simulations: Stack Topology 1 3 2 4 5 6 8 • Simulation setup • Qualnet 3.9.5 • 802.11b MAC with default parameters • TCP SACK • Auto rate adaptation is off • WCPCap slightly better than WCP • Yields smaller queue and thus smaller delays • Not as good as optimal as we target 70% utilization 7 9 Optimal WCPCap TCP WCP

18. Simulations: Diamond Topology 1 3 • WCP does not achieve max-min rates • Rates are dependent on the number of congested neighborhood and the degree of congestion • WCPCap achieves max-min rates 2 4 5 6 8 7 9

19. Experimental Setup • Mini-PCs running Click and Linux 2.6.20 • ICOP eBox-3854 • 802.11b wireless cards running the madwifi driver • Omni directional antennas • some antennas covered with aluminum foils to reduce transmission range

20. Experimental Results: Stack Topology 1 3 2 4 5 6 8 7 9 Simulations Experiments For this topology, WCP’s simulation and experimental results are nearly identical

21. Experimental Results: Arbitrary Topology • 14 nodes and five flows • TCP starves different flows during different runs 18 18 23 23 10 10 24 24 16 16 22 22 12 12 26 26 13 13 15 15 19 19 11 11 20 20 14 14 WCP consistently gives fair rates

22. WXCP: Explicit Congestion Control for Wireless Multi-hop NetworksYang Su and Thomas Gross (IWQoS’05)

23. Motivation • In wireless networks, physical capacity is not fixed • Varies with the number of contending nodes and the traffic load in the neighborhood • CC Protocols (such as XCP) that rely on link capacity estimate for computing feedback tend to overestimate capacity • Gives rise to unfairness and fluctuating rates

24. Contribution • Proposes an extension to XCP for wireless networks • Estimates how much capacity a flow has for fair access by locally monitoring channels conditions • Proposes three metrics for measuring the state of resource usage and the level of congestion at a node • Available bandwidth • Interface queue length • Average link layer retransmission

25. Congestion Metrics • Available bandwidth • If estimation is made periodically, channel idle time represents network capacity still available during the estimation period =time used by station itself+physical carrier sense time+virtual carrier sense time

26. Congestion Metrics • Interface queue length • When input rate > output rate  queue builds up • Average link layer retransmission

27. Performance

28. Packet drop rate and Fairness

29. Grid Topology

30. Thanks !