TCP challenges in multi-hop wireless networksyuba.stanford.edu/trainwreck/tcp_mutlihop.pdf ·...

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, …)



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



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



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



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)



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



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



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



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



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



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



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…



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…

TCP challenges in multi-hop wireless networksyuba.stanford.edu/trainwreck/tcp_mutlihop.pdf ·...

Documents

Transcript of TCP challenges in multi-hop wireless networksyuba.stanford.edu/trainwreck/tcp_mutlihop.pdf ·...