tcp in wireless ad hoc networks
Post on 31-Dec-2015
85 Views
Preview:
DESCRIPTION
TRANSCRIPT
TCP in Wireless Ad Hoc Networks
2008
TCP on Wireless Ad Hoc Networks
• TCP overview
• Ad hoc TCP and network layer: mobility, route failures and timeout
• The problem of fairness and the NRED
• TCP Westwood: efficient transport for high-speed wired/wireless networks
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.
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
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, transmission range = one hop
For large number of hops throughput stabilizes (pipelining effect)
Throughput Degradations withIncreasing 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 …
Averagethroughputover 50 runs
Speed (m/s)
Ideal
Actual
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
Performance with Explicit Notification
0
0.2
0.4
0.6
0.8
1
2 10 20 30
mean speed (m/s)
thro
ug
hp
ut
as a
fra
ctio
n o
fid
eal
Base TCP
With explicitnotification
Enhancing TCP Fairness in Ad Hoc Wireless Networks Using Neighborhood RED
Kaixin Xu, Mario Gerla
University of California, Los Angeles
Lantao Qi, Yantai Shu
Tianjin University, Tianjin, China
(Mobicom 2003)
TCP Unfairness in Ad Hoc Networks
• 3 TCP flows contending with each other• Flow 2 is nearly starved• Original RED fails to improve the fairness
F T P 1
F T P 2
F T P 3
(1 0 0 , 1 0 0 ) (6 0 0 , 1 0 0 )
(3 5 0 , 3 5 0 )
(3 5 0 , 7 0 0 )(0 , 7 0 0 )
(3 5 0 , 1 0 5 0 )
(1 0 0 , 1 3 0 0 ) (6 0 0 , 1 3 0 0 )
(7 0 0 , 7 0 0 )
Direct way: Announce queue size upon changes Too much overhead, queue location
problem? Our method: Indirectly estimate an index of
instant queue size by monitoring wireless channel
Neighborhood Congestion Detection
• Average queue size is calculated using RED’s alg.
• Congestion: queue size exceeds the minimal threshold
intervalsampling
timebusychannelUbusy
Channel utilization ratio
Queue size index K is a constant
busyUKq *
A
1
5
3
4
2
6
O u tg o in g Q u eu e
In co m in g Q u eu e
Channel busy
CTS
Neighborhood Random Early Detection (NRED)
• Extending RED to the distributed neighborhood queue (Virtual)
• Key Problems– Counting the size of the distributed neighborhood
queue– Calculating proper packet drop probability at each
node• Components of Neighborhood RED
– Neighborhood Congestion Detection (NCD)– Neighborhood Congestion Notification (NCN)– Distributed Neighborhood Packet Drop (DNPD)
Performance Evaluation
• Fairness is achieved• Loss of aggregated throughput
– Tradeoff between fairness and throughput
Overall Throughput
F T P 1
F T P 2
F T P 3
(1 0 0 , 1 0 0 ) (6 0 0 , 1 0 0 )
(3 5 0 , 3 5 0 )
(3 5 0 , 7 0 0 )(0 , 7 0 0 )
(3 5 0 , 1 0 5 0 )
(1 0 0 , 1 3 0 0 ) (6 0 0 , 1 3 0 0 )
(7 0 0 , 7 0 0 )
Experiment result on TJU testbed
f
Overal l throughput of 3 TCP fl ows
0
500
1000
15002000
2500
3000
3500
Drop Tai l RED NRED Pause
Thro
ughp
ut(k
bps)
0
0. 2
0. 4
0. 6
0. 8
1
Fair
ness
Ind
ex
fl ow1 fl ow2 fl ow3 total fai rness
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 inter-
arrival 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)
• 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)
Receiver
Sender
Internet
Bottleneck
packets
ACKs
measure
• First TCPW version used a “bandwidth like” estimator (BE) given by:
“ Original” Rate estimation (BE-> RE)
)/( 1 kkkk ttdb
tk-1 tk
dk
2
1 11
kkkkkk
bbBEBE
sample
exponential filter
k
kk t
t
2
2filter gain
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
• Fairness: better fairness than RENO under varying RTT
• Friendliness: TCPW is friendly to TCP Reno
D a t a G e n e r a l
D a t a G e n e r a l
Base StationW ireless
Host
In te rnet In ternet
TC P
long p ropaga tion tim e
link e rro rs
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
top related