Transcript TCP for Mobile and Wireless Hosts

TCP for Wireless and Mobile Hosts
Nitin H. Vaidya
Computer Science Department
Texas A&M University
[email protected]
http://www.cs.tamu.edu/faculty/vaidya/
1
Note

This is an overview talk

Lot of work discussed in this talk is by other people,
not by Vaidya

For a list of references, and a more complete set of
slides, see Vaidya’s home page (follow the link to
Seminars).
2
Wireless Technologies
3
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
4
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
5
Multi-Hop Wireless

May need to traverse multiple links to reach a
destination
6
Multi-Hop Wireless
Mobile Ad Hoc Networks (MANET)

Mobility causes route changes
7
Multi-Hop Wireless
Metricom’s Ricochet Network

Around 28.8 Kbps (128 Kbps to come, may be
already there)
Wireless hosts
modem
Poletop
radio
internet
8
Satellites

Geostationary Earth Orbit (GEO) Satellites
example: Inmarsat
SAT
ground stations
9
Satellites

Low-Earth Orbit (LEO) Satellites
example: Iridium (66 satellites) (2.4 Kbps data)
constellation
SAT
SAT
SAT
ground stations
10
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
11
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)
12
Transmission Control Protocol / Internet Protocol
TCP/IP
13
Internet Protocol (IP)

Packets may be delivered out-of-order

Packets may be lost

Packets may be duplicated
14
Transmission Control Protocol (TCP)

Window based protocol
Size of window determines sending rate (data sent per RTT)
Window size based on network state and receive buffer size

Implements congestion avoidance and control
packet loss assumed to be indication of congestion
sending rate reduced drastically on detecting a packet loss

Reliable ordered delivery: reliability by retransmissions
packet loss detected by timeouts and duplicate acks

End-to-end semantics
Acks confirm delivery of data received by TCP receiver
Ack for data sent only after data has reached receiver
15
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
16
Cumulative Acknowledgements

A new cumulative acknowledgement is generated
only on receipt of a new in-sequence packet
40
39
33
38
34
41
35
40
34
39
35
i
37
data
38
36
i
36
ack
37
17
Duplicate Acknowledgements


Duplicate ack is generated when a received packet
has a larger-than-expected sequence number
Duplicate acks may be generated when
a packet is lost, or
a packet is delivered out-of-order (OOO)
40
39
37
38
34
41
40
36
39
39
34
37
38 lost due to congestion
36
34
40
out-of-order delivery
38
37
36
38 lost due to errors
18
Fast Retransmit Mechanism

TCP sender assumes that a packet loss has occurred
if it receives 3 dupacks consecutively

3 dupacks will be generated if 3 packets are
delivered subsequent to a lost packet
12 11 10 9 8 7

3 dupacks are also generated if a packet is delivered
at least 3 places beyond its in-sequence location
12
8
11 10 9 7
Fast retransmit useful only if lower layers deliver packets
“almost ordered” ---- otherwise, unnecessary fast retransmit
19
Fast retransmit is followed by fast recovery.
After fast recovery, window size is reduced in half.
Window size (segments)
After fast recovery
10
Receiver’s advertized window
8
6
4
2
0
0
2
4
6
8
10 12 14
Time (round trips)
20
Impact of Transmission Errors

Packet loss due to errors can trigger fast retransmit
and fast recovery, resulting in
retransmission of lost packet
reduction in congestion window

Reducing congestion window in response to errors is
unnecessary
unless errors are caused by congestion

Reduction in congestion window in response to errors
can significantly reduce the throughput

TCP cannot distinguish between packet losses due to
congestion and those due to transmission errors. 21
Impact of Errors
1600000
1200000
800000
bits/sec
400000
0
16384 32768 65536 131072
1/error rate
(in bytes)
Exponential error model
2 Mbps wireless full duplex link
No congestion losses
22
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
23
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
24
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
25
Proposals to Improve Performance of
TCP over Wireless







Split connection approach
Link level mechanisms
TCP-Aware link layer
Explicit notification
TCP-Unaware approximation of TCP-aware link layer
Receiver-based discrimination
Sender-based discrimination
26
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

Split connection results in independent flow control
for the two parts

Flow/error control protocols, packet size, time-outs,
may be different for each part
FH
Fixed Host
BS
Base Station
MH
Mobile Host
27
Split Connection Approach
Per-TCP connection state
TCP connection
TCP connection
application
application
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
rxmt
wireless
application
28
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
29
Split Connection Approach : Disadvantages

End-to-end semantics violated
ack may be delivered to sender, before data delivered to the
receiver
May not be a problem for applications that do not rely on
TCP for the end-to-end semantics
39
40
38
FH
37
BS
40
MH
36
30
Split Connection Approach : Disadvantages

BS retains hard state
BS failure can result in loss of data (unreliability)
If BS fails, packet 40 will be lost
Because it is ack’d to sender, the sender does not buffer 40
39
40
38
FH
37
BS
40
MH
36
31
Split Connection Approach : Disadvantages

