1. Univ. of TehranComputer Network1 Special Topics on Wireless Ad-hoc Networks University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani TCP on Wireless Network Lecture 12: TCP on Wireless Network

2. Univ. of TehranComputer Network2 Covered topics How to run applications on wireless network? Transport layer References Chapter 5 of the book Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan and Randy H. Katz, “A Comparison of Mechanisms for Improving TCP Performance over Wireless Links”

3. Univ. of TehranComputer Network3 Outline TCP basics Layer 4 consideration: Impact of transmission errors on TCP performance Timeout Approaches to improve TCP performance Approaches to improve application performance

4. Univ. of TehranComputer Network4 TCP Basics Reliable ordered delivery 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 TCP window flow control is “self-clocking” New data sent when old data is ack’d Helps maintain “equilibrium” Implements congestion avoidance and control

5. Univ. of TehranComputer Network5 Window Based Flow Control TCP sender sets retransmission timer for only one packet. If ack for the timed packet is not received the packet is assumed to be lost RTO dynamically calculated Congestion window size bounds the amount of data that can be sent per round-trip time Throughput <= W / RTT

6. Univ. of TehranComputer Network6 Retransmission Timeout (RTO) 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 2 2

7. Univ. of TehranComputer Network7 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 Double RTO on each timeout (Exponential backoff)

8. Univ. of TehranComputer Network8 Congestion Collapse and Efficiency knee – point after which throughput increases slowly delay increases quickly cliff – point after which throughput decreases quickly to zero (congestion collapse) delay goes to infinity Congestion avoidance stay at knee Congestion control stay left of (but usually close to) cliff Note (in an M/M/1 queue) delay = 1/(1 – utilization ) Load Throughput Delay kneecliff over utilization under utilization saturation congestion collapse

9. Univ. of TehranComputer Network9 Goals Operate near the knee point Remain in equilibrium How to maintain equilibrium? Don’t put a packet into network until another packet leaves. How do you do it? Use ACK: send a new packet only after you receive and ACK. Why? Maintain number of packets in network “constant”

10. Univ. of TehranComputer Network10 Congestion Control TCP assume packet loss is due to congestion On packet loss, reduces the congestion window and consequently amount of data sent per RTT throughput may decrease

11. Univ. of TehranComputer Network11 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

12. Univ. of TehranComputer Network12 Fast Retransmit Mechanism Timeouts can take too long Fast retransmit in case of packet loss How to identify packet loss? Duplicated Acks. Dupacks may be generated due to packet loss, or out-of-order packet delivery Assumes packet loss in case of three consecutive dupacks 128791011 3 dupacks are 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

13. Univ. of TehranComputer Network13 Congestion Avoidance On each new ack, increase cwnd by 1/cwnd packets cwnd increases linearly with time during congestion avoidance Slow start Congestion avoidance Slow start threshold Example assumes that acks are not delayed

14. Univ. of TehranComputer Network14 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

15. Univ. of TehranComputer Network15 ssthresh = 8 ssthresh = 10 cwnd = 20 After timeout

16. Univ. of TehranComputer Network16 Fast recovery 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

17. Univ. of TehranComputer Network17 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

18. Univ. of TehranComputer Network18 After fast retransmit and fast recovery window size is reduced in half. Receiver’s advertized window After fast recovery

19. Univ. of TehranComputer Network19 Outline TCP basics Impact of transmission errors on TCP performance Approaches to improve TCP performance Classification Discussion of selected approaches

20. Univ. of TehranComputer Network20 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, and Dup Acks. Dups Acks cause Fast retransmit which results in retransmission of lost packet reduction in congestion window Reducing congestion window in response to errors is unnecessary and reduces the throughput

21. Univ. of TehranComputer Network21 Congestion Response to Errors On a CDMA channel, errors occur due to interference from other user, and noise 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.

22. Univ. of TehranComputer Network22 Burst Errors May Cause Timeouts If a wireless link remains unavailable for extended duration, a window worth of data may be lost Timeout might occur Timeout results in slow start and reduces congestion window to 1 MSS, which reduces throughput Unfortunately, TCP cannot distinguish between packet losses due to congestion and transmission errors

