Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 TCP for Wireless and Mobile Hosts Nitin H. Vaidya University of Illinois at Urbana-Champaign © 2001 Nitin.

Similar presentations


Presentation on theme: "1 TCP for Wireless and Mobile Hosts Nitin H. Vaidya University of Illinois at Urbana-Champaign © 2001 Nitin."— Presentation transcript:

1 1 TCP for Wireless and Mobile Hosts Nitin H. Vaidya University of Illinois at Urbana-Champaign nhv@uiuc.edu http://www.crhc.uiuc.edu/~nhv © 2001 Nitin Vaidya

2 2 Notes  Names in brackets, as in [Vaidya99], refer to a document in the list of references  Many charts included in these slides are based on similar results presented in graphs in published literatures. Since, in many cases, exact numbers are not provided in the papers, the charts in these slides are based on “guess-timates” obtained from published graphs. Please refer original sources for accurate data.  This handout may not be as readable as the original slides, since the slides contain colored text and figures.

3 3 Notes  PowerPoint source for tutorial slides and reference list for the tutorial are presently available at http://www.cs.tamu.edu/faculty/vaidya/ (follow the link to Seminars)

4 4 Internet Engineering Task Force (IETF) Activities  IETF pilc (Performance Implications of Link Characteristics) working group  http://www.ietf.org/html.charters/pilc-charter.html http://www.ietf.org/html.charters/pilc-charter.html  http://pilc.grc.nasa.gov http://pilc.grc.nasa.gov  Refer [Dawkins99] and [Montenegro99] for an overview of related work  IETF tcpsat (TCP Over Satellite) working group  http://www.ietf.org/html.charters/tcpsat-charter.html http://www.ietf.org/html.charters/tcpsat-charter.html  http://tcpsat.grc.nasa.gov/tcpsat/ http://tcpsat.grc.nasa.gov/tcpsat/  Refer [Allman98] for overview of satellite related work

5 5 Internet Engineering Task Force (IETF) Activities  IETF manet (Mobile Ad-hoc Networks) working group  http://www.ietf.org/html.charters/manet-charter.html http://www.ietf.org/html.charters/manet-charter.html  IETF mobileip (IP Routing for Wireless/Mobile Hosts) working group  http://www.ietf.org/html.charters/mobileip-charter.html http://www.ietf.org/html.charters/mobileip-charter.html

6 6 Tutorial Outline  Wireless technologies  TCP basics  Impact of transmission errors on TCP performance  Approaches to improve TCP performance  Classification  Discussion of selected approaches  TCP over satellite

7 7 Tutorial Outline  Impact of mobility on TCP performance  Approaches to improve TCP performance in presence of mobility  Issues in multi-hop wireless networks  Issues needing further work  References

8 8 Notable Omissions  Wireless ATM  WAP (Wireless Application Protocol) http://www.wapforum.com

9 9 Wireless Technologies

10 10 Wireless Technologies  Wireless local area networks  Cellular wireless  Satellites  Multi-hop wireless  Wireless local loop

11 11 Wireless Local Area Networks  Local area connectivity using wireless communication  IEEE 802.11 WLAN Standard  Example: WaveLan, Aironet  Wireless LAN may be used for  last hop to a wireless host  wireless connectivity between hosts on the LAN

12 12 Cellular Wireless  Space divided into cells  A base station is responsible to communicate with hosts in its cell  Mobile hosts can change cells while communicating  Hand-off occurs when a mobile host starts communicating via a new base station

13 13 Multi-Hop Wireless  May need to traverse multiple links to reach a destination

14 14 Multi-Hop Wireless - Mobility Mobile Ad Hoc Networks (MANET)  Mobility causes route changes

15 15 Multi-Hop Wireless Metricom’s Ricochet Network  Around 28.8 Kbps (128 Kbps to come) Poletop radio Wireless hosts internet modem

16 16 Satellites  Geostationary Earth Orbit (GEO) Satellites  example: Inmarsat SAT ground stations

17 17 Satellites  Low-Earth Orbit (LEO) Satellites  example: Iridium (66 satellites) (2.4 Kbps data) SAT ground stations SAT constellation

