TCP Wireless Tutorial

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
1
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.
2
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)
3
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://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://tcpsat.grc.nasa.gov/tcpsat/
Refer [Allman98] for overview of satellite related work
4
Internet Engineering Task Force (IETF)
Activities
 IETF manet (Mobile Ad-hoc Networks) working group

 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
5
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
6
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
7
Notable Omissions
 Wireless ATM
 WAP (Wireless Application Protocol)

http://www.wapforum.com
8
Wireless Technologies
9
Wireless Technologies
 Wireless local area networks

 Cellular wireless
 Satellites
 Multi-hop wireless
 Wireless local loop
10
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
11
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
12
Multi-Hop Wireless
 May need to traverse multiple links to reach a

destination
13
Multi-Hop Wireless - Mobility
Mobile Ad Hoc Networks (MANET)
 Mobility causes route changes
14
Multi-Hop Wireless
Metricom’s Ricochet Network
 Around 28.8 Kbps (128 Kbps to come)
Wireless hosts
modem
Poletop
internet
radio
15
Satellites
 Geostationary Earth Orbit (GEO) Satellites

example: Inmarsat
SAT
ground stations
16
Satellites
 Low-Earth Orbit (LEO) Satellites
example: Iridium (66 satellites) (2.4 Kbps data)
SAT constellation
SAT
SAT
ground stations
17
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
18
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)
19
Transmission Control Protocol / Internet Protocol
TCP/IP
20
Internet Protocol (IP)
 Packets may be delivered out-of-order
 Packets may be lost
 Packets may be duplicated
21
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
22
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
23
Cumulative Acknowledgements
 A new cumulative acknowledgement is generated

only on receipt of a new in-sequence packet
40 39 38 37
33 34 35 36
41 40 39 38
34 35 36 37
i data i ack 24
Delayed Acknowledgements
 An ack is delayed until
another packet is received, or
delayed ack timer expires (200 ms typical)
 Reduces ack traffic New ack not produced
on receipt of packet 36,
but on receipt of 37
40 39 38 37
33 35
41 40 39 38
35 37
25
Duplicate Acknowledgements
 A dupack is generated whenever an

out-of-order segment arrives at the receiver
40 39 38 37
34 36
42 41 40 39
36 36
Dupack
On receipt of 38 26
(Above example assumes delayed acks)
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)
40 39 37 38
34 36
41 40 39 37
36 36
Dupack
On receipt of 38 27
Number of dupacks depends on how much
OOO a packet is
40 39 37 38
34 36
New Ack New Ack
41 40 39 37
34 36 36
New Ack New Ack Dupack
42 41 40 39
36 36 38
New Ack Dupack New Ack 28

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
Sender’s window
1 2 3 4 5 6 7 8 9 10 11 12 13
Acks received Not transmitted

29
Sender’s window
1 2 3 4 5 6 7 8 9 10 11 12 13
Ack 5
1 2 3 4 5 6 7 8 9 10 11 12 13
Sender’s window 30
Ack Clock
 TCP window flow control is “self-clocking”
 New data sent when old data is ack’d
 Helps maintain “equilibrium”
31
 Congestion window size bounds the amount of data

that can be sent per round-trip time
 Throughput <= W / RTT
32
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
33
How does TCP detect a packet loss?
 Retransmission timeout (RTO)
 Duplicate acknowledgements
34
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
35
Retransmission Timeout (RTO) calculation
 RTO = mean + 4 mean deviation

 Standard deviation σ : σ 2 = average of (sample – mean)2
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
36
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
37
Exponential Backoff
 Double RTO on each timeout
T1 T2 = 2 * T1
Timeout interval doubled
Packet
transmitted
Time-out occurs
before ack received,
packet retransmitted
38
Fast Retransmission
 Timeouts can take too long

 how to initiate retransmission sooner?
 Fast retransmit
39
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
3 dupacks are also generated if a packet

