1. 1 TCP over Wireless (I) some slides adapted, notably from tutorial by Nitin Vaidya

2. 2 Wireless Connectivity - Characteristics  Transmission errors  Wireless LANs - 802.11, Hyperlan  Cellular wireless  Multi-hop wireless  Satellites  Low bandwidth  Cellular wireless  Packet radio (e.g., Metricom)  Long or variable latency  GEO, LEO satellites  Packet radio - high variability  Asymmetry in bandwidth, error characteristics  Satellites (example: DirectPC)

3. 3 TCP/IP over Wireless  De facto standard for internetworking  Allows wireless devices to connect seamlessly to the Internet  TCP over wireless introduces some problems not faced in wired networks (transmission errors, mobility …)  We will overview these issues as well as existing solutions  What type of wireless network (cellular, last hop, ad hoc, satellite …)?

4. 4 Quick review of Transmission Control Protocol / Internet Protocol TCP/IP

5. 5 Internet Protocol (IP)  Packets may be delivered out-of-order  Packets may be lost  Packets may be duplicated

6. 6 Transmission Control Protocol (TCP)  Reliable ordered delivery  Implements congestion avoidance and control  Reliability achieved by means of retransmissions if necessary  End-to-end semantics  Acknowledgements sent to TCP sender confirm delivery of data received by TCP receiver  Ack for data sent only after data has reached receiver

7. 7 TCP Basics  Cumulative acknowledgements  An acknowledgement ack’s all contiguously received data  TCP assigns byte sequence numbers  For simplicity, we will assign packet sequence numbers  Also, we use slightly different syntax for acks than normal TCP syntax  In our notation, ack i acknowledges receipt of packets through packet i

8. 8 40393738 3533 Cumulative Acknowledgements  A new cumulative acknowledgement is generated only on receipt of a new in-sequence packet 41403839 3537 3634 3634 i dataack i

9. 9 Delayed Acknowledgements  An ack is delayed until  another packet is received, or  delayed ack timer expires (200 ms typical)  Reduces ack traffic 40393738 3533 41403839 3537 New ack not produced on receipt of packet 36, but on receipt of 37

10. 10 Duplicate Acknowledgements  A dupack is generated whenever an out-of-order segment arrives at the receiver 40393738 3634 42413940 36 Dupack (Above example assumes delayed acks) On receipt of 38

11. 11 Duplicate Acknowledgements  Duplicate acks are not delayed  Duplicate acks may be generated when  a packet is lost, or  a packet is delivered out-of-order (OOO) 40393837 3634 41403739 36 Dupack On receipt of 38

12. 12 Number of dupacks depends on how much OOO a packet is 40393837 3634 41403739 36 Dupack 42413940 36 38 New Ack 34 New Ack DupackNew Ack

13. 13 Window Based Flow Control  Sliding window protocol  Window size minimum of  receiver’s advertised window - determined by available buffer space at the receiver  congestion window - determined by the sender, based on feedback from the network 23456789101113112 Sender’s window Acks receivedNot transmitted

14. 14 Window Based Flow Control 23456789101113112 Sender’s window 23456789101113112 Sender’s window Ack 5

15. 15 Ack Clock  TCP window flow control is “self-clocking”  New data sent when old data is ack’d  Helps maintain “equilibrium”

16. 16 Window Based Flow Control  Congestion window size bounds the amount of data that can be sent per round-trip time  Throughput <= W / RTT

17. 17 Ideal Window Size  Ideal size = delay * bandwidth  delay-bandwidth product  What if window size < delay*bw ?  Inefficiency (wasted bandwidth)  What if > delay*bw ?  Queuing at intermediate routers increased RTT due to queuing delays  Potentially, packet loss

18. 18 How does TCP detect a packet loss?  Retransmission timeout (RTO)  Duplicate acknowledgements

19. 19 Detecting Packet Loss Using Retransmission Timeout (RTO)  At any time, TCP sender sets retransmission timer for only one packet  If acknowledgement for the timed packet is not received before timer goes off, the packet is assumed to be lost  RTO dynamically calculated

20. 20 Retransmission Timeout (RTO) calculation  RTO = mean + 4 mean deviation  Standard deviation  average of (sample – mean)  Mean deviation  average of |sample – mean|  Mean deviation easier to calculate than standard deviation  Mean deviation is more conservative   Large variations in the RTT increase the deviation, leading to larger RTO 22

21. 21 Timeout Granularity  RTT is measured as a discrete variable, in multiples of a “tick”  1 tick = 500 ms in many implementations  smaller tick sizes in more recent implementations (e.g., Solaris)  RTO is at least 2 clock ticks

22. 22 Exponential Backoff  Double RTO on each timeout Packet transmitted Time-out occurs before ack received, packet retransmitted Timeout interval doubled T1 T2 = 2 * T1

23. 23 Fast Retransmission  Timeouts can take too long  how to initiate retransmission sooner?  Fast retransmit

