Download Slow Start - ECSE - Rensselaer Polytechnic Institute

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)
• 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
B
m
Source
t
ACKs

Animation
Destination
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 s : s 2 = average of (sample – mean)2
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
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
T1
T2 = 2 * T1
Timeout interval doubled
Packet
transmitted
Time-out occurs
before ack received,
packet retransmitted
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 slowstart 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
Congestion Window size
(segments)
14
Congestion
avoidance
12
10
8
Slow start
threshold
6 Slow start
4
2
0
0
1
2
3
4
5
6
7
8
Time (round trips)
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
After timeout
20
cwnd = 20
15
10
5
ssthresh = 10
ssthresh = 8
Time (round trips)
25
22
20
15
12
9
6
3
0
0
Congestion window (segments)
25
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
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
(at
Window size (segments)
After fast recovery
10
Receiver’s advertized window
8
6
4
2
0
0
2
4
6
8
10
12
14
Time (round trips)
After fast retransmit and fast recovery window size is
reduced in half.
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 - Mobility
Mobile 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)
constellation
SAT
SAT
SAT
ground stations
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 errors
on 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 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
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
Techniques to Improve TCP Performance
in Presence of Errors
Classification 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.