1. TRANSPORT PROTOCOLS FOR WLANs and AD HOC NETWORKS Ian F. Akyildiz Broadband & Wireless Networking Laboratory School of Electrical and Computer Engineering Georgia Institute of Technology Tel: 404-894-5141; Fax: 404-894-7883 Email: ian@ece.gatech.edu Web: http://www.ece.gatech.edu/research/labs/bwn

2. IFA’2004 2 Overview of Transport Problems in WLANs Packet loss in wireless networks may be due to 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 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 TCP’s congestion responses are triggered by wireless packet loss but interact poorly with wireless nets

3. IFA’2004 3 TCP Congestion Detection TCP assumes timeouts and duplicate acks indicate congestion or (rarely) packet reordering TCP assumes timeouts and duplicate acks indicate congestion or (rarely) packet reordering Timeout indicates packet or ACK was lost Timeout indicates packet or ACK was lost Duplicate ACKs may indicate packet reordering 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

4. IFA’2004 4 TCP Congestion Control Basic timeout and retransmission 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) 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

5. IFA’2004 5 TCP Congestion Control (cont’d) Slow start – used to initiate a connection or after a timeout 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 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

6. IFA’2004 6 Poor Interaction with TCP Packet loss due to channel noise or mobility Packet loss due to channel noise or mobility –Enter congestion control –Slow increase of cwnd Bursts of packet loss and hand-offs Bursts of packet loss and hand-offs –Timeout –Enter slow start (very painful!) Cumulative ACK scheme not good with bursty losses 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

7. IFA’2004 7 Solution Categories Entirely new transport protocol 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 Modifications to TCP –Maintain end-to-end semantics –May or may not be backwards compatible Split-connection TCP 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

8. IFA’2004 8 Solution Categories (Cont’d) Link-layer protocols 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 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

9. IFA’2004 9 End-to-end Solution Approaches Sender is aware of the existence of wireless hops. Sender is aware of the existence of wireless hops. E2E (Reno): no support for partial ACKs E2E (Reno): no support for partial ACKs E2E-NewReno: partial ACKs allow further packet retransmissions E2E-NewReno: partial ACKs allow further packet retransmissions E2E-Selective Acknowledgments (SACK): ACK describes 3 received non-contiguous ranges E2E-Selective Acknowledgments (SACK): ACK describes 3 received non-contiguous ranges E2E-SMART: cumulative ACK with sequence # of packet causing ACK 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

10. IFA’2004 10 E2E-ELN: Explicit Loss Notification 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 Base station generates ELN messages to sender with ACK stream End-to-end Solution Approaches (Cont’d)

11. IFA’2004 11 Performance Results of E2E Protocols E2E (Reno): coarse-grained timeouts really hurt 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 E2E-New Reno: avoiding timeouts helps –Throughput 10-25% better in LAN –Throughput twice as good in WAN ELN techniques avoid shrinking congestion window 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 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) Not as much data in pipe (harder to get 3 duplicate acks)

12. IFA’2004 12 E2E selective acks (SACK): 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 Performance Results of E2E Protocols (Cont’d)

13. IFA’2004 13 Split-connection Protocols Goal: to hide any non-congestion-related losses from the TCP sender. Goal: to hide any non-congestion-related losses from the TCP sender. Attempt to isolate TCP source from wireless losses 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 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 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

14. IFA’2004 14 Split Connection Approach Connection between wireless host MH and fixed host FH goes through base station BS Connection between wireless host MH and fixed host FH goes through base station BS FH-MH = FH-BS + BS-MH FH-MH = FH-BS + BS-MH FHMHBS Base StationMobile Host Fixed Host

15. IFA’2004 15 Split Connection Approach Split connection results in independent flow control for the two parts 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 Flow/error control protocols, packet size, time-outs, may be different for each part FHMHBS Base StationMobile Host Fixed Host

16. IFA’2004 16 I-TCP: Indirect TCP MH MSR FH MH = Mobile Host MSR = Mobile Support Router FH = Fixed Host I-TCPTCP

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

18. IFA’2004 18 I-TCP Basics move MSR-2 FH MH MH socket MH MH socket MSR-1 MSR1 mhsocket MSR1 fhsocket MSR2 fhsocket MSR2 mhsocket FH socket I-TCP Handoff Regular TCP Wireless TCP