24. 24 Detecting Packet Loss Using Dupacks Fast Retransmit Mechanism  Dupacks may be generated due to  packet loss, or  out-of-order packet delivery  TCP sender assumes that a packet loss has occurred if it receives three dupacks consecutively 128791011 3 dupacks are also generated if a packet is delivered at least 3 places beyond its in-sequence location Fast retransmit useful only if lower layers deliver packets “almost ordered” ---- otherwise, unnecessary fast retransmit

25. 25 Congestion Avoidance and Control Slow Start  initially, congestion window size cwnd = 1 MSS (maximum segment size)  increment window size by 1 MSS on each new ack  slow start phase ends when window size reaches the slow-start threshold  cwnd grows exponentially with time during slow start  factor of 1.5 per RTT if every other packet ack’d  factor of 2 per RTT if every packet ack’d  Could be less if sender does not always have data to send

26. 26 Congestion Avoidance  On each new ack, increase cwnd by 1/cwnd packets  cwnd increases linearly with time during congestion avoidance  1/2 MSS per RTT if every other packet ack’d  1 MSS per RTT if every packet ack’d

27. 27 Slow start Congestion avoidance Slow start threshold Example assumes that acks are not delayed

28. 28 Congestion Control  On detecting a packet loss, TCP sender assumes that network congestion has occurred  On detecting packet loss, TCP sender drastically reduces the congestion window  Reducing congestion window reduces amount of data that can be sent per RTT  throughput may decrease

29. 29 Congestion Control -- Timeout  On a timeout, the congestion window is reduced to the initial value of 1 MSS  The slow start threshold is set to half the window size before packet loss  more precisely, ssthresh = maximum of min(cwnd,receiver’s advertised window)/2 and 2 MSS  Slow start is initiated

30. 30 ssthresh = 8 ssthresh = 10 cwnd = 20 After timeout

31. 31 Congestion Control - Fast retransmit  Fast retransmit occurs when multiple (>= 3) dupacks come back  Fast recovery follows fast retransmit  Different from timeout : slow start follows timeout  timeout occurs when no more packets are getting across  fast retransmit occurs when a packet is lost, but latter packets get through  ack clock is still there when fast retransmit occurs  no need to slow start

32. 32 Fast Recovery  ssthresh = min(cwnd, receiver’s advertised window)/2 (at least 2 MSS)  retransmit the missing segment (fast retransmit)  cwnd = ssthresh + number of dupacks  when a new ack comes: cwnd = ssthreh  enter congestion avoidance Congestion window cut into half

33. 33 After fast retransmit and fast recovery window size is reduced in half. Receiver’s advertized window After fast recovery

34. 34 TCP Reno  Slow-start  Congestion avoidance  Fast retransmit  Fast recovery

35. 35 Fast Recovery Fast recovery can result in a timeout with multiple losses per RTT.  TCP New-Reno [Hoe96]  stay in fast recovery until all packet losses in window are recovered  can recover 1 packet loss per RTT without causing a timeout  Selective Acknowledgements (SACK) [mathis96rfc2018]  provides information about out-of-order packets received by receiver  can recover multiple packet losses per RTT

36. 36 Does IEEE 802.11 Work Well in Multi-hop Wireless Network? Author: Shugong Xu, Tarek Saadawi City University of New York

37. 37 Overview of The Paper  This paper is about TCP over multi-hop networks, but its also about cross-layer interactions  Conclusion: Cross Layer interactions between 802.11 Protocol, routing and TCP can be destructive.  Experimental Scenario:  A Static String Topology  TCP as Transport Layer Protocol  Problems:  Instability Problem  Unfairness Problem 01234567

38. 38 Simulation Environment  Simulator: ns-2 with wireless extensions  MAC Layer: IEEE 802.11 MAC Distributed Coordination function(DCF).  Transport Layer: TCP connections carrying bulk transfers (always have data)  Network Scenario  A Static String Network Topology  Interference range is a little more than two times of the communication range 01234567 Interference Range Communication Range

39. 39 Instability Problem—Experiment Setup 12345 Source Destination  A single TCP connection, with node 1 as the source and node 5 as the destination.  Three sets of experiments with Maximum Window Size(window_) 32, 8, and 4 respectively.

40. 40 Instability Problem—Experiment Result  When window_=32 or 8, serious oscillation of throughput is observed.  When window_4, throughput is stable.

41. 41 Instability Problem—Trace Analysis(1) 12345 Data Ack RTS CTS Interference Range of Node 2

42. 42 Instability Problem—Summary  Collision and exposed terminal problem prevent node 2 from receiving RTS from or sending CTS to node 1.  The random back-off, big data packet, and sending back-to-back packets worsen the above problems.  When window_ = 4, the chance to send back a CTS is greatly increased, so the throughput becomes stable.  After node 1 fails seven times to receive CTS, node 1 believes there is a route failure and starts a route discovery.  Before a route is available, node 1 can not send out a data packet. This period usually is long enough to cause a timeout at the TCP sender.  For TCP, timeout triggers Slow Start, which significantly reduces the throughput.