23. Univ. of TehranComputer Network23 Improving TCP How to improve performance? Hide error losses from the sender TCP Not reduce congestion window Let sender determine cause of packet loss if it is due to errors, it will not reduce congestion window. where modifications are needed? At the sender node At the receiver node At intermediate node(s) Combinations of the above

24. Univ. of TehranComputer Network24 Ideal Behavior Ideal TCP behavior: TCP sender should retransmit a packet lost due to transmission errors, without taking any congestion control actions 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

25. Univ. of TehranComputer Network25 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

26. Univ. of TehranComputer Network26 Link Layer Mechanisms Forward Error Correction (FEC) FEC incurs overhead even when errors do not occur Adaptive FEC schemes can reduce the overhead by choosing appropriate FEC dynamically Link level retransmission in case of error in the link layer. FEC to correct a small number of errors link level retransmission when FEC capability is exceeded

27. Univ. of TehranComputer Network27 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

28. Univ. of TehranComputer Network28 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

29. Univ. of TehranComputer Network29 Link Level Retransmissions Issues Retransmissions can cause head-of-the-line blocking Receiver 1 may be in a bad state, retransmissions to receiver 1 are lost, and also block a packet from being sent to receiver 2 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 Base station Receiver 1 Receiver 2

30. Univ. of TehranComputer Network30 Link Level Retransmissions 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

31. Univ. of TehranComputer Network31 A More Accurate Picture With large RTO granularity, interference is unlikely, if time required for link-level retransmission is small compared to TCP RTO 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.

32. Univ. of TehranComputer Network32 A More Accurate Picture Frequent errors increase RTO significantly on slow wireless links RTT on slow links is 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

33. Univ. of TehranComputer Network33 A More Accurate Picture Timeout interval may actually be larger than RTO Retransmission timer reset on an ack If the ack’d packet and next packet were transmitted in a burst, next packet gets an additional RTT before the timer will go off 12 dataack Timeout = RTO Effectively, Timeout = RTT of packet 1 + RTO Reset, Timeout = RTO

34. Univ. of TehranComputer Network34 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

35. Univ. of TehranComputer Network35 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

36. Univ. of TehranComputer Network36 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

37. Univ. of TehranComputer Network37 Link Level Retransmissions In-order delivery Not all connections benefit from retransmissions or ordered delivery audio Need to be able to specify requirements on a per- packet basis Should the packet be retransmitted? How many times? Enforce in-order delivery? Need a standard mechanism to specify the requirements open issue (IETF PILC working group)

38. Univ. of TehranComputer Network38 Adaptive Link Layer Strategies Adaptive protocols attempt to dynamically choose: FEC code retransmission limit frame size

39. Univ. of TehranComputer Network39 Link Layer Retransmissions 2 Mbps wireless duplex link with 1 ms delay Exponential error model No congestion losses 20 ms1 ms 10 Mbps2 Mbps

40. Univ. of TehranComputer Network40 Link Layer Schemes:Summary When is a reliable link layer beneficial to TCP performance? if it provides almost in-order delivery TCP retransmission timeout large enough to tolerate additional delays due to link level retransmits Also Hide wireless losses from TCP sender Link layer modifications needed at both ends of wireless link TCP need not be modified

41. Univ. of TehranComputer Network41 Split Connection Approach TCP connection is broken into two connections: the wired and wireless parts if wireless link is not last on route, then more than two TCP connections may be needed FH - BS connection : standard TCP selective repeat protocol on top of UDP BS - MH connection : selective repeat protocol on top of UDP FH-MH = FH-BS + BS-MH FHMHBS Base StationMobile Host Fixed Host

42. Univ. of TehranComputer Network42 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 Split connection results in independent flow control for the two parts

43. Univ. of TehranComputer Network43 Split Connection Approach : Other Variations Asymmetric transport protocol (Mobile-TCP) 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

