PowerPoint slides - Nitin Vaidya - University of Illinois at Urbana

TCP for Wireless and Mobile Hosts
Nitin H. Vaidya
University of Illinois at Urbana-Champaign
[email protected]
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
radio
internet
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)
constellation
SAT
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
33
38
34
41
35
40
34
39
35
i
37
data
38
36
i
36
ack
37
24
Delayed Acknowledgements


An ack is delayed until
another packet is received, or
delayed ack timer expires (200 ms typical)
New ack not produced
Reduces ack traffic
on receipt of packet 36,
but on receipt of 37
40
39
38
33
41
37
35
40
39
35
38
37
25
Duplicate Acknowledgements

A dupack is generated whenever an
out-of-order segment arrives at the receiver
40
39
38
37
34
42
41
36
40
36
(Above example assumes delayed acks)
39
36
Dupack
On receipt of 38
26
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
41
40
36
39
37
36
36
Dupack
On receipt of 38
27
Number of dupacks depends on how much
OOO a packet is
40
39
37
34
41
36
New Ack
40
39
34
New Ack
41
40
36
New Ack
New Ack
37
36
New Ack
42
38
36
Dupack
39
36
Dupack
38
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
Window Based Flow Control
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
Window Based Flow Control

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 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
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
12 8 11 10 9 7
3 dupacks are also generated if a packet
is delivered at least 3 places beyond its
in-sequence location
Fast retransmit useful only if lower layers deliver packets
“almost ordered” ---- otherwise, unnecessary fast retransmit
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
Congestion Window size
(segments)
14
Congestion
avoidance
12
10
8
Slow start
threshold
6Slow start
4
2
0
0
1
2
3
4
5
6
7
8
Time (round 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
25
cwnd = 20
20
15
10
ssthresh = 10
ssthresh = 8
5
25
22
20
15
12
9
6
3
0
0
Congestion window (segments)
After timeout
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
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.
49
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




Wireless technologies
TCP basics
Impact of transmission errors on TCP performance
Approaches to improve TCP performance
Classification
Discussion of selected approaches
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
Random Errors May Cause Fast Retransmit
41
40
34
39
38
36
Example assumes delayed ack - every other packet ack’d
56
Random Errors May Cause Fast Retransmit
42
41
40
36
39
36
dupack
Duplicate acks are not delayed
57
Random Errors May Cause Fast Retransmit
43
42
36
41
40
36
36
Duplicate acks
58
Random Errors May Cause Fast Retransmit
44
43
42
36
41
36
36
3 duplicate acks trigger
fast retransmit at sender
59
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
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




Wireless technologies
TCP basics
Impact of transmission errors on TCP performance
Approaches to improve TCP performance
Classification
Discussion of selected approaches
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




Wireless technologies
TCP basics
Impact of transmission errors on TCP performance
Approaches to improve TCP performance
Classification
Discussion of selected approaches
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 Layer Mechanisms
Link Level Retransmissions

Link level retransmission schemes retransmit a
packet at the link layer, if errors are detected

Retransmission overhead incurred only if errors occur
unlike FEC overhead
79
Link Layer Mechanisms
In general

Use FEC to correct a small number of errors

Use link level retransmission when FEC capability is
exceeded
80
Link Level Retransmissions
Link layer state
TCP connection
application
application
application
transport
transport
transport
network
network
link
link
link
physical
physical
physical
rxmt
wireless
network
81
Link Level Retransmissions
Issues

How many times to retransmit at the link level before
giving up?
Finite bound -- semi-reliable link layer
No bound -- reliable link layer

What triggers link level retransmissions?
Link layer timeout mechanism
Link level acks (negative acks, dupacks, …)
Other mechanisms (e.g., Snoop, as discussed later)

How much time is required for a link layer
retransmission?
Small fraction of end-to-end TCP RTT
Large fraction/multiple of end-to-end TCP RTT
82
Link Level Retransmissions
Issues

Should the link layer deliver packets as they arrive, or
deliver them in-order?
Link layer may need to buffer packets and reorder if
necessary so as to deliver packets in-order
83
Link Level Retransmissions
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
Link Level Retransmissions
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
Link Level Retransmissions
An Early Study [DeSimone93]

The sender’s Retransmission Timeout (RTO) is a
function of measured RTT (round-trip times)
Link level retransmits increase RTT, therefore, RTO

If errors not frequent, RTO will not account for RTT
variations due to link level retransmissions
When errors occur, the sender may timeout & retransmit
before link level retransmission is successful
Sender and link layer both retransmit
Duplicate retransmissions (interference) waste wireless
bandwidth
Timeouts also result in reduced congestion window
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
Link Level Retransmissions
A More Accurate Picture

Frequent errors increase RTO significantly on slow
wireless links
RTT on slow links large, retransmissions result in large
variance, pushing RTO up
Likelihood of interference between link layer and TCP
retransmissions smaller
But congestion response will be delayed due to larger RTO
When wireless losses do cause timeout, much time wasted
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
Link Level Retransmissions

Selective repeat protocols can deliver packets out of
order

Significantly out-of-order delivery can trigger TCP fast
retransmit
Redundant retransmission from TCP sender
Reduction in congestion window

Example: Receipt of packets
3,4,5 triggers dupacks
6
2
5
Lost packet
Retransmitted packet
4
3
2
1
92
Link Level Retransmissions
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
Link Level Retransmissions
In-order delivery

Not all connections benefit from retransmissions or
ordered delivery
audio

Need to be able to specify requirements on a perpacket 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
Link layer
retransmission
800000
400000
0
1E+05
65536
32768
16384
1/error rate
(in bytes)
2 Mbps wireless duplex link with 1 ms delay
Exponential error model
No congestion losses
20 ms
1 ms
10 Mbps 2 Mbps
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
Split connection approach
TCP-Aware link layer
TCP-Unaware approximation of TCP-aware link layer
Explicit notification
Receiver-based discrimination
Sender-based discrimination
99
Split Connection Approach
100
Split Connection Approach

End-to-end TCP connection is broken into one
connection on the wired part of route and one over
wireless part of the route

A single TCP connection split into two TCP
connections
if wireless link is not last on route, then more than two TCP
connections may be needed
101
Split Connection Approach

Connection between wireless host MH and fixed host
FH goes through base station BS

FH-MH = FH-BS
FH
Fixed Host
+
BS
Base Station
BS-MH
MH
Mobile Host
102
Split Connection Approach

Split connection results in independent flow control
for the two parts

Flow/error control protocols, packet size, time-outs,
may be different for each part
FH
Fixed Host
BS
Base Station
MH
Mobile Host
103
Split Connection Approach
Per-TCP connection state
TCP connection
TCP connection
application
application
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
rxmt
wireless
application
104
Split Connection Approach
Indirect TCP [Bakre95,Bakre97]


FH - BS connection : Standard TCP
BS - MH connection : Standard TCP
105
Split Connection Approach
Selective Repeat Protocol (SRP) [Yavatkar94]



FH - BS connection : standard TCP
BS - FH connection : selective repeat protocol on top
of UDP
Performance better than Indirect-TCP (I-TCP),
because wireless portion of the connection can be
tuned to wireless behavior
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
FH
37
BS
40
MH
36
111
Split Connection Approach : Disadvantages

BS retains hard state
BS failure can result in loss of data (unreliability)
If BS fails, packet 40 will be lost
Because it is ack’d to sender, the sender does not buffer 40
39
40
38
FH
37
BS
40
MH
36
112
Split Connection Approach : Disadvantages

BS retains hard state
Hand-off latency increases due to state transfer
Data that has been ack’d to sender, must be moved to new
base station
FH
40
39
40
BS
38
37
36
39
40
New base station
MH
MH
Hand-off
113
Split Connection Approach : Disadvantages

Buffer space needed at BS for each TCP connection
BS buffers tend to get full, when wireless link slower (one
window worth of data on wired connection could be stored at
the base station, for each split connection)

Window on BS-MH connection reduced in response
to errors
may not be an issue for wireless links with small delay-bw
product
114
Split Connection Approach : Disadvantages

Extra copying of data at BS
copying from FH-BS socket buffer to BS-MH socket buffer
increases end-to-end latency

May not be useful if data and acks traverse different
paths (both do not go through the base station)
Example: data on a satellite wireless hop, acks on a dial-up
channel
data
FH
MH
ack
115
Various Schemes







Link layer mechanisms
Split connection approach
TCP-Aware link layer
TCP-Unaware approximation of TCP-aware link layer
Explicit notification
Receiver-based discrimination
Sender-based discrimination
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
application
application
application
transport
transport
transport
network
network
link
link
link
physical
physical
physical
FH
BS
rxmt
wireless
network
MH
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
36
TCP state
maintained at
link layer
37
38
40
39
38
FH
37
BS
34
MH
36
Example assumes delayed ack - every other packet ack’d
121
Snoop : Example
35
39
36
37
38
41
40
34
39
38
36
122
Snoop : Example
37
40
38
39
42
41
40
36
39
36
dupack
Duplicate acks are not delayed
123
Snoop : Example
37
40
38
41
39
43
42
36
41
40
36
36
Duplicate acks
124
Snoop : Example
44
37
40
38
41
39
42
43
FH
37
41
BS
Discard
dupack
MH
36
36
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
45
37
40
38
41
39
42
44
43
42
37
36
36
36
36
126
Snoop : Example
46
37
40
43
38
41
44
39
42
45
43
42
36
TCP sender does not
fast retransmit
41
36 36
36
127
Snoop : Example
47
37
40
43
38
41
44
39
42
45
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
FH
44
BS
41
MH
43
36 36
36 36
129
Snoop [Balakrishnan95acm]
bits/sec
2000000
1600000
1200000
base TCP
Snoop
800000
400000
0
no error
256K
128K
64K
32K
16K
1/error rate
(in bytes)
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-oforder 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
4
MH
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
Split connection approach
TCP-Aware link layer
TCP-Unaware approximation of TCP-aware link layer
Explicit notification
Receiver-based discrimination
Sender-based discrimination
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
application
application
application
transport
transport
transport
network
network
link
link
link
physical
physical
physical
rxmt
wireless
network
142
Delayed Dupacks Protocol

Link layer retransmission scheme at the base station

Link layer delivers packets out-of-order when
transmission errors occur
Why may a link layer deliver packets out-of-order?
• Only an issue when the link layer does not use stop-andgo 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
Delayed Dupacks Protocol

TCP receiver delays dupacks (third and subsequent)
for interval D, when out-of-order packets received

Dupack delay intended to give link level retransmit
time to succeed

Benefit: Delayed dupacks can result in recovery from
a transmission loss without triggering a response
from the TCP sender

Disadvantage: Recovery from congestion losses
delayed
144
Delayed Dupacks Protocol

Delayed dupacks released after interval D, if missing
packet not received by then

Link layer maintains state to allow retransmission
Link layer state is not TCP-specific

145
Delayed Dupacks : Example
35
36
Link layer state
37
38
40
39
38
37
34
36
Example assumes delayed ack - every other packet ack’d
Link layer acks are not shown
146
Delayed Dupacks : Example
36
37
38
39
41
40
39
38
BS
34
35
36
Removed from BS link layer buffer on receipt of a
link layer ack (LL acks not shown in figure)
147
Delayed Dupacks : Example
37
40
38
39
42
41
40
36
39
36
dupack
Duplicate acks are not delayed
148
Delayed Dupacks : Example
37
40
38
41
39
43
42
36
Original ack
41
40
36
36
Duplicate acks
149
Delayed Dupacks : Example
37
44
39
41
40
42
43
37
36
dupack
Base station forwards dupacks
41
36
dupacks
36
Delayed
dupack
150
Delayed Dupacks : Example
37
42
40
43
41
45
44
36
dupacks
42
36
37
36
36
Delayed dupacks
151
Delayed Dupacks : Example
37
43
41
44
42
46
45
43
42
36
TCP sender does not
fast retransmit
41
Delayed dupacks are
discarded if lost
packet received before
delay D expires
152
Delayed Dupacks [Vaidya99]
2000000
1600000
base TCP
1200000
800000
dupack delay
80ms + LL
Retransmit
400000
0
1E+05
65536
32768
16384
1/error rate
Only LL
retransmit
20 ms
(in bytes)
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
100000
80000
60000
40000
20000
0
base TCP
dupack delay
80ms + LL
Retransmit
1E+05
65536
32768
16384
1/error rate
Only LL
retransmit
(in bytes)
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
Split connection approach
TCP-Aware link layer
TCP-Unaware approximation of TCP-aware link layer
Explicit notification
Receiver-based discrimination
Sender-based discrimination
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 StandardsTransport Protocol (SCPS-TP)
Satellite
wireless
Ground station
TCP destinations
161
Space Communication Protocol StandardsTransport Protocol (SCPS-TP)




The receiving ground station keeps track of how
many packets with errors are received (their
checksums failed)
When the error rate exceeds a threshold, the ground
station sends corruption experienced messages to
destinations of recent error-free TCP packets
destinations are cached
The TCP destinations tag acks with corruptionexperienced bit
TCP sender, after receiving an ack with corruptionexperienced bit, does not back off until it receives an
ack without that bit (even if timeout or fast retransmit
162
occurs)
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
MH
4
3
wireless
hole at 2
2 1
BS
1
1
4
3
1
1 1
Dupack with ELN set
FH
163
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
Partial ack
36
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
Partial ack
36
Cumulative ack
167
Explicit Loss Notification [Biaz99thesis]
when MH is TCP receiver

Attempts to approximate hypothetical ELN proposed
in [Balakrishnan96] for the case when MH is receiver

Caches TCP sequence numbers at base station,
similar to Snoop. But does not cache data packets,
unlike Snoop.

Duplicate acks are tagged with ELN bit before being
forwarded to sender if sequence number for the lost
packet is cached at the base station

Sender takes appropriate action on receiving ELN
168
Explicit Loss Notification [Biaz99thesis]
when MH is TCP receiver
Sequence numbers
cached at base station
39
38
37
39
36
37
38
37
37
Dupack with ELN
169
Various Schemes







Link-layer retransmissions
Split connection approach
TCP-Aware link layer
TCP-Unaware approximation of TCP-aware link layer
Explicit notification
Receiver-based discrimination
Sender-based discrimination
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
FH
11
10
BS
MH
T
FH
BS
12
11
Congestion loss
10
MH
173
Receiver-Based Scheme

Packet loss due to transmission error
12
FH
11
10
BS
MH
2T
12
FH
BS
11
Error loss
10
MH
174
Receiver-Based Scheme

Receiver uses the inter-arrival time between
consecutively received packets to guess the cause of
a packet loss

On determining a packet loss as being due to errors,
the receiver may
tag corresponding dupacks with an ELN bit, or
send an explicit notification to sender
175
Receiver-Based Scheme
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







Link-layer retransmissions
Split connection approach
TCP-Aware link layer
TCP-Unaware approximation of TCP-aware link layer
Explicit notification
Receiver-based discrimination
Sender-based discrimination
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
reduce congestion window

Sender can only use statistics based on round-trip
times, window sizes, and loss pattern
unless network provides more information (example: explicit
loss notification)
181
Heuristics for Congestion Avoidance
throughput
cliff
knee
RTT
load
load
182
Heuristics for Congestion Avoidance

Define condition C as a function of congestion
window size and observed RTTs

Condition C evaluated when a new RTT is calculated
condition C typically evaluates to 2 or 3 possible values
for now assume 2 values: TRUE or FALSE

If (C == True) reduce congestion window

Several proposals for condition C
183
Heuristics for Congestion Avoidance
Some proposals

Normalized Delay Gradient [jain89]
r = [RTT(i)-RTT(i-1)] / [RTT(i)+RTT(i-1)]
w = [W(i)-W(i-1)] / [W(i)+W(i-1)]
Condition C = (r/w > 0)
184
Heuristics for Congestion Avoidance
Some proposals

Normalized Throughput Gradient [Wang91]
Throughput gradient
TG(i) = [T(i) - T(i-1) ] / [ W(i)-W(i-1)]
Normalized Throughout Gradient
NTG = TG(i) / TG(1)
Condition C = (NTG < 0.5)
185
Heuristics for Congestion Avoidance
Some proposals

TCP Vegas [Brakmo94]
expected throughput ET = W(i) / RTTmin
actual throughput
AT = W(i) / RTT(i)
Condition C = ( ET-AT > beta)
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
reduce congestion window
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
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
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 StandardTransport 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 TCPVegas, to bound window growth, to reduce
congestion-induced losses
202
Space Communications Protocol StandardTransport Protocol (SCPS-TP)

During link outage, TCP sender freezes itself, and
resumes when link is restored
outage assumed to occur in both directions simultaneously
ground station can detect outage of incoming link (for
instance, by low signal levels), and infers outage of outgoing
link
ground stations provide link outage information to any
sender that attempts to send packets on the outgoing link
sender does not unnecessarily timeout or retransmit until it
is informed that link has recovered

Selective acknowledgement protocol to recover
losses quickly
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






TCP over Satellite
Impact of mobility on TCP performance
Approaches to improve TCP performance in
presence of mobility
Issues in multi-hop wireless networks
Issues needing further work
References
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]
S
MH
Router
3
Home
agent
Router
1
Router
2
211
Mobile IP [Johnson96]
move
Router
3
S
MH
Foreign agent
Home agent
Router
1
Router
2
Packets are tunneled
using IP in IP
212
Example Hand-Off Procedure
1.
2.
Each base station periodically transmits beacon
Mobile host, on hearing stronger beacon from a new
BS, sends it a greeting
 changes routing tables to make new BS its default gateway
 sends new BS identity of the old BS