18 18 Satellites  GEO  long delay - 250-300 ms propagation delay  LEO  relatively low delay - 40 - 200 ms  large variations in delay - multiple hops/route changes, relative motion of satellites, queueing

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

20 20 Transmission Control Protocol / Internet Protocol TCP/IP

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

22 22 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

23 23 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

24 24 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

25 25 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

26 26 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

27 27 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

28 28 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

29 29 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

30 30 Window Based Flow Control 23456789101113112 Sender’s window 23456789101113112 Sender’s window Ack 5

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

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

33 33 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

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

35 35 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

36 36 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

37 37 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

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

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

40 40 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

41 41 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

42 42 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

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

44 44 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

45 45 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

46 46 ssthresh = 8 ssthresh = 10 cwnd = 20 After timeout

47 47 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

48 48 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

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

50 50 TCP Reno  Slow-start  Congestion avoidance  Fast retransmit  Fast recovery

51 51 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

52 52 Impact of transmission errors on TCP performance

53 53 Tutorial Outline  Wireless technologies  TCP basics  Impact of transmission errors on TCP performance  Approaches to improve TCP performance  Classification  Discussion of selected approaches

54 54 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

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

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

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

58 58 Random Errors May Cause Fast Retransmit 40 36 Duplicate acks 414342

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

60 60 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

61 61 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]

62 62 This Tutorial  We consider errors for which reducing congestion window is an inappropriate response

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

64 64 Note  Since results from different papers are not necessarily obtained using same system model, comparison of absolute numbers in different graphs may not be valid  Observe trends, rather than absolute numbers

65 65 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

66 66 Random Errors May Also Cause Timeout  Multiple packet losses in a window can result in timeout when using TCP-Reno (and to a lesser extent when using SACK)

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

68 68 Tutorial Outline  Wireless technologies  TCP basics  Impact of transmission errors on TCP performance  Approaches to improve TCP performance  Classification  Discussion of selected approaches

69 69 Classification of Schemes to Improve Performance of TCP in Presence of Transmission Errors

70 70 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

71 71 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

72 72 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

73 73 Tutorial Outline  Wireless technologies  TCP basics  Impact of transmission errors on TCP performance  Approaches to improve TCP performance  Classification  Discussion of selected approaches

74 74 Selected Schemes to Improve Performance of TCP in Presence of Transmission Errors

75 75 Caveat  When describing various schemes, only the major features are presented  Often, some additional features are present in these schemes, to optimize their performance  We will not cover all the details, only the most relevant ones

76 76 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]

77 77 Link Level Mechanisms

78 78 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

79 79 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

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

81 81 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

82 82 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

83 83 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

84 84 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

85 85 Link Level Retransmissions Issues  Retransmissions can cause congestion losses  Attempting to retransmit a packet at the front of the queue, effectively reduces the available bandwidth, potentially making the queue at base station longer  If the queue gets full, packets may be lost, indicating congestion to the sender  Is this desirable or not ? Base station Receiver 1 Receiver 2

86 86 Link Level Retransmissions An Early Study [DeSimone93]  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

87 87 RTO Variations Packet loss RTT sample RTO Wireless

88 88 A More Accurate Picture  Analysis in [DeSimone93] does not accurately model real TCP stacks  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]

89 89 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

90 90 Link-Layer Retransmissions A More Accurate Picture [Ludwig98]  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

91 91 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

92 92 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

93 93 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

94 94 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 [Ludwig99]  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)

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

96 96 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

97 97 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

98 98 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

99 99 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

100 100 Split Connection Approach

101 101 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

102 102 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

103 103 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

104 104 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

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

106 106 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

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

108 108 Split Connection Approach : Other Variations  Mobile-End Transport Protocol [Wang98infocom]  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  Idea similar to [Yavatkar94]

109 109 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

110 110 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

111 111 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

112 112 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

113 113 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

114 114 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

115 115 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

116 116 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

117 117 TCP-Aware Link Layer

118 118 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

119 119 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

120 120 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

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

122 122 Snoop : Example 41403839 3634 36 37 38 3539

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

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

125 125 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

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

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

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

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