44. Univ. of TehranComputer Network44 Split Connection Approach : Other Variations Mobile-End Transport Protocol Terminate the TCP connection at BS TCP connection runs only between BS and FH BS pretends to be MH (MH’s IP functionality moved to BS) BS guarantees reliable ordered delivery of packets to MH BS-MH link can use any arbitrary protocol optimized for wireless link

45. Univ. of TehranComputer Network45 Split Connection Approach : Hides transmission errors from sender Primary responsibility at base station If specialized transport protocol used on wireless, then wireless host also needs modification In case of Mobile host, the state of BS can be transferred.

46. Univ. of TehranComputer Network46 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 On multiple packet losses per window (timeouts can occur on the BS-MH connection, stalling during the timeout interval) Selective acks improve performance for such cases

47. Univ. of TehranComputer Network47 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

48. Univ. of TehranComputer Network48 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

49. Univ. of TehranComputer Network49 Split Connection Approach : Disadvantages 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

50. Univ. of TehranComputer Network50 Split Connection Approach : Disadvantages Buffer space needed at BS for each TCP connection BS buffers tend to get full, when wireless link slower. Window on BS-MH connection reduced in response to errors may not be an issue for wireless links with small delay-bw product

51. Univ. of TehranComputer Network51 Split Connection Approach : Disadvantages Extra copying of data at BS One for FH-BS socket buffer and one for BS-MH. 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

52. Univ. of TehranComputer Network52 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

53. Univ. of TehranComputer Network53 Snoop Protocol Buffers data packets at the base station BS to allow link layer retransmission soft state at base station, instead of hard state 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 Hides wireless losses from the sender Requires modification to only BS (network- centric approach)

54. Univ. of TehranComputer Network54 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

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

56. Univ. of TehranComputer Network56 Snoop : Example 41403839 3634 36 37 38 3539

57. Univ. of TehranComputer Network57 Snoop : Example 42413940 36 Duplicate acks are not delayed 36 dupack 37 38 39 40

58. Univ. of TehranComputer Network58 Snoop : Example 40 36 Duplicate acks 414342 37 38 39 40 41

59. Univ. of TehranComputer Network59 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

60. Univ. of TehranComputer Network60 Snoop : Example 37 36 424544 36 37 38 39 40 41 42 43 36

61. Univ. of TehranComputer Network61 Snoop : Example 42 36 434645 36 37 38 39 40 41 42 43 41 36 44 TCP sender does not fast retransmit

62. Univ. of TehranComputer Network62 Snoop : Example 43 36 444746 36 37 38 39 40 41 42 43 41 36 44 TCP sender does not fast retransmit 45

63. Univ. of TehranComputer Network63 Snoop : Example FHMHBS 44 36 454847 36 42 43 41 36 44 45 43 46

64. Univ. of TehranComputer Network64 Snoop 2 Mbps Wireless link 0 400000 800000 1200000 1600000 2000000 16K32K64K 128K256K no error 1/error rate (in bytes) bits/sec base TCP Snoop

65. Univ. of TehranComputer Network65 Snoop: When Beneficial? Snoop prevents fast retransmit despite transmission errors, and out-of-order delivery on the wireless link 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

66. Univ. of TehranComputer Network66 Snoop: 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

67. Univ. of TehranComputer Network67 Snoop: 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) 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

68. Univ. of TehranComputer Network68 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

69. Univ. of TehranComputer Network69 WTCP Example FHBSMH 33 34 Numbers in this figure are timestamps Base station residence time is 1 unit

70. Univ. of TehranComputer Network70 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

71. Univ. of TehranComputer Network71 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

72. Univ. of TehranComputer Network72 Delayed Dupacks Protocol 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)

73. Univ. of TehranComputer Network73 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

74. Univ. of TehranComputer Network74 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? 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 flows may also be blocked from being delivered to the upper layer

75. Univ. of TehranComputer Network75 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

76. Univ. of TehranComputer Network76 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

77. Univ. of TehranComputer Network77 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)

78. Univ. of TehranComputer Network78 Delayed Dupacks : Example 42413940 36 Duplicate acks are not delayed 36 dupack 37 38 39 40

