Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Konstantinos Psounis October 2007
University of Southern California 1
TCP challenges in multi-hopwireless networks
Konstantinos PsounisAssistant Professor
EE and CS departments, USC
Joint work with Vlad Balan, Ramesh Govindan, Ki-Young Jang, Apoorva Jindal, Sumit Rangwala
2
Why multi-hop?
Easy to deploy
Easy to upgrade
Inexpensive
The only option for some killer applications, e.g. disaster recovery networks vehicular ad hoc networks environmental monitoring (underwater, forests, …)
Konstantinos Psounis October 2007
University of Southern California 2
3
Why not multi-hop?
Bad performance e.g. consider a mesh network using TCP over de facto MAC
standard (802.11)throughput reduces significantly after 3 hopssevere capture effects which leads to extreme unfairness
But, is this inherent to multi-hop, or we don’t do thingsright? Specifically, is TCP regulating the end-to-end rates properly?
4
In case of congestion TCP signals congestion to sources and “fairly”
shares capacity
Congestion in the wired world
f1, r1
f2, r2
l1,C1
Konstantinos Psounis October 2007
University of Southern California 3
5
Congestion in the multi-hop wireless world
f1, r1
f2, r2
f3, r3
f4, r4
f5, r5
l1,C1
Assume, for simplicity, a single disk model for transmission andinterference range
C1=f(…,r3,r4,r5,…)
SR
6
An example
Konstantinos Psounis October 2007
University of Southern California 4
7
Outline
AIMD basics and TCP
What’s the cause of trouble and how to fix it Congestion is a neighborhood, not a single-link affair
Simulation results
Experimental results
“fixed” AIMD scheme: evolution of TCP or a newprotocol?
8
AIMD basics and TCP
AIMD basics: rf: rate of flow f upon congestion
• rf = rf / β• react again to congestion after tMD
else• rf = rf + α• every tAI
TCP: recall that r = W / RTT β = 2 ⇒ rf = rf / 2 α = 1 / RTT ⇒ rf = rf + 1 / RTT tMD = tAI = RTT
Konstantinos Psounis October 2007
University of Southern California 5
9
What is wrong with TCP
Congestion is a neighborhood, not a single link affair
Define what is the neighborhood of a link Translate the basic AIMD features in the context of a
neighborhood-centric world
10
Neighborhood of a link
1
3
2
4
5 6
7
8
9
10
All incoming and outgoing links from the sender, receiver, all the one-hop neighbors of sender, and all the one-hop neighbors of receiver
Neighbors (overhearing)
Konstantinos Psounis October 2007
University of Southern California 6
11
Neighborhood-centric world
In a neighborhood-centric world we want toshare information within the neighborhood:1. Congestion notifications2. “Clocking” information, i.e. tMD and tAI
Congestion sharing is conceptually easy upon congestion inform neighboring nodes/links neighbors inform flows that traverse them sources react to congestion
Sharing “clocking” information is a bit moreinvolved
12
From flow RTT to neighborhood RTT
TCP clocks window increases and decreases with eachflow’s RTT silent adaptation to network dynamics: as congestion
increases, rate of increase reduces We want to do the same at a neighborhood level
use the same value for all flows traversing a neighborhood
One option: let RTTi→j be the max RTT among all RTTs of flows traversing
link i→j let RTTi→j
n be the max RTT among all RTTi→js of links in the
neighborhood of link i→j use this “neighborhood” RTT
Konstantinos Psounis October 2007
University of Southern California 7
13
Simulation setup
Qualnet-based simulations 802.11b MAC with default parameters
• 11Mbps, 512bytes DATA packets Zero channel loses
• packet loses due to collision and interference do occur Buffer size: 64 packets 4 qualitatively different topologies
Schemes: TCP with SACK and ECN Max-min optimal rate allocation “Neighborhood-centric” AIMD-scheme (which shares
congestion and clocking information within a neighborhood)
14
How to find if a link is congested• number of links it interferes with• number of asymmetric links
Stack topology (flow in the middle)
S1 S2R1 R2
Konstantinos Psounis October 2007
University of Southern California 8
15
Stack topology (flow in the middle)
TCP starves middle flow Sharing congestion within the neighborhood of link 4→5 improves
performance dramatically nodes 2 and 8 react to congestion at link 4→5
16
Diamond topology
Congested links/neighborhoods are different from stack TCP again starves flows that traverse congested links Sharing congestion within the neighborhoods yields better performance
flow in the middle traverses both congested neighborhoods result implies “proportional fairness” type of behavior
Konstantinos Psounis October 2007
University of Southern California 9
17
Half-diamond topology
TCP does well here Neighborhood AIMD is slightly worse because it is not particularly
optimized
18
Chain-cross topology
TCP again starves flows going through congested links Sharing congestion information within the neighborhoods yields
close to optimal performance
Konstantinos Psounis October 2007
University of Southern California 10
19
Experimental setup
mini-PCs running Click and Linux 2.6.20 ICOP eBox-3854
wireless cards running the madwifi driver Senao NMP-8602
one omni directional antenna per mini-PC, 18dBm transmissionpower some antennas covered with aluminum to reduce transmission range
20
Experimental setup (cont.)
Parameters (radio rates, packet sizes, etc.) same as in simulations 3 qualitatively different topologies
two man-made one arbitrary topology of 15 nodes
All experiments performed at night-time for repeatability external interference limited but present
Konstantinos Psounis October 2007
University of Southern California 11
21
Stack topology
3 nodes at each floor in 3 consecutive floors Experiments in line with simulations Note: Max-min optimal (computed using brute-force) does not yield equal
rates because external interference is different for each flow depending on the
building floor
3 nodes at each floor in 3 consecutive floors
22
Chain-cross topology
Same behavior as before
Konstantinos Psounis October 2007
University of Southern California 12
23
Similar behavior as before Note: brute-force computation of max-min rates harder
to do here…
Arbitrary topology
10
26
14
12
1315
22
24
23
16
11
20
19
1718
10
26
14
12
1315
22
24
23
16
1120
19
1718
24
Effect on application layer
Consider the stack topology HTTP connection: 4→5→6
download a number of pictures totaling 900K Three cases
1. no other flows2. one FTP flow on 1→2→33. two FTP flows, one on 1→2→3 and one on 7→8→9
Under case 3. the connection timeouts (no completioneven after 10min) show videos…
Konstantinos Psounis October 2007
University of Southern California 13
25
Evolution or a new scheme?
Summarize: TCP can be spectacularly bad over 802.11-scheduled multi-
hop networks “Translating” key AIMD features to a neighborhood-centric
world can fix the problem
Required changes could be retrofitted into TCP … but are rather major Neighborhood-centric designs can be viewed as
evolution of AIMD schemes to account for complexinterference but not as evolution of TCP…