tcp-wireless-tutorial.ppt

1
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

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

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

4
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

5
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

6
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

7
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

8
Notable Omissions
 Wireless ATM
 WAP (Wireless Application Protocol)
http://www.wapforum.com

10
Wireless Technologies
 Wireless local area networks
 Cellular wireless
 Satellites
 Multi-hop wireless
 Wireless local loop

11
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

12
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

13
Multi-Hop Wireless
 May need to traverse multiple links to reach a
destination

14
Multi-Hop Wireless - Mobility
Mobile Ad Hoc Networks (MANET)
 Mobility causes route changes

15
Multi-Hop Wireless
Metricom’s Ricochet Network
 Around 28.8 Kbps (128 Kbps to come)
Poletop
radio
Wireless hosts
internet
modem

16
Satellites
 Geostationary Earth Orbit (GEO) Satellites
example: Inmarsat
SAT
ground stations

17
Satellites
 Low-Earth Orbit (LEO) Satellites
example: Iridium (66 satellites) (2.4 Kbps data)
SAT
ground stations
SAT
SAT
constellation

18
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

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

20
Transmission Control Protocol / Internet Protocol
TCP/IP

21
Internet Protocol (IP)
 Packets may be delivered out-of-order
 Packets may be lost
 Packets may be duplicated

22
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

23
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

24
40 39 37
38
35
33
Cumulative Acknowledgements
 A new cumulative acknowledgement is generated
only on receipt of a new in-sequence packet
41 40 38
39
35 37
36
34
36
34
i data ack
i

25
Delayed Acknowledgements
 An ack is delayed until
another packet is received, or
delayed ack timer expires (200 ms typical)
 Reduces ack traffic
40 39 37
38
35
33
41 40 38
39
35 37
New ack not produced
on receipt of packet 36,
but on receipt of 37

26
Duplicate Acknowledgements
 A dupack is generated whenever an
out-of-order segment arrives at the receiver
40 39 37
38
36
34
42 41 39
40
36 36
Dupack
(Above example assumes delayed acks)
On receipt of 38

27
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 38
37
36
34
41 40 37
39
36 36
Dupack
On receipt of 38

28
Number of dupacks depends on how much
OOO a packet is
40 39 38
37
36
34
41 40 37
39
36 36
Dupack
42 41 39
40
36 36 38
New Ack
New Ack
New Ack
New Ack
34
New Ack
Dupack
New Ack

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

30
2 3 4 5 6 7 8 9 10 11 13
1 12
Sender’s window
2 3 4 5 6 7 8 9 10 11 13
1 12
Sender’s window
Ack 5

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

32
 Congestion window size bounds the amount of data
that can be sent per round-trip time
 Throughput <= W / RTT

33
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

34
How does TCP detect a packet loss?
 Retransmission timeout (RTO)
 Duplicate acknowledgements

35
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

36
Retransmission Timeout (RTO) calculation
 RTO = mean + 4 mean deviation
Standard deviation s : s = average of (sample – mean)
Mean deviation d = average of |sample – mean|
Mean deviation easier to calculate than standard deviation
Mean deviation is more conservative: d >= s
 Large variations in the RTT increase the deviation,
leading to larger RTO
2 2

37
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

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

39
Fast Retransmission
 Timeouts can take too long
how to initiate retransmission sooner?
 Fast retransmit

40
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 7
9
10
11
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

41
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

42
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

43
0
2
4
6
8
10
12
14
0 1 2 3 4 5 6 7 8
Time (round trips)
Congestion
Window
size
(segments)
Slow start
Congestion
avoidance
Slow start
threshold
Example assumes that acks are not delayed

44
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

45
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

46
0
5
10
15
20
25
0
3
6
9
1
2
1
5
2
0
2
2
2
5
Time (round trips)
Congestion
window
(segments)
ssthresh = 8 ssthresh = 10
cwnd = 20
After timeout

47
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

48
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

49
0
2
4
6
8
10
0 2 4 6 8 10 12 14
Time (round trips)
Window
size
(segments)
After fast retransmit and fast recovery window size is
reduced in half.
Receiver’s advertized window
After fast recovery

50
TCP Reno
 Slow-start
 Congestion avoidance
 Fast retransmit
 Fast recovery

51
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

52
Impact of transmission errors
on TCP performance

53
Tutorial Outline
 TCP basics
Classification

54
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

55
Random Errors May Cause Fast Retransmit
40 39 37
38
36
34
Example assumes delayed ack - every other packet ack’d

56
41 40 38
39
36
34

57
42 41 39
40
36
Duplicate acks are not delayed
36
dupack

58
40
36
36
36
Duplicate acks
41
43 42

59
41
36
36
3 duplicate acks trigger
fast retransmit at sender
42
44 43
36

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

