TCP Problems in Multi-hop Wireless Networks

Ajit C. Warrier and Injong Rhee

North 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.