12 8 11 10 9 7 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
40
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 41
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
42
14 Congestion
12 avoidance
Congestion Window size
10
(segments)
8
6 Slow start
4 threshold
Slow start
2
0
0 1 2 3 4 5 6 7 8
Tim e (ro un d trips)
Example assumes that acks are not delayed 43

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
44
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
45
After timeout
Congestion window (segments)
25
20 cwnd = 20
15
10
5
ssthresh = 8 ssthresh = 10
0
12
20
22
0
15
25
Time (round trips)
46
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
47
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
48
After fast recovery
10
Receiver’s advertized window
8
Window size (segments)
6
4
2
0
0 2 4 6 8 10 12 14
Tim e (ro und trips)
After fast retransmit and fast recovery window size

is 49
reduced in half.
TCP Reno
 Slow-start
 Congestion avoidance
 Fast retransmit
 Fast recovery
50
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
51
Impact of transmission errors
on TCP performance
52
Tutorial Outline
 TCP basics
 Classification
53
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
54
Random Errors May Cause Fast Retransmit
40 39 38 37
34 36
Example assumes delayed ack - every other packet ack’d
55
41 40 39 38
34 36
56
42 41 40 39
36 36
dupack
Duplicate acks are not delayed
57
43 42 41 40
36 36 36
Duplicate acks
58
44 43 42 41
36 36 36
3 duplicate acks trigger

fast retransmit at sender
59
 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
60
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]
61
This Tutorial
 We consider errors for which reducing congestion

window is an inappropriate response
62
Impact of Random Errors [Vaidya99]
1600000
1200000
800000 bits/sec
400000
0
16384 32768 65536 131072
1/error rate (in bytes)
Exponential error model

2 Mbps wireless full duplex link
No congestion losses 63
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
64
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
65
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)
66
Impact of Transmission Errors
 TCP cannot distinguish between packet losses due to

congestion and transmission errors
 Unnecessarily reduces congestion window
 Throughput suffers
67
Tutorial Outline
 TCP basics
Classification
68
Classification of Schemes to
Improve Performance of TCP in
Presence of Transmission Errors
69
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
70
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
71
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
72
Tutorial Outline
 TCP basics
Classification
73
Selected Schemes to
Improve Performance of TCP in
Presence of Transmission Errors
74
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
75
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]
76
Link Level Mechanisms
77
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
78
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
79
In general
 Use FEC to correct a small number of errors
 Use link level retransmission when FEC capability is

exceeded
80
Link layer state
TCP connection
application application application

transport transport transport
network network network
rxmt
link link link
physical physical physical
wireless
81
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
82
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
83
Issues
 Retransmissions can cause head-of-the-line blocking
Receiver 1
Base station Receiver 2
 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
84
Issues
 Retransmissions can cause congestion losses
Receiver 1
Base station Receiver 2

 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 ?
85
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
86
RTO Variations
Wireless
Packet loss
RTT sample
RTO
87
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]
88
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
89
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
data ack
1 2
Timeout = RTO
Reset, Timeout = RTO
Effectively, Timeout = RTT of packet 1 + RTO 90

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

Lost packet
3,4,5 triggers dupacks Retransmitted packet
6 2 5 4 3 2 1 92
In-order delivery
 To avoid unnecessary fast retransmit, link layer using

retransmission should attempt to deliver packets
“almost in-order”
6 5 4 3 2 2 1
6 5 2 4 3 2 1
93
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)
94
Adaptive Link Layer Strategies
[Lettieri98,Eckhardt98,Zorzi97]
Adaptive protocols attempt to dynamically choose:
 FEC code
 retransmission limit
 frame size
95
Link Layer Retransmissions [Vaidya99]
2000000
1600000
base TCP
1200000
800000 Link layer
retransmission
400000
0
16384
32768
65536
1/error rate 1E+05

(in bytes)
20 ms 1 ms
10 Mbps 2 Mbps
2 Mbps wireless duplex link with 1 ms delay