130 130 Snoop [Balakrishnan95acm] 2 Mbps Wireless link

131 131 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

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

133 133 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

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

135 135 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

136 136 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

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

138 138 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

139 139 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

140 140 TCP-Unaware Approximation of TCP-Aware Link Layer

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

142 142 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

143 143 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

144 144 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

145 145 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

146 146 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

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

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

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

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

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

152 152 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

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

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

155 155 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

156 156 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

157 157 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

158 158 Explicit Notification

159 159 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

160 160 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

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

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

163 163 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

164 164 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

165 165 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

166 166 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

167 167 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

168 168 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

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

170 170 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

171 171 Receiver-Based Discrimination Scheme

172 172 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

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

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

175 175 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

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

177 177 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

178 178 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

179 179 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

180 180 Sender-Based Discrimination Scheme

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

182 182 Heuristics for Congestion Avoidance load RTT throughput knee cliff

183 183 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

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

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

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

187 187 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

188 188 Sender-Based Schemes Diagnostic Accuracy [Biaz99ic3n]

189 189 Sender-Based Schemes Diagnostic Accuracy [Biaz99ic3n]

190 190 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

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

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

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

194 194 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

195 195 Tutorial Outline  Schemes to improves TCP performance in presence of transmission errors  TCP over Satellite  Impact of mobility on TCP performance  Approaches to improve TCP performance in presence of mobility  Issues in multi-hop wireless networks  Issues needing further work  References

196 196 TCP Over Satellite

197 197 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

198 198 Problems Addressed by Various Schemes  Long delay  Large delay-bandwidth products  Transmission errors

199 199 Improving TCP-over-Satellite [Allman98sept][IETF-TCPSAT]  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

200 200 Larger Initial Window [Allman98september] [Allman98august]  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

201 201 Byte Counting [Allman98august]  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

202 202 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

203 203 Space Communications Protocol Standard- Transport 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

204 204 Satellite Transport Protocol (STP) [Henderson98]  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

205 205 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]

206 206 Tutorial Outline  TCP over Satellite  Impact of mobility on TCP performance  Approaches to improve TCP performance in presence of mobility  Issues in multi-hop wireless networks  Issues needing further work  References

207 207 Impact of Mobility on TCP Performance

208 208 Impact of Mobility  Hand-offs occur when a mobile host starts communicating with a new base station (in cellular wireless systems)

209 209 Impact of Mobility  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

210 210 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

211 211 Mobile IP [Johnson96] Router 1 Router 3 Router 2 S MH Home agent

212 212 Mobile IP [Johnson96] Router 1 Router 3 Router 2 SMH Home agent Foreign agent move Packets are tunneled using IP in IP

213 213 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

214 214 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

215 215 Mobile IP  Mobile IP would need to modify the previous hand-off procedure to inform the home agent the identity of the new foreign agent  Triangular optimization can reduce the routing delay  Route directly to foreign agent, instead of via home agent

216 216 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

217 217 Impact of Handoffs on Schemes to Improves Performance in Presence of Errors  Split connection approach  hard state at base station must be moved to new base station  Snoop protocol  soft state need not be moved  while the new base station builds new state, packet losses may not be recovered locally  Frequent handoffs a problem for schemes that rely on significant amount of hard/soft state at base stations  hard state should not be lost  soft state needs to be recreated to benefit performance

218 218 Techniques to Improve TCP Performance in Presence of Mobility

219 219 Classification  Hide mobility from the TCP sender  Make TCP adaptive to mobility

220 220 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

221 221 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

222 222 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

223 223 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

224 224 TCP Performance

225 225 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

226 226 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

227 227 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

228 228 TCP Performance Improvement

229 229 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

230 230 Improving Performance by Smooth Handoffs [Caceres95]  Provide sufficient overlap between cells to avoid packet loss or  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

231 231 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

232 232 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

233 233 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

234 234 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

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

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

237 237 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

238 238 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

239 239 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

240 240 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

241 241 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

242 242 Tutorial Outline  TCP over Satellite  Impact of mobility on TCP performance  Approaches to improve TCP performance in presence of mobility  Issues in multi-hop wireless networks  Issues needing further work  References

