1 / 50

Overview of Transport Problems in WLANs

Overview of Transport Problems in WLANs. Packet loss in wireless networks may be due to Bit errors Handoffs Congestion (rarely) Reordering (rarely, except for certain types of wireless nets) TCP assumes packet loss is due to Congestion Reordering (rarely)

william-walls
Download Presentation

Overview of Transport Problems in WLANs

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. Overview of Transport Problems in WLANs • Packet loss in wireless networks may be due to • Bit errors • Handoffs • Congestion (rarely) • Reordering (rarely, except for certain types of wireless nets) • TCP assumes packet loss is due to • Congestion • Reordering (rarely) • TCP’s congestion responses are triggered by wireless packet loss but interact poorly with wireless nets

  2. TCP Congestion Detection • TCP assumes timeouts and duplicate acks indicate congestion or (rarely) packet reordering • Timeout indicates packet or ACK was lost • Duplicate ACKs may indicate packet reordering • ACKs up through last successful in-order packet received • Called a “cumulative” ACK • After three duplicate ACKs, assume packet loss, not reordering • Receipt of duplicate ACKs means some data is still flowing

  3. TCP Congestion Control • Basic timeout and retransmission • If sender receives no ACK for data sent, timeout and retransmit • Go To Slow Start (Exponential back-off) • Timeout value based on mean and variance of RTT • Congestion “avoidance” (really congestion control) • Uses congestion window (cwnd) for more flow control • Cwnd set to 1/2 of its value when congestion loss occurred • Sender can send up to minimum of advertised window and cwnd • Then, additive increase cwnd (at most 1 at each RTT) • Careful way to approach limit of network

  4. TCP Congestion Control (cont’d) • Slow start – used to initiate a connection or after a timeout • Set cwnd to 1 segment • At each ACK, increase cwnd by 1 segment (exponential increase) • Aggressive way of building up bandwidth for flow • Switch to congestion avoidance once cwnd is one half of what it was when congestion occurred • Fast retransmit and fast recovery • After three duplicate ACKs, assume packet loss, data still flowing • Sender resends missing segment • Set cwnd to ½ of current cwnd plus 3 segments • For each duplicate ACK, increment cwnd by 1 (keep flow going) • When new data acked, do regular congestion avoidance

  5. Poor Interaction with TCP • Packet loss due to channel noise or mobility • Enter congestion control • Slow increase of cwnd • Bursts of packet loss and hand-offs • Timeout • Enter slow start (very painful!) • Cumulative ACK scheme not good with bursty losses • Missing data detected one segment at a time • Duplicate ACKs take a while to cause retransmission • TCP Reno may suffer coarse time-out and enter slow start! • TCP New Reno still only retransmits one packet per RTT

  6. Solution Categories • Entirely new transport protocol • Hard to deploy widely • End-to-end protocol needs to be efficient on wired networks too • Must implement much of TCP’s flow control • Modifications to TCP • Maintain end-to-end semantics • May or may not be backwards compatible • Split-connection TCP • Breaks end-to-end nature of protocol • May be backwards compatible with end-hosts • State on basestation may make handoffs slow • Extra TCP processing at basestation

  7. Solution Categories (Cont’d) • Link-layer protocols • Invisible to higher-level protocols • Does not break higher-level end-to-end semantics • May not shield sender completely from packet loss • May adversely interact with higher-level mechanisms • May adversely affect delay-sensitive applications • Snoop protocol • Does not break end-to-end semantics • Like a LL protocol, does not completely shield sender • Only soft state at base station – not essential for correctness

  8. End-to-end Solution Approaches • Sender is aware of the existence of wireless hops. • E2E (Reno): no support for partial ACKs • E2E-NewReno: partial ACKs allow further packet retransmissions • E2E-Selective Acknowledgments (SACK): ACK describes 3 received non-contiguous ranges • E2E-SMART: cumulative ACK with sequence # of packet causing ACK • Sender uses info for bitmask of okay packets • Ignores possibility that holes are due to reordering • Easier to generate and transmit acks

  9. End-to-end Solution Approaches (Cont’d) • E2E-ELN: Explicit Loss Notification • Receiver gets corrupted packet • Instead of dropping it, TCP gets it, generates ELN message with duplicate ACK • Entire packet dropped? • Base station generates ELN messages to sender with ACK stream

  10. Performance Results of E2E Protocols • E2E (Reno): coarse-grained timeouts really hurt • Throughput less than 50% of maximum in local area • Throughput of less than 25% in wide area • E2E-New Reno: avoiding timeouts helps • Throughput 10-25% better in LAN • Throughput twice as good in WAN • ELN techniques avoid shrinking congestion window • Over two times better than E2E • E2E-ELN-RXMT (ELN+Fast Retransmissions) only a little better than E2E-ELN • Enough data in pipe usually to get fast retransmit from ELN • Bigger difference with smaller buffer size • Not as much data in pipe (harder to get 3 duplicate acks)

  11. Performance Results of E2E Protocols (Cont’d) • E2E selective acks (SACK): • Over twice as good as E2E • Not as good as best LL schemes (10% worse on LAN, 35% worse in WAN) • Problem is still shrinkage of congestion window

  12. Split-connection Protocols • Goal: to hide any non-congestion-related losses from the TCP sender. • Attempt to isolate TCP source from wireless losses • TCP connection is split between a sender and receiver into two separate connections at the base station: • TCP connection over wired link; • Specialized protocol over wireless link. • TCP sender over wireless link performs all retransmissions in response to losses • SPLIT (I-TCP): uses TCP Reno over wireless link • SPLIT-SMART: uses SMART-based selective acks

  13. Split Connection Approach • Connection between wireless host MH and fixed host FH goes through base station BS • FH-MH = FH-BS + BS-MH FH BS MH Fixed Host Base Station Mobile Host

  14. FH BS MH Fixed Host Base Station Mobile Host Split Connection Approach • Split connection results in independent flow control for the two parts • Flow/error control protocols, packet size, time-outs, may be different for each part

  15. I-TCP: Indirect TCP I-TCP TCP MSR MH FH • MH = Mobile Host • MSR = Mobile Support Router • FH = Fixed Host

  16. Indirect-TCP Protocol • Different flow control and congestion control for wireless and wired links; • Separate transport protocol supports disconnections, moves and other wireless related features; • Faster reaction to mobility due to proximity between MSR and MH. • MSR manages much of the overhead

  17. MH socket MH socket MH MH MSR-1 MSR-1 FH I-TCP Basics move Wireless TCP I-TCP Handoff MSR1 fhsocket MSR2 fhsocket Regular TCP MSR-2 MSR1 mhsocket MSR2 mhsocket FH socket

  18. I-TCP • Built on top of a mobile IP • MSR acts a proxy to the MH • it fakes an image of the MH and hands this to a new MSR during cell switches • Assuming no MSR failures and indefinite MH disconnection, I-TCP does not compromise end-to-end reliability. • Well-suited for throughput intensive applications

  19. Split Connection Approach Advantages: • Simple Implementation • Backward compatible to TCP fixed hosts • FH unaware of MSRs • Separates flow and congestion control of the wireless and wired link • Can optimize FH-MSR connection independently - different protocols, MTUs • Can support notifications that can be used by link and location aware applications

  20. Split Connection Approach Disadvantages: • Violation of end-to-end semantics • MSR maintains state • MSR failure can cause connection loss • Hand-off latency increases due to state transfer • Unless optimized, extra copying of data at MSR

  21. Performance of Split Approaches • SPLIT: • Wired goodput 100% since no retransmissions there • Eventually stalls when wireless link times out • Buffer space limited at base station • SPLIT-SMART: • Throughput better than SPLIT (at least twice as good) • Better performance of wireless link avoids holding up wired links as much • Split connections not as effective as TCP-aware LL protocol, which also avoids splitting the connection

  22. Link Layer Approaches • LL: TCP-like behavior with cumulative acks and retransmit granularity faster than TCP’s • LL-SMART: addition of selective retransmissions • Cumulative ack with sequence # of of packet causing ack • LL-TCP-AWARE: Snoop protocol • At base station cache segments • Detect and suppress duplicate acks • Retransmit lost segments locally • LL-SMART-TCP-AWARE: Combination of selective acks and duplicate ack suppression

  23. Snoop Protocol Design Goals: • Improved Performance • No change to TCP at fixed hosts • No violation of end-to-end TCP semantics • No recompiling/relinking of existing applications

  24. FH BS MH Snoop Protocol • Buffers data packets at the base station BS • to allow link layer retransmission • When dupacks received by BS from MH, retransmit on wireless link, if packet present in buffer • Prevents fast retransmit at TCP sender FH by dropping the dupacks at BS

  25. Per TCP-connection state TCP connection application application application transport transport transport network network network rxmt link link link physical physical physical FH BS MH wireless Snoop Protocol

  26. Snoop Protocol Advantages: • High throughput can be achieved • performance further improved using selective acks • Local recovery from wireless losses • Fast retransmit not triggered at sender despite out-of-order link layer delivery • End-to-end semantics retained • Soft state at base station • loss of the soft state affects performance, but not correctness

  27. Snoop Protocol Disadvantages: • Link layer at base station needs to be TCP-aware • Not useful if TCP headers are encrypted (IPsec) • Cannot be used if TCP data and TCP acks traverse different paths (both do not go through the base station)

  28. Link Layer Approaches Results • Simple retransmission at link layer helps, but not totally • Combination of selective acks and duplicate suppression is best • Real problem is link layers that allow out-of-order packet delivery, triggering duplicate acks, fast retransmission and congestion avoidance in TCP • Overall, want to avoid triggering TCP congestion handling techniques

  29. Summary • Good TCP-aware LL shields sender from duplicate acks • Avoids redundant retransmissions by sender and base station • Adding selective acks helps a lot with bursty errors • Split connection with standard TCP shields sender from losses, but poor wireless link still causes sender to stall • Adding selective acks over wireless link helps a lot • Still not as good as local LL improvement • E2E schemes with selective acks help a lot • Still not as good as best LL schemes • Explicit loss E2E schemes help (avoid shrinking congestion window) but should be combined with SACK for multiple packet losses

  30. Summary • TCP-aware link-layer protocol (Snoop) with selective acknowledgments performs the best; • Split-connection approaches is not a requirement for good performance. • Selective acknowledgment is very useful in lossy links, especially for burst losses. • Explicit Loss Notification is worth to try.

  31. Overview of Transport Problems in Ad Hoc Networks • Effect of route reconstruction/repair • Effect of network partitioning/merging, multi-path routing • Sender mistakes the delay of ACK arrival and increases RTT as a sign of congestion • Sender begins to reduce window size • High bit error rates • problem amplified with multiple hops • Out-of-order packet delivery • frequent route changes may cause out-of-order delivery • Half-duplex radios • cannot send and receive packets simultaneously • changing mode (send or receive) incurs overhead

  32. Multi-Hop Paths • May need to traverse multiple links to reach a destination

  33. Multi-Hop Paths • Mobility causes route changes

  34. mobility causes link breakage, resulting in route failure Route is repaired TCP sender times out. Starts sending packets again No throughput No throughput despite route repair TCP data and acks en route discarded Throughput Degradation with Route Failure

  35. TCP sender times out. Resumes sending mobility causes link breakage, resulting in route failure TCP sender times out. Backs off timer. Route is repaired No throughput No throughput despite route repair Larger route repair delays especially harmful TCP data and acks en route discarded Throughput Degradation with Route Failure

  36. Caching and TCP Performance • Caching can reduce overhead of route discovery even if cache accuracy is not very high • But if cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple time-outs

  37. Impact of MAC - Delay Variability • As wireless medium is shared between multiple sources, the round-trip delay is variable • Also, on slow wireless networks, delay is large • made larger by send-receive turnaround time • Large and variable delays result in larger RTO • On packet loss, timeout takes much longer to occur • Idle source (waiting for timeout to occur) lowers TCP throughput

  38. Out-of-Order Packet Delivery • Route changes may result in out-of-order (OOO) delivery • Significantly OOO delivery confuses TCP, triggering fast retransmit • Potential solutions: • Avoid OOO delivery by ordering packets before delivering to IP layer • can result in variable delay • turn off fast retransmit • can result in poor performance in presence of congestion

  39. How to Solve? • Network feedback • Inform TCP of route failure by explicit message • Let TCP know when route is repaired • Probing • Explicit notification • Reduces repeated TCP timeouts and backoff

  40. Network Feedback • Network knows best (why packets are lost) • Network feedback beneficial • Need to modify transport & network layer to receive/send feedback • Need mechanisms for information exchange between layers

  41. ATCP: Ad Hoc TCP • ATCP = ad hoc TCP • Considers packet loss due to: • Bit Errors • Route Re-computation • Network Partitioning • Multi-path Routing • Maintains TCP congestion control behaviour • Is compatible with TCP standard

  42. TCP TCP ATCP IP Design of ATCP • Transparent layer between standard TCP and IP. • Standard TCP is unmodified. • Nodes with and without ATCP can interoperate. • Only used on sender-side. • Monitors TCP and Network state based on Explicit Congestion Notification (ECN) and Internet Control Management Protocol (ICMP) messages

  43. ATCP State Transition Diagram

  44. Loss State • Normal  Loss state transition occurs when packet loss due to high BER channel implied: • ATCP sees that TCP’s RTO is about to expire OR • ATCP receives 3 duplicate acknowledgements. • ATCP retransmits lost packet(s) instead of TCP. • When new acknowledgement arrives, • ATCP passes it to TCP • TCP exits persist mode • State transition from Loss  Normal

  45. Congested State • Normal  Congested state transition occurs when sender receives TCP acknowledgement with explicit congestion notification (ECN) bit set. • ECN bit set in TCP acknowledgement when router detects congestion (instead of dropping the packet). • ATCP does nothing in congested state: • Ignore imminent RTO and • Ignore duplicate acknowledgements • TCP would behave as normal • When TCP transmits a new packet, ATCP transitions from Congested  Normal.

  46. Disconnected State • Normal  Disconnected state transition occurs when ICMP Destination Unreachable packet received. • ICMP Destination Unreachable packet generated by network in response to a packet being sent to an unreachable node. • TCP continuously transmits probe packets. • When acknowledgement to probe packet is received, this means destination node is no longer disconnected.

  47. Summary • Much work on routing in ad hoc networks • Some recent work on TCP for ad hoc networks • Need to investigate many issues • MAC-TCP interaction • routing-TCP interaction • impact of route changes on window size, RTO choice after move

  48. References [1] Hari Balakrishnan, Srinivasan Seshan and Randy H.Katz, “Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks”, ACM Wireless Networks, May 1995 [2] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan and Randy H.Katz, “A Comparison of Mechanisms for Improving TCP Performance over Wireless Links”, ACM SIGCOMM 1996. [3] A.Bakre and B.R.Badrinath, “I-TCP: Indirect TCP for Mobile Hosts”,Proc. 15th Int’l Conf. on Distributed Computing Systems, May 1995 [4] A.Bakre and B.R.Badrinath, “Implementation and Performance Evaluation of Indirect TCP”, IEEE Transactions on Computers, March 1997 [5] RFC 2001 – TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery

  49. References [6] J. Liu and S. Singh, "ATCP: TCP for mobile ad hoc networks,“ IEEE JSAC, vol. 19, no. 7, pp. 1300-1315, July 2001. [7] K. Sundaresan, V. Anantharaman, H.-Y. Hsieh, and R. Sivakumar, “ATP: A Reliable Transport Protocol for Ad-hoc Networks." Proc. ACM MOBIHOC 2003, Annapolis, MD USA, June 2003.

More Related