Transcript TCP on Wireless Ad Hoc Networks

TCP in Wireless Ad Hoc
Networks
2009
Summary: TCP Congestion Control
• When CongWin is below Threshold, sender
in slow-start phase, window grows
exponentially.
• When CongWin is above Threshold, sender
is in congestion-avoidance phase, window
grows linearly. AIMD
• When a triple duplicate ACK occurs,
Threshold set to CongWin/2 and CongWin
set to Threshold. AIMD
• When timeout occurs, Threshold set to
CongWin/2 and CongWin is set to 1 MSS.
TCP Problem over Wireless Networks
• In TCP
– Packet Loss <=> Congestion
• But in Mobile Networks
– Packet Loss <=> Congestion (Net) ???
• high bit error rate (Phy) - No
• access contention (MAC) - ?
• disconnection (Net) - No
• handoff (Net) - No
• The TCP end-to-end performance is
degraded seriously in wireless networks
Problems with TCP in ad hoc networks
• Multihop - throughput reduction
• mobility - path breaks and forces TCP to
timeout
 Random interference/jamming causes
packet loss => timeout
 Source cannot discriminate between
congestion loss and random loss => drive
TCP window to zero!
 Interaction between TCP backoff and MAC
backoff may cause unfairness and “capture”
Impact of Multi-Hop Wireless Paths
1600
1400
1200
1000
800
600
TCP Throughtput
(Kbps)
400
200
0
1
2
3
4
5
6
7
8
9 10
Number of hops
TCP Throughput using 2 Mbps 802.11 MAC,
transmission range = one hop
For large number of hops throughput
stabilizes (pipelining effect)
Throughput Degradations with
Increasing Number of Hops
• Packet transmission can occur on at most one
hop among three consecutive hops
• Increasing the number of hops from 1 to 2, 3
results in increased delay, and decreased
throughput
• Increasing number of hops beyond 3 allows
simultaneous transmissions on more than one
link, however, degradation continues due to
contention between TCP Data and Acks
traveling in opposite directions
• When number of hops is large enough, the
throughput stabilizes due to effective pipelining
Impact of Mobility on TCP
• Mobility causes route changes
• Throughput generally degrades with
increasing speed …
Average
throughput
over
50 runs
Ideal
Actual
Speed (m/s)
How to Improve Throughput
• Network feedback
• Inform TCP of route failure by explicit
message
• Let TCP know when route is repaired
– Probing (eg, persistent pkt
retransmissions)
– Explicit link repair notification
• Alleviates repeated TCP timeouts and backoff
throughput as a fraction of
ideal
Performance with Explicit Notification
1
0.8
Base TCP
0.6
With explicit
notification
0.4
0.2
0
2
10
20
30
mean speed (m/s)
TCP-over-wireless
End-to-end approaches
– Purely Sender-centric: TCP-Westwood, TCP-SPC
– Involving both sender and receiver: WTCP
– Purely Receiver-centric: e.g. RCP, WebTP
Split-Connection/Base-Station Oriented
e.g. Indirect-TCP, Snoop etc.
Link-layer approaches
– Reliable link layer
Misc.
e.g. Loss Discrimination using AQM, Explicit
Notification etc.
TCP Westwood:
Efficient Transport for High-speed
wired/wireless Networks
(Mobicom 2001)
TCP Westwood (Mobicom 2001)
Key Idea:
• Enhance congestion control via the Rate
Estimate (RE)
– Estimate is computed at the sender by
sampling and exponential filtering
– Samples are determined from ACK interarrival times and info in ACKs regarding
amounts of bytes delivered
• RE is used by sender to properly set cwnd
and ssthresh after packet loss (indicated by
3 DUPACKs, or Timeout)
Rate Estimation (BE-> RE)
Bottleneck
packets
Receiver
Sender
ACKs
measure
Internet
• Ideally, would like to determine the connection fair
share of the bottleneck bandwidth
• Since fair share is difficult (to define or determine),
we instead estimate the achieved rate: Rate Estimate
(RE)
“Original” Rate estimation (BE-> RE)
dk
tk-1 tk
• First TCPW version used a “bandwidth like” estimator
(BE) given by:
bk  d k /(t k  t k 1 )
sample
 bk  bk 1  exponential
BEk   k BEk 1  1   k 

filter
2 

2  t k
k 
filter gain
2  t k
RE/BE Estimation is similar to Keshav Packet Pair estimation
TCP Westwood: the control algorithm
• TCPW Algorithm Outline:
– When three duplicate ACKs are detected:
• set ssthresh=BE*RTTmin
(instead of ssthresh=cwin/2 as in Reno)
• if (cwin > ssthresh)
set cwin=ssthresh
– When a TIMEOUT expires:
• set ssthresh=BE*RTTmin
(instead of ssthresh=cwnd/2 as in Reno)
and cwin=1
Note: RTTmin = min round trip delay
experienced by the connection
TCP Westwood Benefits
• Reno overreacts to random loss (cwin cut by half)
• TCPW less sensitive to random loss
– (1) a small fraction of “randomly” lost packets
minimally impacts the rate estimate RE
– (2) Thus, cwin = RE x RTT remains unchanged
• As a result, TCPW throughput is higher than Reno
• What do we gain by using RE “feedback” in addition
to packet loss?
(a) better performance with random loss (ie, loss
caused by random errors as opposed to overflow)
(b) ability to distinguish random loss from buffer loss
(c) using RE to estimate bottleneck bdw during slow
start
TCPW in a wireless lossy environment
• Efficiency: Improvement significant on high (Bdw x
Length) paths
link errors
Wireless
Host
Base Station
Internet
Internet
long propagation time
Data Genera l
Data General
TCP
• Fairness: better fairness than RENO under varying
RTT
• Friendliness: TCPW is friendly to TCP Reno
TCPW in presence of random loss:
Analysis and Simulation
Summary
• Introduced the concept of Rate Estimation
and related work
• Reviewed end-to-end estimation based
congestion control methods
• Presented TCP Westwood, and the
evolution of “fair rate” estimate to improve
the performance; showed simulation
results to evaluate the method
• Compared TCPW with other methods