243 243 TCP in Mobile Ad Hoc Networks

244 244 Mobile Ad Hoc Networks (MANET)  May need to traverse multiple links to reach a destination

245 245 Mobile Ad Hoc Networks [IETF-MANET]  Mobility causes route changes

246 246 TCP in Mobile Ad Hoc Networks Issues  Route changes due to mobility  Wireless transmission errors  problem compounded with multiple hops  Out-of-order packet delivery  frequent route changes may cause out-of-order delivery  TCP does not perform well if packets are significantly OOO  Multiple access protocol  choice of MAC protocol can impact TCP performance significantly  Half-duplex radios  cannot send and receive packets simultaneously  changing mode (send or receive) incurs overhead

247 247 Throughput over Multi-Hop Wireless Paths [Gerla99]  When contention-based MAC protocol is used, connections over multiple hops are at a disadvantage compared to shorter connections, because they have to contend for wireless access at each hop  extent of packet delay or drop increases with number of hops

248 248 Impact of Multi-Hop Wireless Paths [Holland99] TCP Throughput using 2 Mbps 802.11 MAC

249 249 Ideal Throughput  f(i) = fraction of time for which shortest path length between sender and destination is I  T(i) = Throughput when path length is I  From previous figure  Ideal throughput =  f(i) * T(i)

250 250 Impact of Mobility TCP Throughput Ideal throughput (Kbps) Actual throughput 2 m/s10 m/s

251 251 Impact of Mobility Ideal throughput Actual throughput 20 m/s 30 m/s

252 252 Throughput generally degrades with increasing speed … Speed (m/s) Average Throughput Over 50 runs Ideal Actual

253 253 But not always … Mobility pattern # Actual throughput 20 m/s 30 m/s

254 254 mobility causes link breakage, resulting in route failure TCP data and acks en route discarded Why Does Throughput Degrade? TCP sender times out. Starts sending packets again Route is repaired No throughput despite route repair

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

256 256 Why Does Throughput Improve? Low Speed Scenario C B D A C B D A C B D A 1.5 second route failure Route from A to D is broken for ~1.5 second. When TCP sender times after 1 second, route still broken. TCP times out after another 2 seconds, and only then resumes.

257 257 Why Does Throughput Improve? Higher (double) Speed Scenario C B D A C B D A C B D A 0.75 second route failure Route from A to D is broken for ~ 0.75 second. When TCP sender times after 1 second, route is repaired.

258 258 Why Does Throughput Improve? General Principle  TCP timeout interval somewhat (not entirely) independent of speed  Network state at higher speed, when timeout occurs, may be more favorable than at lower speed  Network state  Link/route status  Route caches  Congestion

259 259 How to Improve Throughput (Bring Closer to Ideal)  Network feedback  Inform TCP of route failure by explicit message  Let TCP know when route is repaired  Probing  Explicit notification  Reduces repeated TCP timeouts and backoff

260 260 Performance Improvement Without network feedback Ideal throughput 2 m/s speed With feedback Actual throughput

261 261 Performance Improvement Without network feedback With feedback Ideal throughput 30 m/s speed Actual throughput

262 262 Performance with Explicit Notification [Holland99]

263 263 Issues Network Feedback  Network knows best (why packets are lost) + Network feedback beneficial - Need to modify transport & network layer to receive/send feedback  Need mechanisms for information exchange between layers

264 264 Impact of Caching  Route caching has been suggested as a mechanism to reduce route discovery overhead [Broch98]  Each node may cache one or more routes to a given destination  When a route from S to D is detected as broken, node S may:  Use another cached route from local cache, or  Obtain a new route using cached route at another node

265 265 To Cache or Not to Cache Average speed (m/s) Actual throughput (as fraction of expected throughput)

266 266 Why Performance Degrades With Caching  When a route is broken, route discovery returns a cached route from local cache or from a nearby node  After a time-out, TCP sender transmits a packet on the new route. However, the cached route has also broken after it was cached  Another route discovery, and TCP time-out interval  Process repeats until a good route is found timeout due to route failure timeout, cached route is broken timeout, second cached route also broken