Old
BS
4
5,6
New
BS
1
2
3
MH
7
213
Hand-Off Procedure
3.
4.
5.
6.
7.
New BS acknowledges the greeting, and begins to
route the MH’s packets
New BS informs old BS
Old BS changes routing table, to forward any
packets for the MH to the new BS
Old BS sends an ack to new BS
New BS sends handoff-completion message to MH
Old
BS
4
5,6
New
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

Split connection approach
hard state at base station must be moved to new base
station

Snoop protocol
soft state need not be moved
while the new base station builds new state, packet losses
may not be recovered locally

Frequent handoffs a problem for schemes that rely
on significant amount of hard/soft state at base
stations
hard state should not be lost
soft state needs to be recreated to benefit performance
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
+ beacon
arrives
Handoff complete
Routes updated
Last
timed
transmit
Retransmission
timeout
1.0
0
0.15
Packet loss
0.8 sec
Idle sender
221
1-second Rendezvous Delay : Beacon arrives 1
second after cell boundary crossed
Cell crossing
Beacon arrives
Timeout 1
Last
timed
transmit
Handoff
complete
2.0
1.0
0
Retransmission
timeout 2
0.8 1.0
Packet loss
1.15
2.8 sec
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
1400
1200
1000
800
600
400
200
0
o
N
1600
1510
1400
1100
Kbit/sec
s
e
ov
m
la
r
e
ov
ng
i
pp
ls
l
ce
no
n
e
ov
/0
p
rla
ay
l
de
n
o
n
ve
o
-
/1
p
rla
.
c
se
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
Cell crossing
+ beacon
arrives
Handoff complete
Routes updated
Retransmission
timeout
does not occur
Fast retransmit
Last
timed
transmit
1.0
0
0.15
Packet loss
0.8
Idle sender
227
TCP Performance Improvement
1800 1600
1600
1400
1200
1000
800
600
400
200
0
1
1510
1490
1400 1380
1100
Kbit/sec
With fast rxmit
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
FH
Ack 1000
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
Using Multicast to Improve Handoffs

