Post on 14-Dec-2015
TCP Westwood: Efficient Transport for High-speed
wired/wireless Networks
2009
TCP Westwood (Mobicom 2001)
Key Idea:• Enhance congestion control via the Rate
Estimate (RE) Samples are determined from ACK inter-arrival times and info in ACKs regarding amounts of bytes deliveredEstimate is computed at the sender by sampling and exponential filtering
• 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
7
Extensions to TCP
• End-to-end congestion control
Selective acknowledgements: TCP SACK
Delay-based congestion avoidance: TCP Vegas
TCP-Friendly Rate Control: TFRC
Binomial Congestion Control
• Router - assisted Congestion Control
Active Queue Mgmt. (AQM) and RED
Explicit congestion notification: ECN
eXplicit Control Protocol: XCP
• Discriminating between congestion losses and other losses: cross-layer signaling and guesses losses
Related TCP + Bdw estimation work• Bandwidth estimate used by Vegas and Keshav PP
• TCP Vegas monitors Bdw and RTT to infer the bottleneck queue; then, from queue it derives feedback to congestion window
Expected = window size / round trip time
Actual = acks / round trip time
Queues (bottleneck) ~ expected - actual
• Keshav’s Packet Pair scheme also monitors bandwidth to estimate the bottleneck queue and compare to common queue target; it adjusts source rate
• Main difference: TCP Westwood does not need common queue target; it enforces fair share instead.
TCP Westwood Benefits
What do we gain by using RE “feedback” in addition to packet loss?
(a) ability to distinguish random loss from buffer loss, i.e. better performance with random loss (ie, loss caused by random errors as opposed to overflow)
-- exponential filtering
(b) using RE to estimate bottleneck bdw during slow start
-- estimate the achieved rate
TCPW and random loss
• 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 and SACK in presence of random loss
TCPW in presence of random loss: Analysis and Simulation
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
NASA Workshop Demo(From Steve Schultz, NASA)
Internet Throughput Measurement
TCPW Friendliness
• Friendliness: fairness across different TCP flavors“Friendly share” principle: TCPW is allowed to recover the bandwidth wasted by NewReno because of “blind” window reduction
• TCPW original RE (BE) filter has Friendliness Problem….
5 connections total (TCPW + RENO) ; Average throughput per connection is shown in the next slide
Lossy link (1% pkt loss) TCPWReno
TCPW & Reno friendliness
Average TCPW & Reno throughputs vs. TCPW/Reno mix (5 connections total)
No link errors TCPWReno
0
0.2
0.4
0.6
0.8
1
1.2
1.4
Ave
rag
e T
hro
ug
hp
ut(
Mb
ps)
0 1 2 3 4 5No. of Reno connections
Ave
rag
e T
hro
ug
hp
ut(
Mb
ps
)
0
0.2
0.4
0.6
0.8
1
1.2
1.4
0 1 2 3 4 5No. of Reno connections
• Recall that the first TCPW version used a “bandwidth like” estimator (BE) given by:
TCPW original estimation (BE)
)/( 1 kkkk ttdb
tk-1 tk
dk
2
1 11
kkkkkk
bbBEBE
sample
exponential filter
k
kk t
t
2
2filter gain
TCPW Rate Estimation (TCP RE)
• Rate estimate (RE) is obtained by aggregating the data ACKed during the interval T (typically = RTT):
2
1 11
kkkkkk
bbRERE
sample
exponential filter
k
kk t
t
2
2filter gain
dk
T
dk-1
T
d
k
jTktjtb
tk T is the sample interval
BE overestimates fair rate ( = 2.5 Mbps)
TCPW BE Not friendly to NewReno!
TCPW RE or BE interaction with RENO
No errors (bottleneck gets saturated)
0
0.5
1
1.5
2
2.5
3
3.5
4
0 2 4 6 8 10 12 14
Bandw
idth
Est
imatio
n (
Mbps)
Time (sec)
BE RE
fair share
Errors (0.5%), no congestion
RE underestimates fair rate (=3.6 Mbps)
TCPW RE does not improve thruput!
0
0.5
1
1.5
2
2.5
3
3.5
4
0 2 4 6 8 10 12 14
Bandw
idth
Est
imatio
n(M
bps)
Time (sec)
BE RE
fair share*
(*) TCPW fair share > 50% because NewReno is incapable of getting 50%
One TCPW RE or BE and one Reno share a 5Mbps bottleneck
TCPW with adaptive filter (AF)• Neither RE or BE estimator are optimal for all
situationsBE is more effective in random loss RE is more appropriate in congestion loss (ie, buffer overflow)
• KEY IDEA: dynamically select the aggressive estimate (BE) or the conservative estimate (RE) depending on current channel status (congestion or random loss?)
• NEEDED: a “congestion measure” that gives us an idea of the most probable cause of packet loss (congestion or random)
• The Adaptive Filter actually provides a smooth transition from aggressive to conservative measure
TCPW AF: Sampling
• Adapting the size of sampling intervals to congestion level measure
Tk
Congestion: Tk growsTk
No Congestion: Tk = inter ACK
k
kTktjtj
T
d
ks
continuous adaptation
Rate sample
TCPW AF: Sampling (cont)
• The sample size Tk is continuously adjusted according to current congestion:
minmin
/)ˆ(*RTT
cwinhT
RTT
cwinRTTT kk
Max throughput assuming there is no
congestion in the networkactual achieved throughput
Sampleinterval Tk
Upon ACK Receipt
Severe Congestion: Tk --> RTT
Link Under Utilized: Tk --> 0 (ie, inter ACK intrv)
ABE Computes Congestion Level
TCP Westwood with Agile Probing: Handling Dynamic Large Leaky Pipes
-- Problem address Infocom 2004
• Leaky Pipes: packet loss due to error
Unjustified cwnd cut and premature Slow Start exit
• Large Pipes: Large capacity and long delay
Control scheme may not scale• Dynamic Pipes: Dynamic load/changing link
bandwidth (Due to change of technologies, e.g., 802.11, Bluetooth, GPRS)
Linear increase limits efficiency
Persistent Non-Congestion Detection (PNCD)
Persistent Non-congestion detected, Agile Probing invoked
Dominant flows leaveAt around 50 sec
Agile Probing
• Objective: Guided by ERE (Eligible Rate Estimate), converge faster to more appropriate ssthresh
adaptively and repeatedly resets ssthresh to ERE*RTTmin
Exponentially increase cwnd if ssthresh >cwnd
Linearly increase cwnd if ERE < ssthresh
Exit Agile Probing when packet loss is detected
Agile Probing
Lab Measurements Results (FreeBSD Implementation)
Persistent Non-Congestion Detection(PNCD) invokes Agile Probing after dominant flow left
Startup invokes Agile Probing
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