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

Interference Hidden 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.