Static group definition [Ghai94]
groups can be defined taking physical topology into account
static definition may not take individual user mobility pattern
into account

Dynamic group definition [Seshan96]
implemented using IP multicast groups
each user’s group can be different
overhead of updating the multicast groups is a concern with
a large scale deployment
240
Using Multicast to Improve Handoffs

Buffering at multiple base stations incurs memory
overhead

Trade-off between buffering overhead and packet
loss

Buffer requirement can be reduced by starting
buffering only when a mobile host is likely to leave
current cell soon
241
Tutorial Outline






TCP over Satellite
Impact of mobility on TCP performance
Approaches to improve TCP performance in
presence of mobility
Issues in multi-hop wireless networks
Issues needing further work
References
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
800
600
400
200
0
TCP
Throughtput
(Kbps)
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 = S f(i) * T(i)
249
Impact of Mobility
TCP Throughput
2 m/s
10 m/s
Ideal throughput (Kbps)
250
Impact of Mobility
20 m/s
30 m/s
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
failure
Route is
repaired
TCP sender times out.
Starts sending packets again
No throughput
No throughput
despite route repair
TCP data and acks
en route discarded
254
Why Does Throughput Degrade?
mobility causes
link breakage,
resulting in route
failure
TCP sender
times out.
Backs off timer.
Route is
repaired
TCP sender
times out.
Resumes
sending
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
C
B
D
C
D
B
A
C
D
B
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
Why Does Throughput Improve?
Higher (double) Speed Scenario
C
B
D
C
D
B
A
C
D
B
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
Why Does Throughput Improve?
General Principle



