tcp over wireless

TCP Over Wireless

Professor Alhussein Abouzeid

Rensselaer Polytechnic Institute

110 Eighth St, Troy NY 12180Slides adapted from Nitin Vaidya’s Tutorial and others – see referene list

Transmission Control Protocol / Internet Protocol

TCP/IP

Internet Protocol (IP)

• Packets may be delivered out-of-order

• Packets may be lost

• Packets may be duplicated

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

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

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

Simple Ns Simulation

• Topology

DestinationSourceB

ACKs

Animation

TCP: Window Trace

Low Loss Rate

High Loss Rate

Acknowledgements (ACKs)• A new cumulative ACK is generated only on receipt of a

new in-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

Ack Clock

• TCP window flow control is “self-clocking”

• New data sent when old data is ack’d

• Helps maintain “equilibrium”

Window Based Flow Control

• Congestion window size bounds the amount of data that can be sent per round-trip time

• Throughput <= W / RTT

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

How does TCP detect a packet loss?

• Retransmission timeout (RTO)

• Duplicate acknowledgements

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

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

• Sudden RTT increase may cause unnecessary (spurious) RTO

2 2

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

Exponential Backoff

• Double RTO on each timeout

Packettransmitted

Time-out occursbefore ack received,packet retransmitted

Timeout interval doubled

T1 T2 = 2 * T1

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

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

0

2

4

6

8

10

12

14

0 1 2 3 4 5 6 7 8

Time (round trips)

Con

gest

ion

Win

dow

size

(s

egm

ents

)

Slow start

Congestionavoidance

Slow start threshold

Example assumes that acks are not delayed

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

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

0

5

10

15

20

25

Time (round trips)

Con

gest

ion

win

dow

(seg

men

ts)

ssthresh = 8 ssthresh = 10

cwnd = 20

After timeout

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

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

0

2

4

6

8

10

Time (round trips)

Win

dow

size

(seg

men

ts)

After fast retransmit and fast recovery window size isreduced in half.

Receiver’s advertized window

After fast recovery

Wireless Ad-hoc Networks

– Ad-hoc Network scenario

– Ad-hoc Network scenario

Multi-Hop Wireless

• May need to traverse multiple links to reach a destination

Multi-Hop Wireless - MobilityMobile Ad Hoc Networks (MANET)

• Mobility causes route changes

Satellites

• Geostationary Earth Orbit (GEO) Satellites– example: Inmarsat

SAT

ground stations

Satellites• Low-Earth Orbit (LEO) Satellites

– example: Iridium (66 satellites) (2.4 Kbps data)

SAT

ground stations

SAT

SAT

constellation

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

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)

Impact of transmission errorson TCP performance

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

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

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]

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

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)

Impact of Transmission Errors

• TCP cannot distinguish between packet losses due to congestion and transmission errors

• Unnecessarily reduces congestion window

• Throughput suffers

Abrupt Delay Variations

• Abrupt RTT Increase (beyond RTO value) RTO

• Abrupt RTT Decrease Out of order delivery (OOO)Spurious Retransmissions

This Lecture

• We consider errors for which reducing congestion window is an inappropriate response

Lecture Outline

• TCP basics

• Wireless technologies

• Impact of transmission errors on TCP performance

• Approaches to improve TCP performance– Classification

– Discussion of selected approaches

Schemes to Improve Performance of TCP in Presence of Transmission Errors

Techniques to Improve TCP Performance

in Presence of ErrorsClassification 1

Classification based on nature of actions taken toimprove 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

Techniques to Improve TCP Performance

in 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

Techniques to Improve TCP Performance

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

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

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

References-2• K. Wang and S. K. Tripathi, "Mobile-end transport protocol: An alternative to TCP /IP over wireless

links," in IEEE Infocom, pp. 1046-1053, March 1998.

•  H. Balakrishnan and R. Katz, "Explicit loss notification and wireless web performance," in IEEE Globecom Internet Mini- Conference, Sydney, October 1998.

•  H. Balakrishnan, V. Padmanabhan, and R. Katz, "The effects of asymmetry on TCP performance," in Third ACM/IEEE Mobicom conference, Budapest, Hungary, September 1997.

•  H. Balakrishnan, V. Padmanabhan, S. Seshan, and R. Katz, " A comparison of mechanisms for improving Tap performance over wireless links," in ACM SIGCOMM, Stanford, CA, August 1996.

•  H. Balakrishnan, S. Seshan, and R. Katz, "Improving reliable transport and handoff perfor- mance in cellular wireless networks," ACM Wireless Networks, vol. 1, December 1995.