1 / 16

TCP Problems in Multi-hop Wireless Networks

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

ginny
Télécharger la présentation

TCP Problems in Multi-hop Wireless Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP Problems in Multi-hop Wireless Networks Ajit C. Warrier and Injong Rhee North Carolina State University

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

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

  4. Interference (Flows in the Middle) • Competing flows subject to a different level of interference. Flow B subject to more interference than flows A and C 5 B 4 6 A C 1 2 3

  5. Why is FIM a CC problem?(TCP can’t find an equilibrium.) Initially flows A, B and C are sharing BW (not necessarily equally). 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. But nodes 5 and 6 don’t have congestion (I.e., all packets drained at 7 and 8). Congestion at node 2 causes the TCP source at node 1 to reduce its rate. Then, that will reduce the interference at nodes 5 and 6 because node 2 is sending at a less rate. TCPsources at 5 and 6 see more available bandwidth; so they increase their rates causing more interference at node 2. 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. 7 A 5 1 2 3 4 B 6 C 8

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

  7. DEMO I

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

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

  10. Result Preview Stacked Bar graphs CDF Queue drops TCP Channel/collision losses Starvation TFRC Log scale (throughput) Throughput IDEAL ETX (loss rates)

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

  12. BACKUP SLIDES

  13. Additional Slides (RTS/CTS) TCP Reno with RTS/CTS

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

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

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

More Related