267 267 Issues To Cache or Not to Cache  Caching can result in faster route “repair”  Faster does not necessarily mean correct  If incorrect repairs occur often enough, caching performs poorly  Need mechanisms for determining when cached routes are stale

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

269 269 Issues Window Size After Route Repair  Same as before route break: may be too optimistic  Same as startup: may be too conservative  Better be conservative than overly optimistic  Reset window to small value after route repair  Impact low on paths with small delay-bw product

270 270 Issues RTO After Route Repair  Same as before route break  If new route long, this RTO may be too small, leading to timeouts Except when RTT small compared to clock granularity  Same as TCP start-up (6 second)  May be too large  Will result in slow response to future losses  Proposal: new RTO = function of old RTO, old route length, and new route length  Example: new RTO = old RTO * new route length / old route length  Not evaluated yet

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

272 272 Impact of MAC - Delay Variability [Balakrishnan97] Several techniques may be used to mitigate problem, based on minimizing ack transmissions  to reduce frequency of send-receive turnaround and contention between acks and data  Piggybacking link layer acks with data  Sending fewer TCP acks - ack every d-th packet (d may be chosen dynamically) but need to use rate control at sender to reduce burstiness (for large d)  Ack filtering - Gateway may drop an older ack in the queue, if a new ack arrives  reduces number of acks that need to be delivered to the sender

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

274 274 Other Topics

275 275 Header Compression for Wireless Networks [Degermark96]  In TCP packet stream, most header bits are identical  Van Jacobson’s scheme exploits this observation to compress headers, by only sending the “delta” between the previous and current header  Packet losses result in inefficiency, as headers cannot be reconstructed due to lost information  Packet losses likely on wireless links  [Degermark96] proposes a technique that works well despite single packet loss  “twice” algorithm  if current packet fails TCP checksum, assume that a single packet is lost  apply delta for the previous packet twice to the current header, and test checksum again

276 276 Twice Algorithm : Example delta2 delta

277 277 Channel State Dependent Packet Scheduling [Bhagwat96]  Head-of-the Line blocking can occur with FIFO (first- in-first-out) scheduling, if sender attempts to retransmit packets on a channel in a bad state M1M2M3M2M1 Wireless card M1 M2 M3

278 278 Channel State Dependent Packet Scheduling  Separate queue for each destination  Channel state monitor somehow determines if a channel is in burst error state M1 M2 M3 M2 M1 Wireless card M1 M2 M3 scheduler Channel status monitor Per destination queues

279 279 Channel State Dependent Packet Scheduling  Packets transmitted on bad channels, only if packets for no other channels present in queues M1 M2 M3 M2 M1 Wireless card M1 M2 M3 scheduler Channel status monitor Per destination queues

280 280 Channel State Dependent Packet Scheduling  Needs a reasonably good Channel State Monitor M1 M2 M3 M2 M1 Wireless card M1 M2 M3 scheduler Channel status monitor Per destination queues

281 281 Automatic TCP Buffer Tuning [Semke98]  Using too small buffers can yield poor performance  Using too large buffers can limit number of open connections  Automatic mechanisms to choose buffer size dynamically would be useful

282 282 Tutorial Outline  TCP over Satellite  Impact of mobility on TCP performance  Approaches to improve TCP performance in presence of mobility  Issues in multi-hop wireless networks  Issues needing further work  References

283 283 Issues for Further Investigation

284 284 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

285 285 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

286 286 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

287 287 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

288 288 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

289 289 TCP for Mobile Ad Hoc Networks  Much work on routing in ad hoc networks  Some recent work on TCP for ad hoc networks  Need to investigate many issues  MAC-TCP interaction  routing-TCP interaction  impact of route changes on window size, RTO choice after move

290 290 References  Please see attached listing for the references cited in the tutorial

291 291 Thank you !! For more information, send e-mail to Nitin Vaidya at nhv@uiuc.edu © 2001 Nitin Vaidya


Download ppt "1 TCP for Wireless and Mobile Hosts Nitin H. Vaidya University of Illinois at Urbana-Champaign © 2001 Nitin."

Similar presentations


Ads by Google