61
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]

62
This Tutorial
 We consider errors for which reducing congestion
window is an inappropriate response

63
Impact of Random Errors [Vaidya99]
0
400000
800000
1200000
1600000
16384 32768 65536 131072
1/error rate (in bytes)
bits/sec
Exponential error model
2 Mbps wireless full duplex link
No congestion losses

64
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

65
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

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

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

68
Tutorial Outline
 TCP basics
Classification

69
Classification of Schemes to
Improve Performance of TCP in
Presence of Transmission Errors

70
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

71
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

72
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

73
Tutorial Outline
 TCP basics
Classification

74
Selected Schemes to
Improve Performance of TCP in
Presence of Transmission Errors

75
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

76
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]

78
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

79
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

80
In general
 Use FEC to correct a small number of errors
 Use link level retransmission when FEC capability is
exceeded

81
wireless
physical
link
network
transport
application
physical
link
network
transport
application
physical
link
network
transport
application
rxmt
TCP connection
Link layer state

82
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

83
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

84
Issues
 Retransmissions can cause head-of-the-line blocking
 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
Base station
Receiver 1
Receiver 2

85
Issues
 Retransmissions can cause congestion losses
 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 ?
Base station
Receiver 1
Receiver 2

86
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

87
RTO Variations
Packet loss
RTT sample
RTO
Wireless

88
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]

89
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

90
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
1 2
data ack
Timeout = RTO
Effectively, Timeout = RTT of packet 1 + RTO
Reset, Timeout = RTO

91
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

92
 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 2
3
4 1
Lost packet
Retransmitted packet

93
In-order delivery
 To avoid unnecessary fast retransmit, link layer using
retransmission should attempt to deliver packets
“almost in-order”
6 5 4 2
2
3
6 5 2 2
3
4
1
1

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

95
Adaptive Link Layer Strategies
[Lettieri98,Eckhardt98,Zorzi97]
Adaptive protocols attempt to dynamically choose:
 FEC code
 retransmission limit
 frame size

96
Link Layer Retransmissions [Vaidya99]
0
400000
800000
1200000
1600000
2000000
16384
32768
65536
1E+05
base TCP
Link layer
retransmission
2 Mbps wireless duplex link with 1 ms delay
Exponential error model
20 ms 1 ms
10 Mbps 2 Mbps

97
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

98
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

99
Various Schemes
 Link level mechanisms

101
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

102
 Connection between wireless host MH and fixed host
FH goes through base station BS
 FH-MH = FH-BS + BS-MH
FH MH
BS
Base Station Mobile Host
Fixed Host

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

104
wireless
physical
link
network
transport
application
physical
link
network
transport
application
physical
link
network
transport
application
rxmt
Per-TCP connection state
TCP connection TCP connection

105
Indirect TCP [Bakre95,Bakre97]
 FH - BS connection : Standard TCP
 BS - MH connection : Standard TCP

106
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

107
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

108
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]

109
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

110
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

111
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
FH MH
BS
40
39
37
38
36
40

112
 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
FH MH
BS
40
39
37
38
36
40

113
 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 MH
BS
40
39
37
38
36
40
MH
New base station
Hand-off
40
39

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

115
 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
FH MH
data
ack

116
Various Schemes
 Link layer mechanisms

118
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

119
Snoop Protocol
FH MH
BS
wireless
physical
link
network
transport
application
physical
link
network
transport
application
physical
link
network
transport
application
rxmt
Per TCP-connection state
TCP connection

120
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 MH
BS

121
Snoop : Example
FH MH
BS
40 39 37
38
36
34
36
37
38
35 TCP state
maintained at
link layer

122
Snoop : Example
41 40 38
39
36
34
36
37
38
35 39

123
Snoop : Example
42 41 39
40
36
36
dupack
37
38
39
40

124
Snoop : Example
40
36
36
36
Duplicate acks
41
43 42
37
38
39
40
41

125
Snoop : Example
FH MH
BS
41
36
36
37
44 43
36
37
38
39
40
41
42
Discard
dupack
Dupack triggers retransmission
of packet 37 from base station
BS needs to be TCP-aware to
be able to interpret TCP headers

126
Snoop : Example
37
36
36
42
45 44
36
37
38
39
40
41
42
43
36

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

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

129
Snoop : Example
FH MH
BS
44
36
36
45
48 47
36
42
43
41
36
44
45
43
46

130
Snoop [Balakrishnan95acm]
0
400000
800000
1200000
1600000
2000000
16K
32K
64K
128K
256K
no
error
bits/sec
base TCP
Snoop
2 Mbps Wireless link

131
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

132
Snoop Protocol : Classification
 Hides wireless losses from the sender
 Requires modification to only BS (network-centric
approach)