43. 43 Unfairness Problem—Experiment Setup 23456 Source Destination Source First SessionSecond Session  In the first session, data flow from 6 to 4. In the second session, data flow from 2 to 3.  The first session starts at 10.0s. The second session starts at 30.0s.

44. 44 Unfairness Problem (1)  The first session has a throughput of about 450kbps from 10s to 30s, and 0kbps after 30s.  The second session has a throughput of about 900kbps from 30s to 130s.

45. 45 Unfairness Problem (2)  The first session never succeeds to send out packet with sequence number 2164.

46. 46 Unfairness Problem—Trace Analysis(1) 23456 RTSData CTS Interfering Range of Node 5 Ack Interfering Range of Node 4 Data No Route

47. 47 Unfairness Problem—Trace Analysis(2) 23456 RTSData CTS Interfering Range of Node 5 Ack Interfering Range of Node 4 Data No Route

48. 48 Unfairness Problem—Summary  In one-hop TCP connections, the interval between packet transmission is larger than that of the multi- hop TCP connections, which gives the one-hop connection more chances to transmit data.  Random back-off is actually advantageous to the last succeeding host.  Problem called “One-hop unfairness problem”  Authors argue that since one-hop connection is common in a wireless network problem must be addressed

49. 49 Discussion?  Problems Shown:  Instability Problem  Unfairness problem  Conclusions:  IEEE 802.11 does not work well in multi-hop wireless networks.  It may be inappropriate to take IEEE 802.11 as the MAC layer to simulate routing or transport protocols for multi- hop wireless networks.  Are Cross Layer Solutions needed?  Maybe a different set of protocols that play nicer together?

50. 50 More discussion  Rooted in IEEE 802.11 MAC?  TCP is not designed with wireless networking in mind.  Timeout  Slow Start  Interfering range and communication range  If interfering range is the same as the communication range, the two problems presented in this paper will disappear.  Is the configuration of the interfering range simply an engineering issue?  Only a simple topology is considered  What happens if more complex scenarios are considered?  Different traffic?  Multiple connections?  Different spacing between nodes?  More realistic wireless channel?  Can you relate to other stuff we have discussed so far?

51. 51 Impact of transmission errors on TCP performance

52. 52 Random Errors  If number of errors is small, they may be corrected by an error correcting code  Excessive bit errors result in a packet being discarded, possibly before it reaches the transport layer

53. 53 Random Errors May Cause Fast Retransmit 40393738 3634 Example assumes delayed ack - every other packet ack’d

54. 54 Random Errors May Cause Fast Retransmit 41403839 3634 Example assumes delayed ack - every other packet ack’d

55. 55 Random Errors May Cause Fast Retransmit 42413940 36 Duplicate acks are not delayed 36 dupack

56. 56 Random Errors May Cause Fast Retransmit 40 36 Duplicate acks 414342

57. 57 Random Errors May Cause Fast Retransmit 41 36 3 duplicate acks trigger fast retransmit at sender 424443 36

58. 58 Random Errors May Cause Fast Retransmit  Fast retransmit results in  retransmission of lost packet  reduction in congestion window  Reducing congestion window in response to errors is unnecessary  Reduction in congestion window reduces the throughput

59. 59 Sometimes Congestion Response May be Appropriate in Response to Errors  On a CDMA channel, errors occur due to interference from other user, and due to noise [Karn99pilc]  Interference due to other users is an indication of congestion. If such interference causes transmission errors, it is appropriate to reduce congestion window  If noise causes errors, it is not appropriate to reduce window  When a channel is in a bad state for a long duration, it might be better to let TCP backoff, so that it does not unnecessarily attempt retransmissions while the channel remains in the bad state [Padmanabhan99pilc]

60. 60 Impact of Random Errors [Vaidya99] Exponential error model 2 Mbps wireless full duplex link No congestion losses

61. 61 Burst Errors May Cause Timeouts  If wireless link remains unavailable for extended duration, a window worth of data may be lost  driving through a tunnel  passing a truck  Timeout results in slow start  Slow start reduces congestion window to 1 MSS, reducing throughput  Reduction in window in response to errors unnecessary  Multiple packet losses (random) can also result in timeout when using TCP-Reno (and to a lesser extent when using SACK)

62. 62 Impact of Transmission Errors  TCP cannot distinguish between packet losses due to congestion and transmission errors  Unnecessarily reduces congestion window  Throughput suffers

63. 63 Classification of Schemes to Improve Performance of TCP in Presence of Transmission Errors

64. 64 Techniques to Improve TCP Performance in Presence of Errors Classification 1 Classification based on nature of actions taken to improve performance  Hide error losses from the sender  if sender is unaware of the packet losses due to errors, it will not reduce congestion window  Let sender know, or determine, cause of packet loss  if sender knows that a packet loss is due to errors, it will not reduce congestion window

65. 65 Techniques to Improve TCP Performance in Presence of Errors Classification 2 Classification based on where modifications are needed  At the sender node only  At the receiver node only  At intermediate node(s) only  Combinations of the above