79. Univ. of TehranComputer Network79 Delayed Dupacks : Example 40 36 Duplicate acks 414342 37 38 39 40 41 Original ack

80. Univ. of TehranComputer Network80 Delayed Dupacks : Example 41 36 374443 36 37 39 40 41 42 Base station forwards dupacks dupackdupacks Delayed dupack

81. Univ. of TehranComputer Network81 Delayed Dupacks : Example 37 36 424544 36 37 40 41 42 36 dupacks Delayed dupacks 43

82. Univ. of TehranComputer Network82 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

83. Univ. of TehranComputer Network83 Delayed Dupacks [Vaidya99] 2 Mbps wireless duplex link with 20 ms delay No congestion losses 20 ms 10 Mbps2 Mbps

84. Univ. of TehranComputer Network84 Delayed Dupacks [Vaidya99] 5% packet loss due to congestion 20 ms 10 Mbps2 Mbps

85. Univ. of TehranComputer Network85 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

86. Univ. of TehranComputer Network86 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

87. Univ. of TehranComputer Network87 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

88. Univ. of TehranComputer Network88 Explicit Notification Schemes 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

89. Univ. of TehranComputer Network89 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

90. Univ. of TehranComputer Network90 Space Communication Protocol Standards-Transport Protocol (SCPS-TP) Satellite Ground station wireless TCP destinations

91. Univ. of TehranComputer Network91 SCPS-TP Protocol 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)

92. Univ. of TehranComputer Network92 Explicit Loss Notification when MH is the TCP sender 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

93. Univ. of TehranComputer Network93 Explicit Bad State Notification 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

94. Univ. of TehranComputer Network94 Partial Ack Protocols 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

95. Univ. of TehranComputer Network95 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

96. Univ. of TehranComputer Network96 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

97. Univ. of TehranComputer Network97 Explicit Loss Notification 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

98. Univ. of TehranComputer Network98 Explicit Loss Notification when MH is TCP receiver 37 36 37 3839 38 Sequence numbers cached at base station 37 Dupack with ELN

99. Univ. of TehranComputer Network99 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

100. Univ. of TehranComputer Network100 Receiver-Based Scheme MH is TCP receiver which 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

101. Univ. of TehranComputer Network101 Receiver-Based Scheme Packet loss due to congestion FHMHBS 101211 FHMHBS 11 1012 T Congestion loss

102. Univ. of TehranComputer Network102 Receiver-Based Scheme Packet loss due to transmission error FHMHBS 101211 FHMHBS 101112 Error loss 2 T

103. Univ. of TehranComputer Network103 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

104. Univ. of TehranComputer Network104 Diagnostic Accuracy [Biaz99Asset] Congestion losses Error losses

105. Univ. of TehranComputer Network105 Receiver-Based Scheme : Disadvantages Disadvantages: Limited applicability 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 multiple connections on the link will make inter-packet delays variable

106. Univ. of TehranComputer Network106 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

107. Univ. of TehranComputer Network107 Sender-Based Discrimination Scheme 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)

108. Univ. of TehranComputer Network108 Heuristics for Congestion Avoidance load RTT throughput knee cliff load

109. Univ. of TehranComputer Network109 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

110. Univ. of TehranComputer Network110 Heuristics for Congestion Avoidance 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)

111. Univ. of TehranComputer Network111 Heuristics for Congestion Avoidance 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)

112. Univ. of TehranComputer Network112 Heuristics for Congestion Avoidance TCP Vegas [Brakmo94] expected throughput ET = W(i) / RTTmin actual throughput AT = W(i) / RTT(i) Condition C = ( ET-AT > beta)

113. Univ. of TehranComputer Network113 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

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

115. Univ. of TehranComputer Network115 Sender-Based Heuristics : Advantages Only sender needs to be modified Needs further investigation to develop better heuristics investigate longer-term heuristics

116. Univ. of TehranComputer Network116 Why do Statistical Technique Perform Poorly? Techniques to evaluate RTT and window size W to draw conclusions about state of the network use simple statistics. Unfortunately, correlation between RTT and W is often weak Fraction of TCP connections Coefficient of correlation (RTT,W)