Exponential error model
No congestion losses 96
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
97
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
98
Various Schemes
 Link level mechanisms

99
Split Connection Approach
100
 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
101
 Connection between wireless host MH and fixed host

FH goes through base station BS
 FH-MH = FH-BS + BS-MH
FH BS MH
Fixed Host Base Station Mobile Host 102

 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
FH BS MH
Fixed Host Base Station Mobile Host 103

Per-TCP connection state
TCP connection TCP connection

rxmt
link link link
wireless 104
Indirect TCP [Bakre95,Bakre97]
 FH - BS connection : Standard TCP

 BS - MH connection : Standard TCP
105
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
106
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
107
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]
108
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
109
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
110
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
39
40
38 37
FH BS MH
40 36
111
 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
39
40
38 37
FH BS MH
40 36
112
 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
39
40 38 37
FH BS MH
40 36
39
40 MH Hand-off
113
New base station
 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
114
 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
data
FH MH
115
ack
Various Schemes
 Link layer mechanisms

116
TCP-Aware Link Layer
117
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
118
Snoop Protocol
Per TCP-connection state
TCP connection

rxmt
link link link
FH BS MH
wireless
119
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
FH BS MH
120
Snoop : Example
35 TCP state
maintained at
36
link layer
37
38
40 39 38 37
FH BS MH
34 36
121
Snoop : Example
35 39
36
37
38
41 40 39 38
34 36
122
Snoop : Example
37 40
38
39
42 41 40 39
36 36
dupack
123
Snoop : Example
37 40
38 41
39
43 42 41 40
36 36 36
Duplicate acks
124
Snoop : Example
37 40
38 41
39 42
44 43 37 41
FH BS MH
36 36
Discard
dupack
Dupack triggers retransmission 36

of packet 37 from base station
BS needs to be TCP-aware to
be able to interpret TCP headers 125
Snoop : Example
37 40 43
38 41
39 42
45 44 42 37
36 36
36
36
126
Snoop : Example
37 40 43
38 41 44
39 42
46 45 43 42
36 41
TCP sender does not

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

fast retransmit 36 36
36 36
128
Snoop : Example
42 45
43 46
44
48 47 45 44
FH BS MH
41 43
36 36
36 36
129
Snoop [Balakrishnan95acm]
2000000
1600000
bits/sec
1200000 base TCP

800000 Snoop
400000
0
16K
32K
64K
128K
256K
no error
2 Mbps Wireless link

130
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
131
Snoop Protocol : Classification
 Hides wireless losses from the sender
 Requires modification to only BS (network-centric

approach)
132
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
133
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)
134
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
FH BS MH
135
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
FH BS MH
136
WTCP Example
3 3
FH BS MH
4 3
Numbers in this figure are timestamps
Base station residence time is 1 unit
137
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
138
Various Schemes
 Link layer mechanisms

139
TCP-Unaware Approximation of
TCP-Aware Link Layer
140
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)
141
Delayed Dupacks Protocol
Link layer state

TCP connection

rxmt
link link link
wireless
142
 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
143
 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
144
 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
145
Delayed Dupacks : Example
35
Link layer state
36
37
38
40 39 38 37
34 36
Link layer acks are not shown 146

36
37
38
39
41 40 39 38
BS
34 36
35 Removed from BS link layer buffer on receipt of a

link layer ack (LL acks not shown in figure)
147
37 40
38
39
42 41 40 39
36 36
dupack
148
37 40
38 41
39
43 42 41 40
36 36 36
Original ack Duplicate acks
149
37
39 41
40 42
44 43 37 41
36 36
36
dupack dupacks
Delayed
dupack
Base station forwards dupacks
150
37 42
40 43
41
45 44 42 37
36 36
36
dupacks 36
Delayed dupacks
151
37 43
41 44
42
46 45 43 42
36 41
Delayed dupacks are