66. 66 Ideal Behavior  Ideal TCP behavior: Ideally, the TCP sender should simply retransmit a packet lost due to transmission errors, without taking any congestion control actions  Such a TCP referred to as Ideal TCP  Ideal TCP typically not realizable  Ideal network behavior: Transmission errors should be hidden from the sender -- the errors should be recovered transparently and efficiently  Proposed schemes attempt to approximate one of the above two ideals

67. 67 Selected Schemes to Improve Performance of TCP in Presence of Transmission Errors

68. 68 Various Schemes  Link level mechanisms  Split connection approach  TCP-Aware link layer  TCP-Unaware approximation of TCP-aware link layer  Explicit notification  Receiver-based discrimination  Sender-based discrimination For a brief overview, see [Dawkins99,Montenegro99]

69. 69 Link Level Mechanisms

70. 70 Link Layer Mechanisms Forward Error Correction  Forward Error Correction (FEC) [Lin83] can be use to correct small number of errors  Correctable errors hidden from the TCP sender  FEC incurs overhead even when errors do not occur  Adaptive FEC schemes [Eckhardt98] can reduce the overhead by choosing appropriate FEC dynamically

71. 71 Link Layer Mechanisms Link Level Retransmissions  Link level retransmission schemes retransmit a packet at the link layer, if errors are detected  Retransmission overhead incurred only if errors occur  unlike FEC overhead

72. 72 Link Layer Mechanisms In general  Use FEC to correct a small number of errors  Use link level retransmission when FEC capability is exceeded

73. 73 Link Level Retransmissions wireless physical link network transport application physical link network transport application physical link network transport application rxmt TCP connection Link layer state

74. 74 Link Level Retransmissions Issues  How many times to retransmit at the link level before giving up?  Finite bound -- semi-reliable link layer  No bound -- reliable link layer  What triggers link level retransmissions?  Link layer timeout mechanism  Link level acks (negative acks, dupacks, …)  Other mechanisms (e.g., Snoop, as discussed later)  How much time is required for a link layer retransmission?  Small fraction of end-to-end TCP RTT  Large fraction/multiple of end-to-end TCP RTT  Interaction of timers at link level and TCP?

75. 75 Link Level Retransmissions Issues  Should the link layer deliver packets as they arrive, or deliver them in-order?  Link layer may need to buffer packets and reorder if necessary so as to deliver packets in-order

76. 76 Link Level Retransmissions Issues  Retransmissions can cause head-of-the-line blocking  Although link to receiver 1 may be in a bad state, the link to receiver 2 may be in a good state  Retransmissions to receiver 1 are lost, and also block a packet from being sent to receiver 2 Base station Receiver 1 Receiver 2

77. 77 Link Level Retransmissions (Early Studies)  The sender’s Retransmission Timeout (RTO) is a function of measured RTT (round-trip times)  Link level retransmits increase RTT, therefore, RTO  If errors not frequent, RTO will not account for RTT variations due to link level retransmissions  When errors occur, the sender may timeout & retransmit before link level retransmission is successful  Sender and link layer both retransmit  Duplicate retransmissions (interference) waste wireless bandwidth  Timeouts also result in reduced congestion window

78. 78 RTO Variations Packet loss RTT sample RTO Wireless

79. 79 A More Accurate Picture  With large RTO granularity, interference is unlikely, if time required for link-level retransmission is small compared to TCP RTO [Balakrishnan96Sigcomm]  Standard TCP RTO granularity is often large  Minimum RTO (2*granularity) is large enough to allow a small number of link level retransmissions, if link level RTT is relatively small  Interference due to timeout not a significant issue when wireless RTT small, and RTO granularity large [Eckhardt98]

80. 80 Link Level Retransmissions A More Accurate Picture  Frequent errors increase RTO significantly on slow wireless links  RTT on slow links large, retransmissions result in large variance, pushing RTO up  Likelihood of interference between link layer and TCP retransmissions smaller  But congestion response will be delayed due to larger RTO  When wireless losses do cause timeout, much time wasted

81. 81 Large TCP Retransmission Timeout Intervals  Good for reducing interference with link level retransmits  Bad for recovery from congestion losses  Need a timeout mechanism that responds appropriately for both types of losses  Open problem

82. 82 Link Level Retransmissions  Selective repeat protocols can deliver packets out of order  Significantly out-of-order delivery can trigger TCP fast retransmit  Redundant retransmission from TCP sender  Reduction in congestion window  Example: Receipt of packets 3,4,5 triggers dupacks 6252341 Lost packet Retransmitted packet

83. 83 Link Level Retransmissions In-order delivery  To avoid unnecessary fast retransmit, link layer using retransmission should attempt to deliver packets “almost in-order” 654223 652234 1 1

84. 84 Adaptive Link Layer Strategies [Lettieri98,Eckhardt98,Zorzi97] Adaptive protocols attempt to dynamically choose:  FEC code  retransmission limit  frame size