BS retains hard state
Hand-off latency increases due to state transfer
Data that has been ack’d to sender, must be moved to new
base station
FH
40
39
40
BS
38
37
36
39
40
New base station
MH
MH
Hand-off
32
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
33
Split Connection Approach : Disadvantages

Extra copying of data at BS
copying from FH-BS socket buffer to BS-MH socket buffer
increases end-to-end latency

May not be useful if data and acks traverse different
paths (both do not go through the base station)
Example: data on a satellite wireless hop, acks on a dial-up
channel
data
FH
MH
ack
34
Snoop Protocol

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
35
Snoop Protocol
Per TCP-connection state
TCP connection
application
application
application
transport
transport
transport
network
network
link
link
link
physical
physical
physical
FH
BS
rxmt
wireless
network
MH
36
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
37
Snoop : Example
35
36
TCP state
maintained at
link layer
37
38
40
39
38
FH
37
BS
34
MH
36
Example assumes delayed ack - every other packet ack’d
38
Snoop : Example
35
39
36
37
38
41
40
34
39
38
36
39
Snoop : Example
37
40
38
39
42
41
40
36
39
36
dupack
Duplicate acks are not delayed
40
Snoop : Example
37
40
38
41
39
43
42
36
41
40
36
36
Duplicate acks
41
Snoop : Example
44
37
40
38
41
39
42
43
FH
37
41
BS
Discard
dupack
MH
36
36
Dupack triggers retransmission 36
of packet 37 from base station
BS needs to be TCP-aware to
be able to interpret TCP headers
42
Snoop : Example
45
37
40
38
41
39
42
44
43
42
37
36
36
36
36
43
Snoop : Example
46
37
40
43
38
41
44
39
42
45
43
42
36
TCP sender does not
fast retransmit
41
36 36
36
44
Snoop : Example
47
37
40
43
38
41
44
39
42
45
46
44
43
41
TCP sender does not
fast retransmit
36 36
36 36
45
Snoop : Example
42
45
43
46
44
48
47
45
FH
44
BS
41
MH
43
36 36
36 36
46
Snoop
bits/sec
2000000
1600000
1200000
base TCP
Snoop
800000
400000
0
no error
256K
128K
64K
32K
16K
1/error rate
(in bytes)
2 Mbps Wireless link
47
Snoop Protocol : Advantages

High throughput can be achieved
performance further improved using selective acks

Local recovery from wireless losses

Fast retransmit not triggered at sender despite out-oforder link layer delivery

End-to-end semantics retained

Soft state at base station
loss of the soft state affects performance, but not
correctness
48
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)
49
Link Layer Mechanisms

Forward error correction (FEC)
quick recovery

Link level retransmission: Retransmit a packet at the
link layer, if errors are detected
Retransmission overhead incurred only if errors occur
50
Link Level Retransmissions
Link layer state
TCP connection
application
application
application
transport
transport
transport
network
network
link
link
link
physical
physical
physical
rxmt
wireless
network
51
Link Level Retransmissions
Issues

How many times to retransmit at the link level before
giving up?
Fully reliable or not

What triggers link level retransmissions?
Timeout, link layer Nack, TCP dupack (as in Snoop), ...

How much time is required for a link layer
retransmission?
Small or large fraction of end-to-end round trip time

Should the link layer deliver packets as they arrive, or
deliver them in-order?
52
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
53
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
54
TCP-Unawareness

Schemes that require some TCP-specific action from
an intermediate node are said to be TCP-aware

TCP-unawareness is a desirable characteristic
encryption may not allow use of TCP-aware scheme
Pure link level mechanisms are TCP-unaware
Snoop and Split Connection approaches are TCP-aware
55
TCP-Unaware Approaches

TCP-unaware approximation of Snoop
use link level retransmissions similar to Snoop
delay duplicate acknowledgements at the base station to
allow the retransmissions to succeed

Statistical techniques which may be used by the TCP
sender or receiver to determine the cause of a packet
loss
based on statistics collected on round-trip time, window size,
etc.
56
TCP in Presence of Transmission Errors
Summary

Many techniques have been proposed
not all discussed in this presentation

No single technique adequate for all wireless
environments
57
Impact of Mobility
58
Mobile Ad Hoc Networks (MANET)

May need to traverse multiple links to reach a
destination
59
Mobile Ad Hoc Networks

Mobility causes route changes
60
Throughput Typically Degrades With
Increasing Speed
Ideal
Average
Throughput
Over
50 runs
Actual
Speed (m/s)
61
Why Does Throughput Degrade?
mobility causes
link breakage,
resulting in route
failure
Route is
repaired
TCP sender times out.
Starts sending packets again
No throughput
No throughput
despite route repair
TCP data and acks
en route discarded
62
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
63
Performance Improvement
With feedback
Actual throughput
Without network
feedback
Ideal throughput
2 m/s speed
64
Performance Improvement
With feedback
Actual throughput
Without network
feedback
Ideal throughput
30 m/s speed
65
Summary

TCP reacts incorrectly when packets are lost due to
non-congestion causes
errors
mobility

Need mechanisms to improve TCP performance in
presence of such packet losses

Work also needed to study interaction between
different layers (transport, network, link)
66
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
67
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
68
Thanks !
Questions?
[email protected]
69