133
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

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

135
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 MH
BS

136
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 MH
BS

137
WTCP Example
FH BS MH
3 3
3
4
Numbers in this figure are timestamps
Base station residence time is 1 unit

138
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

139
Various Schemes
 Link layer mechanisms

140
TCP-Unaware Approximation of
TCP-Aware Link Layer

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

142
Delayed Dupacks Protocol
wireless
physical
link
network
transport
application
physical
link
network
transport
application
physical
link
network
transport
application
rxmt
TCP connection
Link layer state

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

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

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

146
Delayed Dupacks : Example
40 39 37
38
36
34
Link layer acks are not shown
36
37
38
35
Link layer state

147
BS
41 40 38
39
36
34
36
37
38
39
35 Removed from BS link layer buffer on receipt of a
link layer ack (LL acks not shown in figure)

148
42 41 39
40
36
36
dupack
37
38
39
40

149
40
36
36
36
Duplicate acks
41
43 42
37
38
39
40
41
Original ack

150
41
36
36
37
44 43
36
37
39
40
41
42
Base station forwards dupacks
dupack dupacks
Delayed
dupack

151
37
36
36
42
45 44
36
37
40
41
42
36
dupacks
Delayed dupacks
43

152
42
43
46 45
36
37
41
42
43
41
TCP sender does not
fast retransmit
44
Delayed dupacks are
discarded if lost
packet received before
delay D expires

153
Delayed Dupacks [Vaidya99]
0
400000
800000
1200000
1600000
2000000
16384
32768
65536
1E+05
base TCP
dupack delay
80ms + LL
Retransmit
Only LL
retransmit
2 Mbps wireless duplex link with 20 ms delay
20 ms 20 ms
10 Mbps 2 Mbps

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

155
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

156
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

157
Various Schemes
 Link-layer retransmissions

159
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

160
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

161
Explicit Notification
Space Communication Protocol Standards-
Transport Protocol (SCPS-TP)
Satellite
Ground station
wireless
TCP destinations

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

163
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
MH FH
BS
4 3 2 1 1
3
4
wireless
Record
hole at 2
1
1
1 1
Dupack with ELN set

164
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

165
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

166
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
36
Partial ack
37
Cumulative ack

167
Variations
 Base station may or may not locally buffer and
retransmit lost packets
 Partial ack for all packets or a subset ?
37
36
Partial ack
37
Cumulative ack

168
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

169
Explicit Loss Notification [Biaz99thesis]
37
36
37
38
39
39
38
Sequence numbers
cached at base station
37 37
Dupack with ELN

170
Various Schemes

171
Receiver-Based Discrimination Scheme

172
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

173
Receiver-Based Scheme
 Packet loss due to congestion
FH MH
BS
10
12 11
FH MH
BS
11
10
12
T
Congestion loss

174
 Packet loss due to transmission error
FH MH
BS
10
12 11
FH MH
BS
10
11
12
Error loss
2 T

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

176
Diagnostic Accuracy [Biaz99Asset]
Congestion losses Error losses

177
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

178
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

179
Various Schemes

180
Sender-Based Discrimination Scheme

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

182
Heuristics for Congestion Avoidance
load
load
RTT
throughput
knee
cliff

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

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

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

186
Some proposals
 TCP Vegas [Brakmo94]
expected throughput ET = W(i) / RTTmin
actual throughput AT = W(i) / RTT(i)
Condition C = ( ET-AT > beta)

187
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

188
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]

189
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]

190
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

191
Sender-Based Heuristics : Advantages
 Only sender needs to be modified
Needs further investigation to develop better heuristics
investigate longer-term heuristics

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

193
Statistical Techniques
Future Work
 Other statistical measures ?
 Mechanisms that achieve good TCP throughput
despite not-too-good diagnostic accuracy

194
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

195
Tutorial Outline
 Schemes to improves TCP performance in presence
of transmission errors
 TCP over Satellite
 References

197
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

198
Problems Addressed by Various Schemes
 Long delay
 Large delay-bandwidth products
 Transmission errors

199
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

200
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

201
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

202
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

203
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

204
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

205
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]

206
Tutorial Outline
 References

207
Impact of Mobility on TCP Performance

208
Impact of Mobility
 Hand-offs occur when a mobile host starts
communicating with a new base station (in cellular
wireless systems)

209
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

210
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

211
Mobile IP [Johnson96]
Router
1
Router
3
Router
2
S MH
Home
agent

212
Mobile IP [Johnson96]
Router
1
Router
3
Router
2
S MH
Home agent
Foreign agent
move
Packets are tunneled
using IP in IP

213
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
Old
BS
New
BS
MH
2
1
3
4
5,6
7