117. Univ. of TehranComputer Network117 Statistical Techniques Future Work Other statistical measures ? Mechanisms that achieve good TCP throughput despite not-too-good diagnostic accuracy

118. Univ. of TehranComputer Network118 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

119. Univ. of TehranComputer Network119 TCP over Satellite Geostationary Earth Orbit (GEO) Satellite long latency transmission errors or channel unavailability Low Earth Orbit (LEO) Satellite relatively smaller delays delays more variable Problems? Long delay Large delay-bandwidth products Transmission errors

120. Univ. of TehranComputer Network120 Improving TCP-over-Satellite Larger congestion window (window scale option) maximum window size up to 2 30 Acknowledge every packet (do not delay acks) Selective acks fast recovery can only recover one packet loss per RTT SACKS allow multiple packet recovery per RTT

121. Univ. of TehranComputer Network121 Larger Initial Window Allows initial window size of cwnd to be up to approximately 4 Kbyte Larger initial window results in faster window growth during slow start avoids wait for delayed ack timers (which will occur with cwnd = 1 MSS) larger initial window requires fewer RTTs to reach ssthresh

122. Univ. of TehranComputer Network122 Byte Counting Increase window by number of new bytes ack’d in an acknowledgement, instead of 1 MSS per ack Speeds up window growth despite delayed or lost acks Need to reduce bursts from sender limiting size of window growth per ack rate control

123. Univ. of TehranComputer Network123 Space Communications Protocol Standard-Transport Protocol (SCPS-TP) [Durst96] Sender makes default assumption about source of packet loss default assumption can be set by network manager on a per-route basis default assumption can be changed due to explicit feedback from the network Congestion control algorithm derived from TCP-Vegas, to bound window growth, to reduce congestion-induced losses

124. Univ. of TehranComputer Network124 Protocol (SCPS-TP) During link outage, TCP sender freezes itself, and resumes when link is restored outage assumed to occur in both directions simultaneously ground station can detect outage of incoming link (for instance, by low signal levels), and infers outage of outgoing link ground stations provide link outage information to any sender that attempts to send packets on the outgoing link sender does not unnecessarily timeout or retransmit until it is informed that link has recovered Selective acknowledgement protocol to recover losses quickly

125. Univ. of TehranComputer Network125 Satellite Transport Protocol (STP) Uses split connection approach Protocol on satellite channel different from TCP selective negative acks when receiver detects losses no retransmission timer transmitter periodically requests receiver to ack received data reduces reverse channel bandwidth usage when losses are rare

126. Univ. of TehranComputer Network126 Early Acks Spoofing Ground station acks packets Should take responsibility for delivering packets Early acks from ground station result in faster congestion window growth ACKprime approach [Scott98] Acks from ground station only used to grow congestion window Reliable delivery assumed only on reception of an ack from the receiver this is similar to the partial ack approach [Biaz97]

127. Univ. of TehranComputer Network127 Impact of Mobility Hand-offs (in cellular wireless systems) If link layer performs hand-offs and guarantees reliability despite handoff, then TCP will not be aware of the handoff except for potential delays during handoff

128. Univ. of TehranComputer Network128 Impact of Mobility If hand-off visible to IP Need Mobile IP [Johnson96] packets may be lost while a new route is being established reliability despite handoff We consider this case

129. Univ. of TehranComputer Network129 Improving TCP in Presence of Mobility Hide mobility from the TCP sender Mobile IP Make TCP adaptive to mobility

130. Univ. of TehranComputer Network130 Example Hand-Off Procedure 1. Each base station periodically transmits beacon 2. Mobile host, on hearing stronger beacon from a new BS, sends it a greeting changes routing tables to make new BS its default gateway sends new BS identity of the old BS Old BS New BS MH 2 1 3 4 5,6 7

131. Univ. of TehranComputer Network131 Hand-Off Procedure 3. New BS acknowledges the greeting, and begins to route the MH’s packets 4. New BS informs old BS 5. Old BS changes routing table, to forward any packets for the MH to the new BS 6. Old BS sends an ack to new BS 7. New BS sends handoff-completion message to MH Old BS New BS MH 2 1 3 4 5,6 7

