TCP Problems in Multi-hop Wireless Networks

Ajit C. Warrier and Injong RheeNorth Carolina State University

TCP Problems in Wireless Networks

• Packet losses as congestion indications– Can’t distinguish channel/signal related losses

from congestion losses (buffer overflow).• But that is NOT an end-to-end congestion

control problem. – Can be easily fixed by replacing congestion

indications by explicit notifications (e.g., ECN).– Problems lie in different places.

Interference (Hidden Terminals)

• Hidden Terminals– Packets are lost due to collisions.

• Each transmitter retries transmission until it receives a MAC-level ACK for some time and then gives up.

• This reduces capacity. – Strictly a MAC-layer problem.

• MAC-layer solutions (e.g., RTS/CTS) can fix this problem, albeit with increased overhead.

Interference (Flows in the Middle)

• Competing flows subject to a different level of interference.

21 3

46

5

A

B

C

Flow B subject to more interference than flows A and C

Why is FIM a CC problem?(TCP can’t find an equilibrium.)

5

7

1 2 3 4

6

8

A

B

C

1. Initially flows A, B and C are sharing BW (not necessarily equally).

2. Node 2 is subject to more interference (from nodes 1, 3, and 6) than the other nodes, so congestion (buffer backlog) occurs at node 2.

3. But nodes 5 and 6 don’t have congestion (I.e., all packets drained at 7 and 8).

4. Congestion at node 2 causes the TCP source at node 1 to reduce its rate.

5. Then, that will reduce the interference at nodes 5 and 6 because node 2 is sending at a less rate. TCP sources at 5 and 6 see more available bandwidth; so they increase their rates causing more interference at node 2.

6. Congestion at node 2 does not reduce; source 1 further reduces its rate and sources 5 and 6 further increase their rates. The vicious cycle continues and flow B eventually starves.

WiseNet Testbed

• 50 nodes of Soekris 4826, 266Mhz CPU and 128MB SDRAM.

• MAC is Atheros IEEE 802.11 chipset (5212) using the MadWifi-NG driver.

DEMO I

DEMO I Configuration

• We use TFRC+ECN instead of TCP to remove the effect of packet losses on TCP sources.

• TFRC + ECN ignores all the losses and each router sets an ECN bit when congestion (queue overflow) occurs. TFRC uses TCP-style end-to-end congestion control.

• One 4-hop flow and four 1-hop flows.• 4-hop flow runs first and the other flows join

later one at a time. • Instantaneous throughput (average per

second) shown.

DEMO II

• Runs 60 flows at the same time.• Random source and destination pairs (not

MESH, but P2P traffic).• Routing using OLSR.• Iperf sources run for 120 seconds.

Result Preview

Starvation

Log scale (throughput)

CDF

ETX (loss rates)

Throughput

Stacked Bar graphs

Queue drops

Channel/collision losses

TCP

TFRC

IDEAL

Conclusions

• These are mostly due to FIM (flows in the middle).

• FIM is not a MAC layer problem only, but breaks end-to-end CC because competing flows are subject to different levels of congestion (interference).

• TCP and TFRC can experience more than 60% flows being starved in a dense network.

BACKUP SLIDES

Additional Slides (RTS/CTS)

TCP Reno with RTS/CTS

Scenario: TCP scalability on a wireless test-bed

• Large number (60 flows) of concurrent TCP transfers.

• P2P flow pattern (not a Mesh!).• (Source, Destination) chosen randomly

among nodes on the test-bed.• IPERF-generated flows run for 120s.• Routing using OLSR.

TCP problems

• TCP interaction with routing.– TCP flows affect routing probes (e.g. ETX

probes) (PAM, IMC 2007).– Effects: Unstable/unavailable routes.

• Interference/CSMA MAC unfairness.– Hidden Terminal Problem.– Flow in the Middle Problem. (MobiHoc 2006).– Effects: Unfairness or worse (starvation).

InterferenceHidden Terminal Case

• MAC collisions (excessive retries).

• May or may not lead to queuing/buffer overflows.

Flow in the Middle Case

• Buffer overflows on affected nodes.

• Usually no MAC excessive retries.