214
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
Old
BS
New
BS
MH
2
1
3
4
5,6
7

215
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

216
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

217
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

218
Techniques to
Improve TCP Performance
in Presence of Mobility

219
Classification
 Hide mobility from the TCP sender
 Make TCP adaptive to mobility

220
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

221
0-second Rendezvous Delay : Beacon arrives
as soon as cell boundary crossed
Last
timed
transmit
Cell crossing
+ beacon
arrives
Handoff complete
Routes updated
Retransmission
timeout
0 0.15 0.8 sec
1.0
Packet loss Idle sender

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

223
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

224
TCP Performance
1600 1510 1400
1100
0
200
400
600
800
1000
1200
1400
1600
1800
N
o
m
oves
overlapping
cells
non-overlap/0
delay
non-overlap/1
sec.
Kbit/sec

225
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

226
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

227
0-second Rendezvous Delay
Improvement using Fast Retransmit
Last
timed
transmit
Cell crossing
+ beacon
arrives
Handoff complete
Routes updated
Retransmission
timeout
does not occur
0 0.15 0.8
1.0
Packet loss
Fast retransmit
Idle sender

228
TCP Performance Improvement
1600
1510 1490
1380
1400
1100
0
200
400
600
800
1000
1200
1400
1600
1800
1 2 3 4
Kbit/sec
With fast rxmit

229
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

230
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

231
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

232
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

233
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
FH MH
BS
Ack 1000
Ack 999

234
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 MH
BS

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

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

237
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)
FH MH
BS
Mobile
TCP receiver

238
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
FH MH
BS
Mobile
TCP receiver

239
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

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

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

242
Tutorial Outline
 References

243
TCP in Mobile Ad Hoc Networks

244
Mobile Ad Hoc Networks (MANET)
 May need to traverse multiple links to reach a
destination

245
Mobile Ad Hoc Networks
[IETF-MANET]
 Mobility causes route changes

246
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

247
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

248
Impact of Multi-Hop Wireless Paths
[Holland99]
0
200
400
600
800
1000
1200
1400
1600
1 2 3 4 5 6 7 8 9 10
Number of hops
TCP
Throughtput
(Kbps)
TCP Throughput using 2 Mbps 802.11 MAC

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

250
Impact of Mobility
TCP Throughput
Ideal throughput (Kbps)
2 m/s 10 m/s

251
Impact of Mobility
Ideal throughput
20 m/s 30 m/s

252
Throughput generally degrades with increasing
speed …
Speed (m/s)
Average
Throughput
Over
50 runs
Ideal
Actual

253
But not always …
Mobility pattern #
Actual
throughput
20 m/s
30 m/s

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

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

256
Why Does Throughput Improve?
Low Speed Scenario
C
B
D
A
C
B
D
A
C
B
D
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.

257
Higher (double) Speed Scenario
C
B
D
A
C
B
D
A
C
B
D
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.

258
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

259
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

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

261
Performance Improvement
Without network
feedback
With feedback
Ideal throughput
30 m/s speed
Actual
throughput

262
Performance with Explicit Notification
[Holland99]
0
0.2
0.4
0.6
0.8
1
2 10 20 30
mean speed (m/s)
throughput
as
a
fraction
of
ideal
Base TCP
With explicit
notification

263
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

264
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

265
To Cache or Not to Cache
Average speed (m/s)

266
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
 Another route discovery, and TCP time-out interval
 Process repeats until a good route is found
timeout due
to route failure
timeout, cached
route is broken
timeout, second cached
route also broken

267
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

268
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

269
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

270
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

271
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

272
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

273
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

275
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

276
Twice Algorithm : Example
delta 2 delta

277
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 M2 M3
M2 M1
Wireless
card
M1
M2
M3

278
 Separate queue for each destination
 Channel state monitor somehow determines if a
channel is in burst error state
M1
M2
M3
M2
M1
Wireless
card
M1
M2
M3
scheduler
Channel status
monitor
Per
destination
queues

279
 Packets transmitted on bad channels, only if packets
for no other channels present in queues
M1
M2
M3
M2
M1
Wireless
card
M1
M2
M3
scheduler
Channel status
monitor
Per
destination
queues

280
 Needs a reasonably good Channel State Monitor
M1
M2
M3
M2
M1
Wireless
card
M1
M2
M3
scheduler
Channel status
monitor
Per
destination
queues

281
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

282
Tutorial Outline
 References

283
Issues for Further Investigation

284
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

285
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

286
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

287
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

288
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

289
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

290
References
 Please see attached listing for the references cited in
the tutorial

tcp-wireless-tutorial.ppt

More Related Content

What's hot

Similar to tcp-wireless-tutorial.ppt

Recently uploaded

tcp-wireless-tutorial.ppt