Get documents about "TCP over Wireless (I) some slides adapted, notably from
Document Sample
TCP over Wireless (I) some slides adapted,
notably from tutorial by Nitin Vaidya
1
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)
2
TCP/IP over Wireless
De facto standard for internetworking
Allows wireless devices to connect seamlessly to the
Internet
TCP over wireless introduces some problems not
faced in wired networks (transmission errors, mobility
…)
We will overview these issues as well as existing solutions
What type of wireless network (cellular, last hop, ad
hoc, satellite …)?
3
Quick review of
Transmission Control Protocol / Internet Protocol
TCP/IP
4
Internet Protocol (IP)
Packets may be delivered out-of-order
Packets may be lost
Packets may be duplicated
5
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
6
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
7
Cumulative Acknowledgements
A new cumulative acknowledgement is generated
only on receipt of a new in-sequence packet
40 39 38 37
33 34 35 36
41 40 39 38
34 35 36 37
i data i ack 8
Delayed Acknowledgements
An ack is delayed until
another packet is received, or
delayed ack timer expires (200 ms typical)
Reduces ack traffic New ack not produced
on receipt of packet 36,
but on receipt of 37
40 39 38 37
33 35
41 40 39 38
35 37
9
Duplicate Acknowledgements
A dupack is generated whenever an
out-of-order segment arrives at the receiver
40 39 38 37
34 36
42 41 40 39
36 36
Dupack
On receipt of 38 10
(Above example assumes delayed acks)
Duplicate Acknowledgements
Duplicate acks are not delayed
Duplicate acks may be generated when
a packet is lost, or
a packet is delivered out-of-order (OOO)
40 39 37 38
34 36
41 40 39 37
36 36
Dupack
On receipt of 38 11
Number of dupacks depends on how much
OOO a packet is
40 39 37 38
34 36
New Ack New Ack
41 40 39 37
34 36 36
New Ack New Ack Dupack
42 41 40 39
36 36 38
New Ack Dupack New Ack 12
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
13
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 14
Ack Clock
TCP window flow control is ―self-clocking‖
New data sent when old data is ack’d
Helps maintain ―equilibrium‖
15
Window Based Flow Control
Congestion window size bounds the amount of data
that can be sent per round-trip time
Throughput <= W / RTT
16
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
17
How does TCP detect a packet loss?
Retransmission timeout (RTO)
Duplicate acknowledgements
18
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
19
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
20
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
21
Exponential Backoff
Double RTO on each timeout
T1 T2 = 2 * T1
Timeout interval doubled
Packet
transmitted
Time-out occurs
before ack received,
packet retransmitted
22
Fast Retransmission
Timeouts can take too long
how to initiate retransmission sooner?
Fast retransmit
23
Detecting Packet Loss Using Dupacks
Fast Retransmit Mechanism
Dupacks may be generated due to
packet loss, or
out-of-order packet delivery
TCP sender assumes that a packet loss has occurred
if it receives three dupacks consecutively
3 dupacks are also generated if a packet
12 8 11 10 9 7 is delivered at least 3 places beyond its
in-sequence location
Fast retransmit useful only if lower layers deliver packets
―almost ordered‖ ---- otherwise, unnecessary fast retransmit
24
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 25
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
26
14 Congestion
Congestion Window size
12 avoidance
10
(segments)
8 Slow start
6Slow start threshold
4
2
0
0 1 2 3 4 5 6 7 8
Time (round trips)
Example assumes that acks are not delayed 27
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
28
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
29
Congestion window (segments) After timeout
25
cwnd = 20
20
15
10
ssthresh = 8 ssthresh = 10
5
0
12
15
20
22
25
0
3
6
9
Time (round trips)
30
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
31
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
32
After fast recovery
10
Window size (segments)
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. 33
TCP Reno
Slow-start
Congestion avoidance
Fast retransmit
Fast recovery
34
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 35
Does IEEE 802.11 Work Well in Multi-hop Wireless
Network?
Author: Shugong Xu, Tarek Saadawi
City University of New York
36
Overview of The Paper
This paper is about TCP over multi-hop networks, but its also
about cross-layer interactions
Conclusion: Cross Layer interactions between 802.11 Protocol,
routing and TCP can be destructive.
Experimental Scenario:
A Static String Topology
0 1 2 3 4 5 6 7
TCP as Transport Layer Protocol
Problems:
Instability Problem
Unfairness Problem
37
Simulation Environment
Simulator: ns-2 with wireless extensions
MAC Layer: IEEE 802.11 MAC Distributed Coordination
function(DCF).
Transport Layer: TCP connections carrying bulk transfers
(always have data)
Network Scenario
A Static String Network Topology
Interference range is a little more than two times of the
communication range
Interference Range Communication Range
0 1 2 3 4 5 6 7
38
Instability Problem—Experiment Setup
1 2 3 4 5
Source Destination
A single TCP connection, with node 1 as the source and node
5 as the destination.
Three sets of experiments with Maximum Window
Size(window_) 32, 8, and 4 respectively.
39
Instability Problem—Experiment Result
When window_=32 or 8, serious oscillation of throughput is observed.
When window_4, throughput is stable.
40
Instability Problem—Trace Analysis(1)
Interference Range of Node 2
RTS Data
1 2 3 4 5
CTS Ack
41
Instability Problem—Summary
Collision and exposed terminal problem prevent node 2 from
receiving RTS from or sending CTS to node 1.
The random back-off, big data packet, and sending back-to-back
packets worsen the above problems.
When window_ = 4, the chance to send back a CTS is greatly
increased, so the throughput becomes stable.
After node 1 fails seven times to receive CTS, node 1 believes there
is a route failure and starts a route discovery.
Before a route is available, node 1 can not send out a data packet.
This period usually is long enough to cause a timeout at the TCP
sender.
For TCP, timeout triggers Slow Start, which significantly reduces the
throughput.
42
Unfairness Problem—Experiment Setup
Second Session First Session
2 3 4 5 6
Source Destination Source
In the first session, data flow from 6 to 4. In the second session,
data flow from 2 to 3.
The first session starts at 10.0s. The second session starts at 30.0s.
43
Unfairness Problem (1)
The first session has a throughput of about 450kbps from 10s to 30s, and
0kbps after 30s.
The second session has a throughput of about 900kbps from 30s to 130s.
44
Unfairness Problem (2)
The first session never succeeds to send out packet with sequence number
2164.
45
Unfairness Problem—Trace Analysis(1)
Interfering Range of Node 5
Data RTS Data
2 3 4 5 6
Ack No Route
CTS
Interfering Range of Node 4
46
Unfairness Problem—Trace Analysis(2)
Interfering Range of Node 5
Data RTS Data
2 3 4 5 6
Ack No Route
CTS
Interfering Range of Node 4
47
Unfairness Problem—Summary
In one-hop TCP connections, the interval between
packet transmission is larger than that of the multi-
hop TCP connections, which gives the one-hop
connection more chances to transmit data.
Random back-off is actually advantageous to the
last succeeding host.
Problem called ―One-hop unfairness problem‖
Authors argue that since one-hop connection is common
in a wireless network problem must be addressed
48
Discussion?
Problems Shown:
Instability Problem
Unfairness problem
Conclusions:
IEEE 802.11 does not work well in multi-hop wireless
networks.
It may be inappropriate to take IEEE 802.11 as the MAC
layer to simulate routing or transport protocols for multi-
hop wireless networks.
Are Cross Layer Solutions needed?
Maybe a different set of protocols that play nicer
together?
49
More discussion
Rooted in IEEE 802.11 MAC?
TCP is not designed with wireless networking in mind.
Timeout Slow Start
Interfering range and communication range
If interfering range is the same as the communication range, the two
problems presented in this paper will disappear.
Is the configuration of the interfering range simply an engineering issue?
Only a simple topology is considered
What happens if more complex scenarios are considered?
Different traffic?
Multiple connections?
Different spacing between nodes?
More realistic wireless channel?
Can you relate to other stuff we have discussed so far?
50
Impact of transmission errors
on TCP performance
51
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
52
Random Errors May Cause Fast Retransmit
40 39 38 37
34 36
Example assumes delayed ack - every other packet ack’d
53
Random Errors May Cause Fast Retransmit
41 40 39 38
34 36
Example assumes delayed ack - every other packet ack’d
54
Random Errors May Cause Fast Retransmit
42 41 40 39
36 36
dupack
Duplicate acks are not delayed
55
Random Errors May Cause Fast Retransmit
43 42 41 40
36 36 36
Duplicate acks
56
Random Errors May Cause Fast Retransmit
44 43 42 41
36 36 36
3 duplicate acks trigger
fast retransmit at sender
57
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
58
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]
59
Impact of Random Errors [Vaidya99]
1600000
1200000
800000 bits/sec
400000
0
4
8
6
72
38
76
53
10
16
32
65
1/error rate 13
(in bytes)
Exponential error model
2 Mbps wireless full duplex link
No congestion losses 60
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
Multiple packet losses (random) can also result in
timeout when using TCP-Reno (and to a lesser extent
when using SACK)
61
Impact of Transmission Errors
TCP cannot distinguish between packet losses due to
congestion and transmission errors
Unnecessarily reduces congestion window
Throughput suffers
62
Classification of Schemes to
Improve Performance of TCP in
Presence of Transmission Errors
63
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
64
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
65
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
66
Selected Schemes to
Improve Performance of TCP in
Presence of Transmission Errors
67
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]
68
Link Level Mechanisms
69
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
70
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
71
Link Layer Mechanisms
In general
Use FEC to correct a small number of errors
Use link level retransmission when FEC capability is
exceeded
72
Link Level Retransmissions
Link layer state
TCP connection
application application application
transport transport transport
network network network
rxmt
link link link
physical physical physical
wireless
73
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
Interaction of timers at link level and TCP? 74
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
75
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
76
Link Level Retransmissions
(Early Studies)
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
77
RTO Variations
Wireless
Packet loss
RTT sample
RTO
78
A More Accurate Picture
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]
79
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
80
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
81
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
Lost packet
3,4,5 triggers dupacks
Retransmitted packet
6 2 5 4 3 2 1 82
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
83
Adaptive Link Layer Strategies
[Lettieri98,Eckhardt98,Zorzi97]
Adaptive protocols attempt to dynamically choose:
FEC code
retransmission limit
frame size
84
Link Layer Retransmissions [Vaidya99]
2000000
1600000
base TCP
1200000
800000 Link layer
retransmission
400000
0
16384
32768
65536
1E+05
20 ms 1 ms
1/error rate (in bytes)
10 Mbps 2 Mbps
2 Mbps wireless duplex link with 1 ms delay
Exponential error model
No congestion losses 85
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
86
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
87
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
88
Split Connection Approach
89
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
90
Split Connection Approach
Connection between wireless host MH and fixed host
FH goes through base station BS
FH-MH = FH-BS + BS-MH
FH BS MH
Fixed Host Base Station Mobile Host 91
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 BS MH
Fixed Host Base Station Mobile Host 92
Split Connection Approach
Per-TCP connection state
TCP connection TCP connection
application application application
rxmt
transport transport transport
network network network
link link link
physical physical physical
wireless 93
Split Connection Approach
Indirect TCP [Bakre95,Bakre97]
FH - BS connection : Standard TCP
BS - MH connection : Standard TCP
94
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
95
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
96
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
97
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
98
Split Connection Approach : Disadvantages
End-to-end semantics violated
ack may be delivered to sender, before data delivered to the
receiver
May not be a problem for applications that do not rely on
TCP for the end-to-end semantics
39
40
38 37
FH BS MH
40 36
99
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 37
FH BS MH
40 36
100
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
39
40 38 37
FH BS MH
40 36
39
40 MH Hand-off
101
New base station
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
102
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
103
ack
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
104
TCP-Aware Link Layer
105
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
106
Snoop Protocol
Per TCP-connection state
TCP connection
application application application
transport transport transport
network network network
rxmt
link link link
physical physical physical
FH BS MH
wireless
107
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
108
Snoop : Example
35 TCP state
maintained at
36
link layer
37
38
40 39 38 37
FH BS MH
34 36
Example assumes delayed ack - every other packet ack’d
109
Snoop : Example
35 39
36
37
38
41 40 39 38
34 36
110
Snoop : Example
37 40
38
39
42 41 40 39
36 36
dupack
Duplicate acks are not delayed
111
Snoop : Example
37 40
38 41
39
43 42 41 40
36 36 36
Duplicate acks
112
Snoop : Example
37 40
38 41
39 42
44 43 37 41
FH BS MH
36 36
Discard
dupack
Dupack triggers retransmission 36
of packet 37 from base station
BS needs to be TCP-aware to
be able to interpret TCP headers 113
Snoop : Example
37 40 43
38 41
39 42
45 44 42 37
36 36
36
36
114
Snoop : Example
37 40 43
38 41 44
39 42
46 45 43 42
36 41
TCP sender does not
fast retransmit 36 36
36
115
Snoop : Example
37 40 43
38 41 44
39 42 45
47 46 44 43
41
TCP sender does not
fast retransmit 36 36
36 36
116
Snoop : Example
42 45
43 46
44
48 47 45 44
FH BS MH
41 43
36 36
36 36
117
Snoop [Balakrishnan95acm]
2000000
1600000
bits/sec
1200000 base TCP
800000 Snoop
400000
0
16K
32K
64K
128K
256K
no error
1/error rate (in bytes)
2 Mbps Wireless link
118
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
119
Snoop Protocol : Classification
Hides wireless losses from the sender
Requires modification to only BS (network-centric
approach)
120
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
121
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)
122
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
123
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
124
WTCP Example
3 3
FH BS MH
4 3
Numbers in this figure are timestamps
Base station residence time is 1 unit
125
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
126
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
127
TCP-Unaware Approximation of
TCP-Aware Link Layer
128
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)
129
Delayed Dupacks Protocol
Link layer state
TCP connection
application application application
transport transport transport
network network network
rxmt
link link link
physical physical physical
wireless
130
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-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
131
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
132
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
133
Delayed Dupacks : Example
35
Link layer state
36
37
38
40 39 38 37
34 36
Example assumes delayed ack - every other packet ack’d
Link layer acks are not shown 134
Delayed Dupacks : Example
36
37
38
39
41 40 39 38
BS
34 36
35 Removed from BS link layer buffer on receipt of a
link layer ack (LL acks not shown in figure)
135
Delayed Dupacks : Example
37 40
38
39
42 41 40 39
36 36
dupack
Duplicate acks are not delayed
136
Delayed Dupacks : Example
37 40
38 41
39
43 42 41 40
36 36 36
Original ack Duplicate acks
137
Delayed Dupacks : Example
37
39 41
40 42
44 43 37 41
36 36
36
dupack dupacks
Delayed
dupack
Base station forwards dupacks
138
Delayed Dupacks : Example
37 42
40 43
41
45 44 42 37
36 36
36
dupacks 36
Delayed dupacks
139
Delayed Dupacks : Example
37 43
41 44
42
46 45 43 42
36 41
Delayed dupacks are
discarded if lost
TCP sender does not packet received before
fast retransmit delay D expires
140
Delayed Dupacks [Vaidya99]
2000000
1600000
base TCP
1200000
800000 dupack delay
400000 80ms + LL
Retransmit
0 Only LL
16384
32768
65536
1E+05
retransmit
1/error rate (in bytes)
20 ms 20 ms
10 Mbps 2 Mbps
2 Mbps wireless duplex link with 20 ms delay
No congestion losses
141
Delayed Dupacks [Vaidya99]
160000
140000
120000 base TCP
100000
80000
60000 dupack delay
40000 80ms + LL
20000 Retransmit
0 Only LL
16384
32768
65536
1E+05
retransmit
1/error rate (in bytes) 20 ms 20 ms
10 Mbps 2 Mbps
5% packet loss due to congestion
142
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
143
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
144
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
145
Explicit Notification
146
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
147
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
148
Explicit Notification
Space Communication Protocol Standards-
Transport Protocol (SCPS-TP)
Satellite
wireless
TCP destinations
Ground station
149
Space Communication Protocol Standards-
Transport 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 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)
150
Explicit Loss Notification [Balakrishnan98]
when MH is the TCP sender
Wireless link first on the path from sender to receiver
The base station keeps track of holes in the packet
sequence received from the sender
When a dupack is received from the receiver, the
base station compares the dupack sequence number
with the recorded holes
if there is a match, an ELN bit is set in the dupack
When sender receives dupack with ELN set, it
retransmits packet, but does not reduce congestion
window Record
hole at 2
4 3 2 1 4 3 1
MH BS FH
wireless 1 1 1 1 151
Dupack with ELN set
Explicit Bad State Notification [Bakshi97]
when MH is TCP receiver
Base station attempts to deliver packets to the MH
using a link layer retransmission scheme
If packet cannot be delivered using a small number of
retransmissions, BS sends a Explicit Bad State
Notification (EBSN) message to TCP sender
When TCP sender receives EBSN, it resets its timer
timeout delayed, when wireless channel in bad state
152
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
153
Partial Ack Protocols
When a packet for which a partial ack is received is
detected to be lost, the sender does not reduce its
congestion window
loss assumed to be due to wireless errors
37
37 36
Partial ack Cumulative ack
154
Variations
Base station may or may not locally buffer and
retransmit lost packets
Partial ack for all packets or a subset ?
37
37 36
Partial ack Cumulative ack
155
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
156
Explicit Loss Notification [Biaz99thesis]
when MH is TCP receiver
Sequence numbers 39
cached at base station
38
37
39 38 37
36 37 37
Dupack with ELN
157
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
158
Receiver-Based Discrimination Scheme
159
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
160
Receiver-Based Scheme
Packet loss due to congestion
12 11 10
FH BS MH
T
12 10
FH BS MH
11
Congestion loss 161
Receiver-Based Scheme
Packet loss due to transmission error
12 11 10
FH BS MH
2T
12 11 10
Error loss
FH BS MH
162
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
163
Receiver-Based Scheme
Diagnostic Accuracy [Biaz99Asset]
Congestion losses Error losses
164
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
165
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
166
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
167
Sender-Based Discrimination Scheme
168
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)
169
Heuristics for Congestion Avoidance
throughput
cliff
knee
RTT
load load
170
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
171
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)
172
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)
173
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)
174
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
175
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]
176
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]
177
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
178
Sender-Based Heuristics : Advantages
Only sender needs to be modified
Needs further investigation to develop better heuristics
investigate longer-term heuristics
179
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) 180
Statistical Techniques
Future Work
Other statistical measures ?
Mechanisms that achieve good TCP throughput
despite not-too-good diagnostic accuracy
181
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
182
Related docs