85. 85 Link Layer Retransmissions [Vaidya99] 2 Mbps wireless duplex link with 1 ms delay Exponential error model No congestion losses 20 ms1 ms 10 Mbps2 Mbps

86. 86 Link Layer Schemes: Summary When is a reliable link layer beneficial to TCP performance?  if it provides almost in-order delivery and  TCP retransmission timeout large enough to tolerate additional delays due to link level retransmits

87. 87 Link Layer Schemes: Classification  Hide wireless losses from TCP sender  Link layer modifications needed at both ends of wireless link  TCP need not be modified

88. 88 Various Schemes  Link level mechanisms  Split connection approach  TCP-Aware link layer  TCP-Unaware approximation of TCP-aware link layer  Explicit notification  Receiver-based discrimination  Sender-based discrimination

89. 89 Split Connection Approach

90. 90 Split Connection Approach  End-to-end TCP connection is broken into one connection on the wired part of route and one over wireless part of the route  A single TCP connection split into two TCP connections  if wireless link is not last on route, then more than two TCP connections may be needed

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

92. 92 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 FHMHBS Base StationMobile Host Fixed Host

93. 93 Split Connection Approach wireless physical link network transport application physical link network transport application physical link network transport application rxmt Per-TCP connection state TCP connection

94. 94 Split Connection Approach Indirect TCP [Bakre95,Bakre97]  FH - BS connection : Standard TCP  BS - MH connection : Standard TCP

95. 95 Split Connection Approach Selective Repeat Protocol (SRP) [Yavatkar94]  FH - BS connection : standard TCP  BS - FH connection : selective repeat protocol on top of UDP  Performance better than Indirect-TCP (I-TCP), because wireless portion of the connection can be tuned to wireless behavior

96. 96 Split Connection Approach : Other Variations  Asymmetric transport protocol (Mobile-TCP) [Haas97icc] Low overhead protocol at wireless hosts, and higher overhead protocol at wired hosts  smaller headers used on wireless hop (header compression)  simpler flow control - on/off for MH to BS transfer  MH only does error detection, BS does error correction too  No congestion control over wireless hop

97. 97 Split Connection Approach : Classification  Hides transmission errors from sender  Primary responsibility at base station  If specialized transport protocol used on wireless, then wireless host also needs modification

98. 98 Split Connection Approach : Advantages  BS-MH connection can be optimized independent of FH-BS connection  Different flow / error control on the two connections  Local recovery of errors  Faster recovery due to relatively shorter RTT on wireless link  Good performance achievable using appropriate BS-MH protocol  Standard TCP on BS-MH performs poorly when multiple packet losses occur per window (timeouts can occur on the BS-MH connection, stalling during the timeout interval)  Selective acks improve performance for such cases

99. 99 Split Connection Approach : Disadvantages  End-to-end semantics violated  ack may be delivered to sender, before data delivered to the receiver  May not be a problem for applications that do not rely on TCP for the end-to-end semantics FHMHBS 40 39 3738 36 40

100. 100 Split Connection Approach : Disadvantages  BS retains hard state BS failure can result in loss of data (unreliability)  If BS fails, packet 40 will be lost  Because it is ack’d to sender, the sender does not buffer 40 FHMHBS 40 39 3738 36 40

101. 101 Split Connection Approach : Disadvantages  BS retains hard state Hand-off latency increases due to state transfer  Data that has been ack’d to sender, must be moved to new base station FHMHBS 40 39 3738 36 40 MH New base station Hand-off 40 39

102. 102 Split Connection Approach : Disadvantages  Buffer space needed at BS for each TCP connection  BS buffers tend to get full, when wireless link slower (one window worth of data on wired connection could be stored at the base station, for each split connection)  Window on BS-MH connection reduced in response to errors  may not be an issue for wireless links with small delay-bw product

103. 103 Split Connection Approach : Disadvantages  Extra copying of data at BS  copying from FH-BS socket buffer to BS-MH socket buffer  increases end-to-end latency  May not be useful if data and acks traverse different paths (both do not go through the base station)  Example: data on a satellite wireless hop, acks on a dial-up channel FHMH data ack

104. 104 Various Schemes  Link layer mechanisms  Split connection approach  TCP-Aware link layer  TCP-Unaware approximation of TCP-aware link layer  Explicit notification  Receiver-based discrimination  Sender-based discrimination

105. 105 TCP-Aware Link Layer

106. 106 Snoop Protocol [Balakrishnan95acm]  Retains local recovery of Split Connection approach and link level retransmission schemes  Improves on split connection  end-to-end semantics retained  soft state at base station, instead of hard state

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

108. 108 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 FHMHBS

109. 109 Snoop : Example FHMHBS 40393738 3634 Example assumes delayed ack - every other packet ack’d 36 37 38 35 TCP state maintained at link layer

110. 110 Snoop : Example 41403839 3634 36 37 38 3539

111. 111 Snoop : Example 42413940 36 Duplicate acks are not delayed 36 dupack 37 38 39 40

112. 112 Snoop : Example 40 36 Duplicate acks 414342 37 38 39 40 41