132. Univ. of TehranComputer Network132 Hand-off Hand-offs may result in temporary loss of route to MH with non-overlapping cells, it may be a while before the mobile host receives a beacon from the new BS While routes are being reestablished during handoff, MH and old BS may attempt to send packets to each other, resulting in loss of packets

133. Univ. of TehranComputer Network133 Using Fast Retransmits to Recover from Timeouts during Handoff [Caceres95] During the long delay for a handoff to complete, a whole window worth of data may be lost After handoff is complete, acks are not received by the TCP sender Sender eventually times out, and retransmits If handoff still not complete, another timeout will occur Performance penalty Time wasted until timeout occurs Window shrunk after timeout

134. Univ. of TehranComputer Network134 0-second Rendezvous Delay : Beacon arrives as soon as cell boundary crossed Last timed transmit Cell crossing + beacon arrives Handoff complete Routes updated Retransmission timeout 00.15 0.8 sec 1.0 Packet loss Idle sender

135. Univ. of TehranComputer Network135 1-second Rendezvous Delay : Beacon arrives 1 second after cell boundary crossed Last timed transmit 0 0.8 2.0 Timeout 1 Cell crossing Packet loss Retransmission timeout 2 Handoff complete Beacon arrives 1.0 1.15 Idle sender 2.8 sec

136. Univ. of TehranComputer Network136 Performance [Caceres95] Four environments 1. No moves 2. Moves (once per 8 sec) between overlapping cells 3. Moves between non-overlapping cells, 0 sec delay 4. Moves between non-overlapping cells, 1 sec delay Experiments using 2 Mbps WaveLan

137. Univ. of TehranComputer Network137 TCP Performance

138. Univ. of TehranComputer Network138 TCP Performance Degradation in case 2 (overlapping cells) is due to encapsulation and forwarding delay during handoff Additional degradation in cases 3 and 4 due to packet loss and idle time at sender

139. Univ. of TehranComputer Network139 Mitigation Using Fast Retransmit When MH is the TCP receiver: after handoff is complete, it sends 3 dupacks to the sender this triggers fast retransmit at the sender instead of dupacks, a special notification could also be sent When MH is the TCP sender: invoke fast retransmit after completion of handoff

140. Univ. of TehranComputer Network140 0-second Rendezvous Delay Improvement using Fast Retransmit Last timed transmit Cell crossing + beacon arrives Handoff complete Routes updated Retransmission timeout does not occur 00.15 0.8 1.0 Packet loss Fast retransmit Idle sender

141. Univ. of TehranComputer Network141 TCP Performance Improvement

142. Univ. of TehranComputer Network142 TCP Performance Improvement No change in cases 1 and 2, as expected Improvement for non-overlapping cells Some degradation remains in case 3 and 4 fast retransmit reduces congestion window

143. Univ. of TehranComputer Network143 Improving Performance by Smooth Handoffs [Caceres95] Provide sufficient overlap between cells to avoid packet loss Buffer packets at BS Discard the packets after a short interval If handoff occurs before the interval expires, forward the packets to the new base station Prevents packet loss on handoff

144. Univ. of TehranComputer Network144 M-TCP [Brown97] In the fast retransmit scheme [Caceres95] sender starts transmitting soon after handoff BUT congestion window shrinks M-TCP attempts to avoid shrinkage in the congestion window

145. Univ. of TehranComputer Network145 M-TCP Uses TCP Persist Mode When a new ack is received with receiver’s advertised window = 0, the sender enters persist mode Sender does not send any data in persist mode except when persist timer goes off When a positive window advertisement is received, sender exits persist mode On exiting persist mode, RTO and cwnd are same as before the persist mode

146. Univ. of TehranComputer Network146 M-TCP Similar to the split connection approach, M-TCP splits one TCP connection into two logical parts the two parts have independent flow control as in I-TCP The BS does not send an ack to MH, unless BS has received an ack from MH maintains end-to-end semantics BS withholds ack for the last byte ack’d by MH FHMHBS Ack 1000Ack 999

