Congestion Control in Multi-hop Wireless Mesh Networks Ihsan Ayyub Qazi.
-
Upload
emery-george -
Category
Documents
-
view
217 -
download
0
Transcript of Congestion Control in Multi-hop Wireless Mesh Networks Ihsan Ayyub Qazi.
Congestion Control in Multi-hop Wireless Mesh Networks
Ihsan Ayyub Qazi
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
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
Transmission Control Protocol (TCP)
Only W packets may be outstanding
Rule for adjusting W If an ACK is received: W ← W+1/W If a packet is lost: W ←
W/2
Understanding Congestion Control in Multi-hop Wireless Mesh Networks
Sumit Rangwala, Apoorva Jindal, Ki-Young Jang, Konstantinos Psounis and Ramesh Govindan (MobiCom’08)
Acknowledgement: following slides taken from Sumit Rangwala, USC.
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?
6
1
2
3
4 5 6
7
8
9
TCP’s Performance
• TCP only signals flows traversing the congested link– Link centric view of congestion
• Fails to account for neighborhood congestion
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1Capacity Region with Optimal SchedulingAchievable Rate Region with 802.11
Rate of Each Outer Flow (Mbps)
Rate
of M
iddl
e Fl
ow (M
bps)
7
TCP
Optimal(Max Min)
What mechanisms can help us achieve near-optimal rates?
WCPCapWCP
Approach
AIMD Based Design
Neighborhood-centric Transport
8
Explicit Rate Notification
Neighborhood of a Link
2
4
5 6
7
8
Neighbors (overhearing)
10
• 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
3
91
Link → sender receiver pair
Prohibits channel captureProhibits channel capture at the sender or causes collision at the
receiverEnsuing ACK prohibits channel capture at the sender or causes
collision at the receiver
WCP: AIMD Based Design
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
Multiplicative Decrease
Key Insight: Congestion is signaled to all flows traversing neighborhood of a congested link
10
WCP
During no congestion increase a flow’s rate as rf = rf + α
Every RTTneighborhood
Additive Increase
Key Insight: Rate adaptation is clocked at the largest flow RTT in a neighborhood
RTTneighborhood : Largest flow RTT within the neighborhood
11
Simulations: Stack Topology
• WCP achieves near optimal performance – Through congestion sharing in the neighborhood
1
2
3
4 5 6
7
8
9TCP WCP Optimal
0
100
200
300
400
500
600
700
8001→34→67→9
Good
pu
t (k
bit
s/se
c)
12
• Simulation setup– Qualnet 3.9.5 – 802.11b MAC with default
parameters– TCP SACK– Auto rate adaptation is off
WCPCapWCP
Approach
AIMD Based Design
Neighborhood-centric Transport
13
Explicit Rate Notification
WCPCap: Explicit Rate Feedback
• Estimate residual capacity in a neighborhood– Need to know the achievable rate region for
802.11-scheduled mesh networks• Using only local information
14
Challenge: Is a given set of rates achievable in a neighborhood?
Combine, incorporating link dependencies, individual probabilities to find net collision and idle probabilities of the link Combine, incorporating local link dependencies, individual probabilities to find net collision and idle probabilities for the link
Calculating Achievable Rates
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
Compute expected packet service time for a link from collision and idle probability of the link
Check feasibility, i.e., for each link, Packet arrival rate × E[service time of a packet] ≤ U,
0 ≤ U ≤ 1
15Requires global informationUsing only local information
Jindal et. al., “The Achievable Rate Region of 802.11 Scheduled Multi-hop Networks”.
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 δ
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10
20
40
60
80
100
120
Utilization Factor (U)
Aver
age
End-
to-E
nd D
elay
(m
s)
U=1 (100% utilization) would yield large delays, we target U=0.7
16
TCPW
CP
WCPCap
Opt
imal
0
100
200
300
400
500
600
700
8001→3
4→6
7→9
Good
pu
t (k
bit
s/se
c)
Simulations: Stack Topology
• WCPCap slightly better than WCP– Yields smaller queue and thus smaller delays– Not as good as optimal as we target 70% utilization
1
2
3
4 5 6
7
8
9
17
• Simulation setup– Qualnet 3.9.5 – 802.11b MAC with default
parameters– TCP SACK– Auto rate adaptation is off
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1Capacity Region with Optimal SchedulingAchievable Rate Region with 802.11
Rate of Each Outer Flow (Mbps)
Rate
of M
iddl
e Fl
ow (M
bps)
TCP
OptimalWCPCap
WCP
Simulations: Diamond Topology
• 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
1
2
3
4 5 6
7
8
9TCP
WCP
WCPCap
Opt
imal
0
100
200
300
400
500
600
700
8001→3
4→6
7→9
Good
pu
t (k
bit
s/se
c)
18
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
19
TCP WCP Optimal0
100
200
300
400
500
600
700
8001→34→67→9
Good
pu
t (k
bit
s/se
c)
Experimental Results: Stack Topology1
2
3
4 5 6
7
8
9
TCPW
CP
Max
-Min
Ach
ieva
ble Rat
e0
200
400
600
8001→3
4→6
7→9
Good
pu
t (k
bit
s/se
c)
Simulations ExperimentsFor this topology, WCP’s simulation and experimental results are nearly identical
20
TCP WCP TCP WCPExperiment 1 Experiment 2
0
100
200
300
400
500
600 10→14
12→23
15→26
22→20
18→11
Goo
dput
(kbi
ts/s
ec)
10
26
14
121315
22
2423
16
1120
19
18
10
26
14
121315
22
2423
16
1120
19
18
Experimental Results: Arbitrary Topology
• 14 nodes and five flows• TCP starves different flows during different runs
WCP consistently gives fair rates
21
WXCP: Explicit Congestion Control for Wireless Multi-hop Networks
Yang Su and Thomas Gross (IWQoS’05)
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
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
Congestion Metrics
• Available bandwidth– If estimation is made periodically, channel idle
time represents network capacity still available during the estimation period
T
bwTB free.
busyfree TTT
=time used by station itself+physical carrier sense time+virtual carrier sense time
rt
j
tt
s
Congestion Metrics
• Interface queue length– When input rate > output rate queue builds up
• Average link layer retransmission
avgifq RtryQn
BT..
1
..
QSd ...
Performance
Packet drop rate and Fairness
Grid Topology
Thanks !