113. 113 Snoop : Example FHMHBS 41 36 374443 36 37 38 39 40 41 42 Discard dupack Dupack triggers retransmission of packet 37 from base station BS needs to be TCP-aware to be able to interpret TCP headers

114. 114 Snoop : Example 37 36 424544 36 37 38 39 40 41 42 43 36

115. 115 Snoop : Example 42 36 434645 36 37 38 39 40 41 42 43 41 36 44 TCP sender does not fast retransmit

116. 116 Snoop : Example 43 36 444746 36 37 38 39 40 41 42 43 41 36 44 TCP sender does not fast retransmit 45

117. 117 Snoop : Example FHMHBS 44 36 454847 36 42 43 41 36 44 45 43 46

118. 118 Snoop [Balakrishnan95acm] 2 Mbps Wireless link

119. 119 Snoop Protocol When Beneficial?  Snoop prevents fast retransmit from sender despite transmission errors, and out-of-order delivery on the wireless link  OOO delivery causes fast retransmit only if it results in at least 3 dupacks  If wireless link level delay-bandwidth product is less than 4 packets, a simple (TCP-unaware) link level retransmission scheme can suffice  Since delay-bandwidth product is small, the retransmission scheme can deliver the lost packet without resulting in 3 dupacks from the TCP receiver

120. 120 Snoop Protocol : Classification  Hides wireless losses from the sender  Requires modification to only BS (network-centric approach)

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

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

123. 123 WTCP Protocol [Ratnam98]  Snoop hides wireless losses from the sender  But sender’s RTT estimates may be larger in presence of errors  Larger RTO results in slower response for congestion losses FHMHBS

124. 124 WTCP Protocol  WTCP performs local recovery, similar to Snoop  In addition, WTCP uses the timestamp option to estimate RTT  The base station adds base station residence time to the timestamp when processing an ack received from the wireless host  Sender’s RTT estimate not affected by retransmissions on wireless link FHMHBS

125. 125 WTCP Example FHBSMH 33 34 Numbers in this figure are timestamps Base station residence time is 1 unit

126. 126 WTCP : Disadvantages  Requires use of the timestamp option  May be useful only if retransmission times are large  link stays in bad state for a long time  link frequently enters a bad state  link delay large  WTCP does not account for congestion on wireless hop  assumes that all delay at base station is due to queuing and retransmissions  will not work for shared wireless LAN, where delays also incurred due to contention with other transmitters

127. 127 Various Schemes  Link layer mechanisms  Split connection approach  TCP-Aware link layer  TCP-Unaware approximation of TCP-aware link layer  Explicit notification  Receiver-based discrimination  Sender-based discrimination

128. 128 TCP-Unaware Approximation of TCP-Aware Link Layer

129. 129 Delayed Dupacks Protocol [Mehta98,Vaidya99]  Attempts to imitate Snoop, without making the base station TCP-aware  Snoop implements two features at the base station  link layer retransmission  reducing interference between TCP and link layer retransmissions (by dropping dupacks)  Delayed Dupacks implements the same two features  at BS : link layer retransmission  at MH : reducing interference between TCP and link layer retransmissions (by delaying dupacks)

130. 130 Delayed Dupacks Protocol wireless physical link network transport application physical link network transport application physical link network transport application rxmt TCP connection Link layer state

131. 131 Delayed Dupacks Protocol  Link layer retransmission scheme at the base station  Link layer delivers packets out-of-order when transmission errors occur  Why may a link layer deliver packets out-of-order? Only an issue when the link layer does not use stop-and- go protocol  With OOO link layer delivery, loss of a packet from one flow does not block delivery of packets from another flow  If in-order delivery is enforced, when retransmission for a packet is being performed, packets from other other flows may also be blocked from being delivered to the upper layer

132. 132 Delayed Dupacks Protocol  TCP receiver delays dupacks (third and subsequent) for interval D, when out-of-order packets received  Dupack delay intended to give link level retransmit time to succeed  Benefit: Delayed dupacks can result in recovery from a transmission loss without triggering a response from the TCP sender  Disadvantage: Recovery from congestion losses delayed

133. 133 Delayed Dupacks Protocol  Delayed dupacks released after interval D, if missing packet not received by then  Link layer maintains state to allow retransmission  Link layer state is not TCP-specific

134. 134 Delayed Dupacks : Example 40393738 3634 Example assumes delayed ack - every other packet ack’d Link layer acks are not shown 36 37 38 35 Link layer state

135. 135 Delayed Dupacks : Example BS 41403839 3634 36 37 38 39 35 Removed from BS link layer buffer on receipt of a link layer ack (LL acks not shown in figure)

136. 136 Delayed Dupacks : Example 42413940 36 Duplicate acks are not delayed 36 dupack 37 38 39 40

137. 137 Delayed Dupacks : Example 40 36 Duplicate acks 414342 37 38 39 40 41 Original ack

138. 138 Delayed Dupacks : Example 41 36 374443 36 37 39 40 41 42 Base station forwards dupacks dupackdupacks Delayed dupack