147. Univ. of TehranComputer Network147 M-TCP Withheld ack sent with window advertisement = 0, if MH moves away (handoff in progress) Sender FH put into persist mode during handoff Sender exits persist mode after handoff, and starts sending packets using same cwnd as before handoff FHMHBS

148. Univ. of TehranComputer Network148 M-TCP The last ack is not withheld, if BS does not expect any other ack from the MH this happens when the BS has no other unack’d data buffered locally this is required to prevent a sender timeout at the end of a transfer (or end of a burst of data)

149. Univ. of TehranComputer Network149 M-TCP Avoids reduction of congestion window due to handoff, unlike the fast retransmit scheme simulation-based performance results look good Important Question unanswered : Is not reducing the window a good idea? When host moves, route changes, and new route may be more congested than before. It is not obvious that starting full speed after handoff is right.

150. Univ. of TehranComputer Network150 FreezeTCP [Goff99] M-TCP needs help from base station Base station withholds ack for one byte The base station uses this ack to send a zero window advertisement when a mobile host moves to another cell FreezeTCP requires the receiver to send zero window advertisement (ZWA) FHMHBS Mobile TCP receiver

151. Univ. of TehranComputer Network151 FreezeTCP [Goff99] TCP receiver determines if a handoff is about to happen determination may be based on signal strength Ideally, receiver should attempt to send ZWA 1 RTT before handoff Receiver sends 3 dupacks when route is reestablished No help needed from the base station an end-to-end enhancement FHMHBS Mobile TCP receiver

152. Univ. of TehranComputer Network152 Using Multicast to Improve Handoffs [Ghai94,Seshan96] Define a group of base stations including current cell of a mobile host cells that the mobile host is likely to visit next Address packets destined to the mobile host to the group Only one base station transmits the packets to the mobile host if rest of them buffer the packets, then packet loss minimized on handoff

153. Univ. of TehranComputer Network153 Using Multicast to Improve Handoffs Static group definition [Ghai94] groups can be defined taking physical topology into account static definition may not take individual user mobility pattern into account Dynamic group definition [Seshan96] implemented using IP multicast groups each user’s group can be different overhead of updating the multicast groups is a concern with a large scale deployment

154. Univ. of TehranComputer Network154 Using Multicast to Improve Handoffs Buffering at multiple base stations incurs memory overhead Trade-off between buffering overhead and packet loss Buffer requirement can be reduced by starting buffering only when a mobile host is likely to leave current cell soon

155. Univ. of TehranComputer Network155 Issues for Further Investigation

156. Univ. of TehranComputer Network156 Link Layer Protocols “Pure” link layer designs that support higher transport performance some recent work in this area as noted earlier Identifying scenarios where link layer solutions are inadequate If TCP-awareness is absolutely needed, provide an interface that can be used by other transport protocols too

157. Univ. of TehranComputer Network157 End-to-End Techniques Existing techniques typically require cooperation from intermediate nodes. Such techniques often not applicable encrypted TCP headers TCP data and acks do not go through same base station End-to-end techniques would rely on information available only at end nodes Harder to design due to lack of complete information about errors Explicit Notifications may make that easier

158. Univ. of TehranComputer Network158 Impact of Congestion Losses Past work typically evaluates performance in absence of congestion Relative performance improvement may change substantially when congestion occurs performance improvement may reduce if congestion is dominant, or if RTO becomes larger due to wireless errors

159. Univ. of TehranComputer Network159 Multiple TCP Transfers Past work typically measures a single TCP connection over wireless TCP throughput is the metric of choice When multiple connections share a wireless link, other performance metrics may make sense fairness aggregate throughput Relative performance improvements of various schemes may change when multiple connections are considered

160. Univ. of TehranComputer Network160 TCP Window & RTO Settings After a Move Congestion window & RTO size at connection open are chosen to be conservative When a route change occurs due to mobility, which values to use? Same as before route change ---- may be too aggressive Same as at connection open ---- may be too conservative Answer unclear some proposals attempt to use same values as before route change, but not clear if that is the best alternative