discarded if lost
TCP sender does not packet received before
fast retransmit delay D expires
152
Delayed Dupacks [Vaidya99]
2000000
1600000
base TCP
1200000
800000 dupack delay
80ms + LL
400000
Retransmit
0 Only LL
retransmit
16384
32768
65536
1E+05
20 ms 20 ms
10 Mbps 2 Mbps
2 Mbps wireless duplex link with 20 ms delay

No congestion losses
153
Delayed Dupacks [Vaidya99]
160000
140000
120000 base TCP
100000
80000
60000 dupack delay
40000 80ms + LL
20000 Retransmit
0 Only LL
retransmit
16384
32768
65536
1E+05
20 ms 20 ms
10 Mbps 2 Mbps
5% packet loss due to congestion

154
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
155
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
156
Various Schemes
 Link-layer retransmissions
157
Explicit Notification
158
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
159
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
160
Explicit Notification
Space Communication Protocol Standards-
Transport Protocol (SCPS-TP)
Satellite
wireless
TCP destinations
Ground station
161
Space Communication Protocol Standards-
 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)
162
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 Record
hole at 2
4 3 2 1 4 3 1
MH BS FH
wireless 1 1 1 1 163
Dupack with ELN set
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
164
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
165
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
37 36
Partial ack Cumulative ack
166
Variations
 Base station may or may not locally buffer and

retransmit lost packets
 Partial ack for all packets or a subset ?
37
37 36
Partial ack Cumulative ack
167
Explicit Loss Notification [Biaz99thesis]
 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

168
Explicit Loss Notification [Biaz99thesis]
Sequence numbers 39
cached at base station
38
37
39 38 37
36 37 37
Dupack with ELN
169
Various Schemes
170
Receiver-Based Discrimination Scheme
171
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
172
Receiver-Based Scheme
 Packet loss due to congestion

12 11 10
FH BS MH
12 10
FH BS MH
11
Congestion loss 173
 Packet loss due to transmission error

12 11 10
FH BS MH
2T
12 11 10
Error loss
FH BS MH
174
 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
175
Diagnostic Accuracy [Biaz99Asset]
Congestion losses Error losses

176
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
177
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
178
Various Schemes
179
Sender-Based Discrimination Scheme
180
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

 Sender can only use statistics based on round-trip times,

window sizes, and loss pattern
 unless network provides more information (example: explicit loss
notification)
181
Heuristics for Congestion Avoidance
throughput
cliff
knee
RTT
load load
182
 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

183
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)
184
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)
185
Some proposals
 TCP Vegas [Brakmo94]
expected throughput ET = W(i) / RTTmin
actual throughput AT = W(i) / RTT(i)
Condition C = ( ET-AT > beta)
186
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

187
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]
188
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]
189
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
190
Sender-Based Heuristics : Advantages
 Only sender needs to be modified
Needs further investigation to develop better heuristics

investigate longer-term heuristics
191
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) 192

Statistical Techniques
Future Work
 Other statistical measures ?
 Mechanisms that achieve good TCP throughput

despite not-too-good diagnostic accuracy
193
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
194
Tutorial Outline
 Schemes to improves TCP performance in presence

of transmission errors
 TCP over Satellite
 References
195
TCP Over Satellite
196
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
197
Problems Addressed by Various Schemes
 Long delay
 Large delay-bandwidth products
 Transmission errors
198
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
199
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
200
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
201
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
202
Space Communications Protocol Standard-
 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
203
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
204
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]
205
Tutorial Outline

 References
206
Impact of Mobility on TCP Performance
207
Impact of Mobility
 Hand-offs occur when a mobile host starts

communicating with a new base station (in cellular
wireless systems)
208
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
209
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
210
Mobile IP [Johnson96]
MH Router
S
3
Home
agent
Router Router
1 2
211
Mobile IP [Johnson96]
move
Router
S MH
3
Foreign agent
Home agent
Router Router Packets are tunneled