139. 139 Delayed Dupacks : Example 37 36 424544 36 37 40 41 42 36 dupacks Delayed dupacks 43

140. 140 Delayed Dupacks : Example 42434645 36 37 41 42 43 41 TCP sender does not fast retransmit 44 Delayed dupacks are discarded if lost packet received before delay D expires

141. 141 Delayed Dupacks [Vaidya99] 2 Mbps wireless duplex link with 20 ms delay No congestion losses 20 ms 10 Mbps2 Mbps

142. 142 Delayed Dupacks [Vaidya99] 5% packet loss due to congestion 20 ms 10 Mbps2 Mbps

143. 143 Delayed Dupacks Scheme : Advantages  Link layer need not be TCP-aware  Can be used even if TCP headers are encrypted  Works well for relatively small wireless RTT (compared to end-to-end RTT)  relatively small delay D sufficient in such cases

144. 144 Delayed Dupacks Scheme : Disadvantages  Right value of dupack delay D dependent on the wireless link properties  Mechanisms to automatically choose D needed  Delays dupacks for congestion losses too, delaying congestion loss recovery

145. 145 Various Schemes  Link-layer retransmissions  Split connection approach  TCP-Aware link layer  TCP-Unaware approximation of TCP-aware link layer  Explicit notification  Receiver-based discrimination  Sender-based discrimination

146. 146 Explicit Notification

147. 147 Explicit Notification Schemes General Philosophy  Approximate Ideal TCP behavior: Ideally, the TCP sender should simply retransmit a packet lost due to transmission errors, without taking any congestion control actions  A wireless node somehow determines that packets are lost due to errors and informs the sender using an explicit notification  Sender, on receiving the notification, does not reduce congestion window, but retransmits lost packet

148. 148 Explicit Notification Schemes  Motivated by the Explicit Congestion Notification (ECN) proposals [Floyd94] Variations proposed in literature differ in  who sends explicit notification  how they know to send the explicit notification  what the sender does on receiving the notification

149. 149 Explicit Notification Space Communication Protocol Standards- Transport Protocol (SCPS-TP) Satellite Ground station wireless TCP destinations

150. 150 Space Communication Protocol Standards- Transport Protocol (SCPS-TP)  The receiving ground station keeps track of how many packets with errors are received (their checksums failed)  When the error rate exceeds a threshold, the ground station sends corruption experienced messages to destinations of recent error-free TCP packets  destinations are cached  The TCP destinations tag acks with corruption-experienced bit  TCP sender, after receiving an ack with corruption-experienced bit, does not back off until it receives an ack without that bit (even if timeout or fast retransmit occurs)

151. 151 Explicit Loss Notification [Balakrishnan98] when MH is the TCP sender  Wireless link first on the path from sender to receiver  The base station keeps track of holes in the packet sequence received from the sender  When a dupack is received from the receiver, the base station compares the dupack sequence number with the recorded holes  if there is a match, an ELN bit is set in the dupack  When sender receives dupack with ELN set, it retransmits packet, but does not reduce congestion window MHFHBS 4321134 wireless Record hole at 2 11 11 Dupack with ELN set

152. 152 Explicit Bad State Notification [Bakshi97] when MH is TCP receiver  Base station attempts to deliver packets to the MH using a link layer retransmission scheme  If packet cannot be delivered using a small number of retransmissions, BS sends a Explicit Bad State Notification (EBSN) message to TCP sender  When TCP sender receives EBSN, it resets its timer  timeout delayed, when wireless channel in bad state

153. 153 Partial Ack Protocols [Cobb95][Biaz97]  Send two types of acknowledgements  A partial acknowledgement informs the sender that a packet was received by an intermediate host (typically, base station)  Normal TCP cumulative ack needed by the sender for reliability purposes

154. 154 Partial Ack Protocols  When a packet for which a partial ack is received is detected to be lost, the sender does not reduce its congestion window  loss assumed to be due to wireless errors 37 36 Partial ack 37 Cumulative ack

155. 155 Variations  Base station may or may not locally buffer and retransmit lost packets  Partial ack for all packets or a subset ? 37 36 Partial ack 37 Cumulative ack

156. 156 Explicit Loss Notification [Biaz99thesis] when MH is TCP receiver  Attempts to approximate hypothetical ELN proposed in [Balakrishnan96] for the case when MH is receiver  Caches TCP sequence numbers at base station, similar to Snoop. But does not cache data packets, unlike Snoop.  Duplicate acks are tagged with ELN bit before being forwarded to sender if sequence number for the lost packet is cached at the base station  Sender takes appropriate action on receiving ELN

157. 157 Explicit Loss Notification [Biaz99thesis] when MH is TCP receiver 37 36 37 3839 38 Sequence numbers cached at base station 37 Dupack with ELN

158. 158 Various Schemes  Link-layer retransmissions  Split connection approach  TCP-Aware link layer  TCP-Unaware approximation of TCP-aware link layer  Explicit notification  Receiver-based discrimination  Sender-based discrimination