TCP timeout interval somewhat (not entirely)
independent of speed
Network state at higher speed, when timeout occurs,
may be more favorable than at lower speed
Network state
Link/route status
Route caches
Congestion
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
With feedback
Actual throughput
Without network
feedback
Ideal throughput
2 m/s speed
260
Performance Improvement
With feedback
Actual throughput
Without network
feedback
Ideal throughput
30 m/s speed
261
throughput as a fraction of
ideal
Performance with Explicit Notification
[Holland99]
1
0.8
Base TCP
0.6
With explicit
notification
0.4
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
To Cache or Not to Cache
Average speed (m/s)
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
to route failure


timeout, cached timeout, second cached
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)

Proposal: new RTO = function of old RTO, old route length, and
new route length
May be too large
Will result in slow response to future losses
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 (firstin-first-out) scheduling, if sender attempts to
retransmit packets on a channel in a bad state
M1
M1 M2 M2 M3 M1
Wireless
card
M2
M3
277
Channel State Dependent Packet Scheduling


Separate queue for each destination
Channel state monitor somehow determines if a
channel is in burst error state
M1
M1 M1
M2 M2
scheduler
Wireless
card
M2
Per
M3
destination
queues
Channel status
monitor
M3
278
Channel State Dependent Packet Scheduling

Packets transmitted on bad channels, only if packets
for no other channels present in queues
M1
M1 M1
M2 M2
scheduler
Wireless
card
M2
Per
M3
destination
queues
Channel status
monitor
M3
279
Channel State Dependent Packet Scheduling

Needs a reasonably good Channel State Monitor
M1
M1 M1
M2 M2
scheduler
Wireless
card
M2
Per
M3
destination
queues
Channel status
monitor
M3
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






TCP over Satellite
Impact of mobility on TCP performance
Approaches to improve TCP performance in
presence of mobility
Issues in multi-hop wireless networks
Issues needing further work
References
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
[email protected]
© 2001 Nitin Vaidya
291