using IP in IP
1 2
212
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
4
Old New
BS 5,6 BS
1
2
3
MH
7
213
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
4
Old New
BS 5,6 BS
1
2
3
MH
7 214
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
215
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
216
Impact of Handoffs on Schemes to Improves
Performance in Presence of Errors
 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
217
Techniques to
Improve TCP Performance
in Presence of Mobility
218
Classification
 Hide mobility from the TCP sender
 Make TCP adaptive to mobility
219
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
220
0-second Rendezvous Delay : Beacon arrives
as soon as cell boundary crossed
Cell crossing Retransmission
Handoff complete
+ beacon timeout
Routes updated
arrives
Last
timed 1.0
transmit
0 0.15 0.8 sec
Packet loss Idle sender

221
1-second Rendezvous Delay : Beacon arrives 1
second after cell boundary crossed
Beacon arrives
timeout 2
Timeout 1 Handoff
complete
Last
timed 1.0 2.0
transmit
0 0.8 1.0 1.15 2.8 sec
Packet loss Idle sender

222
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
223
TCP Performance
1800 1600 1510

1600 1400
1400 1100
1200
1000 Kbit/sec
800
600
400
200
0
es
c.
lls
y
la
se
ov
ce
de
1
m
p/
0
in
p/
o
la
pp
N
la
er
er
la
ov
ov
er
n-
ov
n-
no
no
224
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
225
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
226
0-second Rendezvous Delay
Improvement using Fast Retransmit
Handoff complete
+ beacon timeout
Routes updated
arrives does not occur
Fast retransmit
Last
timed 1.0
transmit
0 0.15 0.8
Packet loss
Idle sender
227
TCP Performance Improvement
1800 1600
1600 1510 1490
1400 1380
1400
1200 1100
1000 Kbit/sec
800 With fast rxmit
600
400
200
0
1 2 3 4
228
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
229
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
230
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
231
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
232
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
Ack 999 Ack 1000
FH BS MH
233
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
FH BS MH
234
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)
235
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.
236
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)
Mobile
TCP receiver
FH BS MH
237
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
Mobile
TCP receiver
FH BS MH
238
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
239
 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
240
 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
241
Tutorial Outline

 References
242
TCP in Mobile Ad Hoc Networks
243
Mobile Ad Hoc Networks (MANET)
 May need to traverse multiple links to reach a

destination
244
Mobile Ad Hoc Networks
[IETF-MANET]
 Mobility causes route changes
245
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
246
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
247
Impact of Multi-Hop Wireless Paths
[Holland99]
1600
1400
1200
1000 TCP
800 Throughtput
600 (Kbps)
400
200
0
1 2 3 4 5 6 7 8 9 10
Number of hops
TCP Throughput using 2 Mbps 802.11 MAC

248
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)
249
Impact of Mobility
TCP Throughput
2 m/s 10 m/s
Actual throughput
Ideal throughput (Kbps)

250
Impact of Mobility
20 m/s 30 m/s
Actual throughput
Ideal throughput
251
Throughput generally degrades with increasing
speed …
Ideal
Average
Throughput
Over
50 runs Actual
Speed (m/s)
252
But not always …
30 m/s
20 m/s
Actual
throughput
Mobility pattern # 253

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

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

especially harmful
TCP data and acks
en route discarded 255
Why Does Throughput Improve?
Low Speed Scenario
D D D
C C C
B B B A
A
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.
256
Higher (double) Speed Scenario
D D D
C C C
B B B A
A
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.

257
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
258
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
259
Performance Improvement
Without network With feedback

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

feedback
Actual throughput
Ideal throughput
261
30 m/s speed
Performance with Explicit Notification
[Holland99]
throughput as a fraction of
1
0.8
Base TCP
0.6
ideal
0.4 With explicit

notification
0.2
0
2 10 20 30
mean speed (m/s)
262
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
263
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
264
Actual throughput (as fraction of expected throughput)
Average speed (m/s)

To Cache or Not to Cache
265
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
timeout due timeout, cached timeout, second cached