159. 159 Receiver-Based Discrimination Scheme

160. 160 Receiver-Based Scheme [Biaz98Asset]  MH is TCP receiver  Receiver uses a heuristic to guess cause of packet loss  When receiver believes that packet loss is due to errors, it sends a notification to the TCP sender  TCP sender, on receiving the notification, retransmits the lost packet, but does not reduce congestion window

161. 161 Receiver-Based Scheme  Packet loss due to congestion FHMHBS 101211 FHMHBS 11 1012 T Congestion loss

162. 162 Receiver-Based Scheme  Packet loss due to transmission error FHMHBS 101211 FHMHBS 101112 Error loss 2 T

163. 163 Receiver-Based Scheme  Receiver uses the inter-arrival time between consecutively received packets to guess the cause of a packet loss  On determining a packet loss as being due to errors, the receiver may  tag corresponding dupacks with an ELN bit, or  send an explicit notification to sender

164. 164 Receiver-Based Scheme Diagnostic Accuracy [Biaz99Asset] Congestion losses Error losses

165. 165 Receiver-Based Scheme : Disadvantages  Limited applicability  The slowest link on the path must be the last wireless hop  to ensure some queuing will occur at the base station  The queueing delays for all packets (at the base station) should be somewhat uniform  multiple connections on the link will make inter-packet delays variable

166. 166 Receiver-Based Scheme : Advantages  Can be implemented without modifying the base station (an “end-to-end” scheme)  May be used despite encryption, or if data & acks traverse different paths

167. 167 Various Schemes  Link-layer retransmissions  Split connection approach  TCP-Aware link layer  TCP-Unaware approximation of TCP-aware link layer  Explicit notification  Receiver-based discrimination  Sender-based discrimination

168. 168 Sender-Based Discrimination Scheme

169. 169 Sender-Based Discrimination Scheme [Biaz98ic3n,Biaz99techrep]  Sender can attempt to determine cause of a packet loss  If packet loss determined to be due to errors, do not reduce congestion window  Sender can only use statistics based on round-trip times, window sizes, and loss pattern  unless network provides more information (example: explicit loss notification)

170. 170 Heuristics for Congestion Avoidance load RTT throughput knee cliff

171. 171 Heuristics for Congestion Avoidance  Define condition C as a function of congestion window size and observed RTTs  Condition C evaluated when a new RTT is calculated  condition C typically evaluates to 2 or 3 possible values  for now assume 2 values: TRUE or FALSE  If (C == True) reduce congestion window  Several proposals for condition C

172. 172 Heuristics for Congestion Avoidance Some proposals  Normalized Delay Gradient [jain89] r = [RTT(i)-RTT(i-1)] / [RTT(i)+RTT(i-1)] w = [W(i)-W(i-1)] / [W(i)+W(i-1)] Condition C = (r/w > 0)

173. 173 Heuristics for Congestion Avoidance Some proposals  Normalized Throughput Gradient [Wang91] Throughput gradient TG(i) = [T(i) - T(i-1) ] / [ W(i)-W(i-1)] Normalized Throughout Gradient NTG = TG(i) / TG(1) Condition C = (NTG < 0.5)

174. 174 Heuristics for Congestion Avoidance Some proposals  TCP Vegas [Brakmo94] expected throughput ET = W(i) / RTTmin actual throughput AT = W(i) / RTT(i) Condition C = ( ET-AT > beta)

175. 175 Sender-Based Heuristics  Record latest value evaluated for condition C  When a packet loss is detected  if last evaluation of C is TRUE, assume packet loss is due to congestion  else assume that packet loss is due to transmission errors  If packet loss determined to be due to errors, do not reduce congestion window

176. 176 Sender-Based Schemes Diagnostic Accuracy [Biaz99ic3n]

177. 177 Sender-Based Schemes Diagnostic Accuracy [Biaz99ic3n]

178. 178 Sender-Based Heuristics : Disadvantage  Does not work quite well enough as yet !! Reason  Statistics collected by the sender garbled by other traffic on the network  Not much correlation between observed short-term statistics, and onset of congestion

179. 179 Sender-Based Heuristics : Advantages  Only sender needs to be modified Needs further investigation to develop better heuristics  investigate longer-term heuristics

180. 180 Why do Statistical Technique Perform Poorly?  The techniques we evaluated use simple statistics on RTT and window size W to draw conclusions about state of the network  Unfortunately, correlation between RTT and W is often weak Fraction of TCP connections Coefficient of correlation (RTT,W)

181. 181 Statistical Techniques Future Work  Other statistical measures ?  Mechanisms that achieve good TCP throughput despite not-too-good diagnostic accuracy

182. 182 TCP in Presence of Transmission Errors Summary  Many techniques have been proposed, and several approaches perform well in many environments  Recommendation: Prefer end-to-end techniques  End-to-end techniques are those which do not require TCP-Specific help from lower layers  Lower layers may help improve TCP performance without taking TCP-specific actions. Examples: Semi-reliable link level retransmission schemes Explicit notification