1 / 51

TCP Over Wireless

TCP Over Wireless. Professor Alhussein Abouzeid Rensselaer Polytechnic Institute 110 Eighth St, Troy NY 12180. Slides adapted from Nitin Vaidya’s Tutorial and others – see referene list. Transmission Control Protocol / Internet Protocol TCP / IP. Internet Protocol (IP).

arch
Download Presentation

TCP Over Wireless

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TCP Over Wireless Professor Alhussein Abouzeid Rensselaer Polytechnic Institute 110 Eighth St, Troy NY 12180 Slides adapted from Nitin Vaidya’s Tutorial and others – see referene list

  2. Transmission Control Protocol / Internet ProtocolTCP/IP

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

  4. Transmission Control Protocol (TCP) • Reliable ordered delivery to the higher layer • 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

  5. 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, and assume equal size packets • Also, we use slightly different syntax for acks than normal TCP syntax • In our notation, ack i acknowledges receipt of packets through packet i

  6. TCP • Adaptive mechanism for congestion control • The concept (AIMD): • Speed-up (additive) • Slow-down (multiplicative) • The elements: packets, ACKs, window • The mechanism • Window increase modes: • Slow Start (exp.), Congestion Avoidance (add.) • Loss detection modes: • Triple Duplicates; ‘single’ loss; MD • Time-Out; ‘burst’ loss; reset

  7. Simple Ns Simulation • Topology B m Source Destination t ACKs • Animation

  8. TCP: Window Trace Low Loss Rate High Loss Rate

  9. Acknowledgements (ACKs) • A new cumulative ACK is generated only on receipt of a newin-sequence packet • A dupack is generated whenever an out-of-order segment arrives at the receiver • a packet is lost, or • a packet is delivered out-of-order (OOO) • Delayed ACKs: An ack is delayed until • another new packet is received, or • delayed ack timer expires (200 ms typical) Reduces ack traffic • Duplicate acks are not delayed

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

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

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

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

  14. Detecting Packet Loss Using 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

  15. RTO calculation • RTO = mean + 4 mean deviation • Standard deviation s : s = average of (sample – mean) • Mean deviation d = average of |sample – mean| • Mean deviation easier to calculate than standard deviation • Mean deviation is more conservative: d >= s • Large variations in the RTT increase the deviation, leading to larger RTO • Sudden RTT increase may cause unnecessary (spurious) RTO 2 2

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

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

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

  19. Congestion Avoidance • On each window’s worth of new acks, increase cwnd by 1/cwnd packets • cwnd increases linearly with time during congestion avoidance (assuming cwnd is less than bandwidth-delay product) • 1/2 MSS per RTT if every other packet ack’d • 1 MSS per RTT if every packet ack’d

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

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

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

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

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

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

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

  27. Wireless Ad-hoc Networks • Ad-hoc Network scenario

  28. Ad-hoc Network scenario

  29. Multi-Hop Wireless • May need to traverse multiple links to reach a destination

  30. Multi-Hop Wireless - MobilityMobile Ad Hoc Networks (MANET) • Mobility causes route changes

  31. Satellites • Geostationary Earth Orbit (GEO) Satellites • example: Inmarsat SAT ground stations

  32. Satellites • Low-Earth Orbit (LEO) Satellites • example: Iridium (66 satellites) (2.4 Kbps data) SAT constellation SAT SAT ground stations

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

  34. 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, Nokia) • Long or variable latency • GEO, LEO satellites • Packet radio - high variability • Asymmetry in bandwidth, error characteristics • Satellites (example: DirectPC)

  35. Impact of transmission errorson TCP performance

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

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

  38. 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]

  39. 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 • Slow fading • Timeout results in slow start • Slow start reduces congestion window to 1 MSS, reducing throughput • Reduction in window in response to errors unnecessary

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

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

  42. Abrupt Delay Variations • Abrupt RTT Increase (beyond RTO value) RTO • Abrupt RTT Decrease  Out of order delivery (OOO)Spurious Retransmissions

  43. This Lecture • We consider errors for which reducing congestion window is an inappropriate response

  44. Lecture Outline • TCP basics • Wireless technologies • Impact of transmission errors on TCP performance • Approaches to improve TCP performance • Classification • Discussion of selected approaches

  45. Schemes to Improve Performance of TCP in Presence of Transmission Errors

  46. Techniques to Improve TCP Performancein Presence of ErrorsClassification 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

  47. Techniques to Improve TCP Performancein Presence of ErrorsClassification 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

  48. Techniques to Improve TCP Performancein Presence of ErrorsClassification 3 Classification based on where the solution approach is applicable • Last-hop wireless (cellular) • Single wireless link (Internet) • Multiple wired/wireless only links (Internet/Satellite) • Multi-hop mobile wireless links (Ad-hoc)

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

  50. References-1 • J. Hoe, "Improving the start-up behavior of a congestion control scheme for TCP," in Proceedings of ACM SIGCOMM '96, August 1996. •  M. Mathis, J. Mahdavi, and S. Floyd, "TCP selective acknowledgement options," October 1996. RFC 2018. •  P. Karn, "Re: Pilc: prioritization," January 1999. E-mail posting on the IETF PILC working group mailing list. Archive available at http://pilc.grc.nasa.gov. •  V. Padmanabhan, "Re: Pilc: prioritization," January 1999. E-mail posting on the IETF PILC working group mailing list. Archive available at http://pilc.grc.nasa.gov •  S. Dawkins, a. Montenegro, M. Kojo, V. Magret, and N. H. Vaidya, "Performance implications of link-layer characteristics: Links with errors," tech. rep., PILC, Internet Engineering Task Force (Internet Draft), June 1999. •  S. Lin and D. J. Costello Jr., Error Control Coding: Fundamentals and Applications. Prentice- Hall, Englewood Cliffs, NJ, 1983. •  D. A. Eckhardt and P. Steenkiste, "Improving wireless LAN performance via adaptive local error control," in Int. Conf. Network Protocols, pp. 327-338, 1998. •  A. DeSimone, M. Chuah, and 0. Yue, "Throughput performance of transport-layer protocols over wireless LANs," in Proc. Globecom '93, December 1993. •  S. Seshan, H. Balakrishnan, and R. Katz, "Handoffs in cellular wireless networks: The daedalus implementation and experience," Kluwer International Jouranl on Wireless Communication Systems, 1996. •  R. Ludwig and B. Rathonyi, "Multi-layer tracing of TCP over a reliable wireless link," in ACM SIGMETRICS, 1998. •  R. Ludwig, "A case for flow-adaptive wireless links," Tech. Rep. UCBjCSD-99-1053, CS Dep., University of California, Berkley, May 1999. http://iceberg.cs.berkeley.edujpublications.html. •  D. A. Eckhardt and P. Steenkiste, "Improving wireless LAN performance via adaptive local error control," in Int. Conf. Network Protocols, pp. 327-338, 1998. •  G. Holland and N. H. Vaidya, "Analysis ofTCP performance over mobile ad hoc networks," in International Conference on Mobile Computing and Networking (MOBICOM), August 1999. •  A. Bakre and B. Badrinath, "I-Tap: Indirect Tap for mobile hosts," in Proc. 15th Interna- tional Conf. on Distributed Computing Systems (ICDCS), May 1995. •  R. Yavatkar and N. Bhagwat, "Improving end-to-end performance of TCP over mobile inter-networks," in Workshop on Mobile Computing Systems and Applications, December 1994. •  Z. Haas and P. Agrawal, "Mobile-TCP: An asymmetric transport protocol design for mobile systems," in ICC'97, Montreal, Canada, June 1997.

More Related