to route failure route is broken route also broken
 Another route discovery, and TCP time-out interval

 Process repeats until a good route is found
266
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
267
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
268
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
269
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
270
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
271
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
272
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
273
Other Topics
274
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
275
Twice Algorithm : Example
delta 2 delta
276
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
M1
Wireless
M1 M2 M2 M3 M1 card
M2
M3
277
 Separate queue for each destination

 Channel state monitor somehow determines if a
channel is in burst error state
M1
M1 M1
Wireless
M2 M2 scheduler card
M2
Per
M3
destination
queues
Channel status M3
monitor
278
 Packets transmitted on bad channels, only if packets

for no other channels present in queues
M1
M1 M1
Wireless
M2
Per
M3
destination
queues
Channel status M3
monitor
279
 Needs a reasonably good Channel State Monitor
M1
M1 M1
Wireless
M2
Per
M3
destination
queues
Channel status M3
monitor
280
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
281
Tutorial Outline

 References
282
Issues for Further Investigation
283
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
284
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
285
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
286
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
287
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
288
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
289
References
 Please see attached listing for the references cited in

the tutorial
290
Thank you !!
For more information, send e-mail to

Nitin Vaidya at
nhv@uiuc.edu
© 2001 Nitin Vaidya

291

TCP Wireless Tutorial

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TCP Wireless Tutorial

Загружено:

Авторское право:

Доступные форматы

TCP for Wireless and Mobile Hosts

© 2001 Nitin Vaidya

 Names in brackets, as in [Vaidya99], refer to a

 Many charts included in these slides are based on

 This handout may not be as readable as the original

 PowerPoint source for tutorial slides and reference

(follow the link to Seminars)

 IETF pilc (Performance Implications of Link

 IETF tcpsat (TCP Over Satellite) working group

 IETF manet (Mobile Ad-hoc Networks) working group

 IETF mobileip (IP Routing for Wireless/Mobile Hosts)

 Impact of mobility on TCP performance

 WAP (Wireless Application Protocol)

 Wireless local area networks

 Local area connectivity using wireless communication

 Space divided into cells

 May need to traverse multiple links to reach a

 Geostationary Earth Orbit (GEO) Satellites

 Packets may be delivered out-of-order

 Packets may be lost

 Packets may be duplicated

 Reliable ordered delivery

 Implements congestion avoidance and control

 Reliability achieved by means of retransmissions if

 An acknowledgement ack’s all contiguously received

 TCP assigns byte sequence numbers

 A new cumulative acknowledgement is generated

 A dupack is generated whenever an

New Ack New Ack Dupack

New Ack Dupack New Ack 28

 Sliding window protocol

Acks received Not transmitted

 TCP window flow control is “self-clocking”

 New data sent when old data is ack’d

 Helps maintain “equilibrium”

 Congestion window size bounds the amount of data

 Throughput <= W / RTT

 Ideal size = delay * bandwidth

 What if window size < delay*bw ?

 What if > delay*bw ?

 Retransmission timeout (RTO)

 At any time, TCP sender sets retransmission timer for

 If acknowledgement for the timed packet is not

 RTO dynamically calculated

 RTO = mean + 4 mean deviation

 Large variations in the RTT increase the deviation, leading

 RTT is measured as a discrete variable, in multiples

 1 tick = 500 ms in many implementations

 smaller tick sizes in more recent implementations

 RTO is at least 2 clock ticks

 Double RTO on each timeout

 Timeouts can take too long

 TCP sender assumes that a packet loss has occurred

3 dupacks are also generated if a packet

Fast retransmit useful only if lower layers deliver packets

(maximum segment size)

 slow start phase ends when window size reaches the

 cwnd grows exponentially with time during slow start

 On each new ack, increase cwnd by 1/cwnd packets

 cwnd increases linearly with time during congestion

Example assumes that acks are not delayed 43

 On detecting a packet loss, TCP sender assumes