19. IFA’2004 19 I-TCP Built on top of a mobile IP Built on top of a mobile IP MSR acts a proxy to the MH 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. Assuming no MSR failures and indefinite MH disconnection, I-TCP does not compromise end-to-end reliability. Well-suited for throughput intensive applications Well-suited for throughput intensive applications

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

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

22. IFA’2004 22 Performance of Split Approaches SPLIT: SPLIT: –Wired goodput 100% since no retransmissions there –Eventually stalls when wireless link times out –Buffer space limited at base station SPLIT-SMART: 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 Split connections not as effective as TCP-aware LL protocol, which also avoids splitting the connection

23. IFA’2004 23 Link Layer Approaches LL: TCP-like behavior with cumulative acks and retransmit granularity faster than TCP’s LL: TCP-like behavior with cumulative acks and retransmit granularity faster than TCP’s LL-SMART: addition of selective retransmissions LL-SMART: addition of selective retransmissions –Cumulative ack with sequence # of of packet causing ack LL-TCP-AWARE: Snoop protocol 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 LL-SMART-TCP-AWARE: Combination of selective acks and duplicate ack suppression

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

25. IFA’2004 25 Snoop Protocol Buffers data packets at the base station BS 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 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 Prevents fast retransmit at TCP sender FH by dropping the dupacks at BS FHMHBS

26. IFA’2004 26 Snoop Protocol FHMHBS wireless physical link network transport application physical link network transport application physical link network transport application rxmt Per TCP-connection state TCP connection

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

28. IFA’2004 28 Snoop Protocol Disadvantages: Link layer at base station needs to be TCP-aware Link layer at base station needs to be TCP-aware Not useful if TCP headers are encrypted (IPsec) 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) Cannot be used if TCP data and TCP acks traverse different paths (both do not go through the base station)

29. IFA’2004 29 Link Layer Approaches Results Simple retransmission at link layer helps, but not totally Simple retransmission at link layer helps, but not totally Combination of selective acks and duplicate suppression is best 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 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 Overall, want to avoid triggering TCP congestion handling techniques

30. IFA’2004 30Summary Good TCP-aware LL shields sender from duplicate acks 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 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 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 Explicit loss E2E schemes help (avoid shrinking congestion window) but should be combined with SACK for multiple packet losses

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

32. IFA’2004 32 Effect of route reconstruction/repair Effect of route reconstruction/repair Effect of network partitioning/merging, multi-path routing 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 High bit error rates –problem amplified with multiple hops Out-of-order packet delivery Out-of-order packet delivery –frequent route changes may cause out-of-order delivery Half-duplex radios Half-duplex radios –cannot send and receive packets simultaneously –changing mode (send or receive) incurs overhead Overview of Transport Problems in Ad Hoc Networks

33. IFA’2004 33 Multi-Hop Paths May need to traverse multiple links to reach a destination May need to traverse multiple links to reach a destination

34. IFA’2004 34 Mobility causes route changes Mobility causes route changes Multi-Hop Paths

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

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

37. IFA’2004 37 Caching and TCP Performance Caching can reduce overhead of route discovery even if cache accuracy is not very high 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 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

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

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

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

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

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

43. IFA’2004 43 Design of ATCP Transparent layer between standard TCP and IP. 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 Monitors TCP and Network state based on Explicit Congestion Notification (ECN) and Internet Control Management Protocol (ICMP) messages TCP ATCP IP

44. IFA’2004 44 ATCP State Transition Diagram

45. IFA’2004 45 Loss State Normal  Loss state transition occurs when packet loss due to high BER channel implied: 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. ATCP retransmits lost packet(s) instead of TCP. When new acknowledgement arrives, When new acknowledgement arrives, –ATCP passes it to TCP –TCP exits persist mode –State transition from Loss  Normal

46. IFA’2004 46 Congested State Normal  Congested state transition occurs when sender receives TCP acknowledgement with explicit congestion notification (ECN) bit set. 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: ATCP does nothing in congested state: –Ignore imminent RTO and –Ignore duplicate acknowledgements TCP would behave as normal TCP would behave as normal When TCP transmits a new packet, ATCP transitions from Congested  Normal. When TCP transmits a new packet, ATCP transitions from Congested  Normal.

47. IFA’2004 47 Disconnected State Normal  Disconnected state transition occurs when ICMP Destination Unreachable packet received. 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. TCP continuously transmits probe packets. –When acknowledgement to probe packet is received, this means destination node is no longer disconnected.

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

49. IFA’2004 49 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. 15 th 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

50. IFA’2004 50 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.