View
216
Download
0
Tags:
Embed Size (px)
Citation preview
CS 294-9 :: Fall 2003
TCP Congestion Control Review• 3 phases
– Slow-start• Probing for initial congestion level.
– Congestion Avoidance• Additive increase, multiplicative decrease
– Fast Retransmission/Recovery• Optimizations
CS 294-9 :: Fall 2003
Slow-Start• At beginning or after an RTO loss.
• Window set to 1 segment.
• Every new ACK grows window by 1.
• If ssthresh not yet set:– Keep going until RTO loss occurs.– Set ssthresh to 1/2 window size.– Start over.
• If ssthresh set, transition to avoidance phase.
CS 294-9 :: Fall 2003
Congestion Avoidance• Grow window by 1/window for every ACK.
• When RTO loss occurs:– Set ssthresh to half window size.– Set window to 1.– Go back to slow start.
CS 294-9 :: Fall 2003
Fast Retransmit/Recover• If three duplicate ACK’s detected:
– Retransmit segment identified by duplicate ACK’s.
– Set ssthresh to 1/2 window size.– Set window size to ssthresh.– As long as dup acks keep coming, use the
following window size equation:• window + # dup acks
– If ack changes, go back to avoidance.– If RTO occurs, back to slow start.
CS 294-9 :: Fall 2003
AIMD Graphically• TCP congestion control mostly modeled as
being in AIMD phase in steady-state.
Win
dow
Siz
e
Time
ssthresh
CS 294-9 :: Fall 2003
AIMD Fairness• AIMD motivated by fairness and stability.
• Claim is that AIMD will push multiple TCP connections into a fair and stable operating point.
• Formally unproven, but can provide intuition graphically.
CS 294-9 :: Fall 2003
AIMD Fairness Problems• What assumptions are made by the
graphical “proof”– Synchronous reaction by both participants.
• What governs when TCP reacts?– Round-trip time.– Thus, longer RTT connections might lose to
shorter RTT connections.
CS 294-9 :: Fall 2003
Loss as Congestion• TCP congestion control couples loss with
congestion.– Every loss is a congestion event.
• Where does loss come from?– Overflowing queues in bottleneck routers.– Rarely from network level congestion.
CS 294-9 :: Fall 2003
RED• Random Early Drop
• Introduced as a way of providing congestion feedback before queues completely full.
• Basic operation:– Router keeps track of weighted average queue length.
– Below some low threshold, nothing done.
– Between low and high thresholds, probability of dropping increases linearly
– Above high threshold, everything dropped.
CS 294-9 :: Fall 2003
TimeTime
MaxMaxqueue lengthqueue length
MinMinthresholdthreshold
MaxMaxthresholdthreshold
Instantaneous queue lengthInstantaneous queue length
RED GraphicallyRED Graphically
100%100%
Initial drop probabilityInitial drop probability
maxmaxpp WeightedWeightedAverageAverageQueue LengthQueue Lengthminminthth maxmaxthth
Forced dropForced drop
No dropNo drop
ProbabilisticProbabilisticearly dropearly drop
CS 294-9 :: Fall 2003
ECN• Explicit Congestion Notification
– Instead of dropping packet, mark it.– Receiver echoes the mark back to sender in the
next ACK (and all ACK’s thereafter).– Sender clears the mark after it makes
adjustment.
• Recent evidence that shows that ECN essential for any active queue management scheme.
CS 294-9 :: Fall 2003
MM Streams and TCP• Congestion control only works if everyone
plays along.
• Unrestricted datagram traffic will clobber TCP.
• Clearly, need congestion control, but in what form.
CS 294-9 :: Fall 2003
Why not TCP?• Could just use TCP without the reliability
part. Why might this be problematic?– Large, sudden changes in rate.– Caused by slow start, RTO’s, etc.
CS 294-9 :: Fall 2003
TCP Friendliness• To avoid being labeled “unreactive”, we
need to “look” like TCP.
• Two basic strategies:– Use a “TCP-compatible” congestion control
algorithm to determing sending rate.– Use encoding and streaming strategies that can
deal with rapid rate changes induced by TCP.– Combine these together.
CS 294-9 :: Fall 2003
TCP-Compatible Cong. Control• What’s the right metric for compatibility?
– A control algorithm is TCP-compatible (or friendly) if it achieves the same long-term throughput as TCP given similar network conditions.
CS 294-9 :: Fall 2003
Analyzing TCPW
indo
w S
ize
(# S
egm
ents
)
Time(# RTT’s)
ssthresh
2 * ssthresh
Want an expression for bandwidth of connection in terms of loss and delay.
n
# packets = 3/2 n2
Loss probability = L
Expected loss = 1
# packets such that E(loss) = 1 given L is 1/L
n = sqrt(2/(3L))
B = # packets * S / #RTT * RTT
B = (3/2 n*S) / RTT
B = sqrt(3/(2L))*S/RTT
CS 294-9 :: Fall 2003
RAP• Rate-based version of TCP AIMD
– Periodically probe for greater bandwidth• No more than once per RTT
– Immediately react to congestion.
• AIMD applied to inter-packet gap– No longer need to maintain a “window”
– Presumes constant packet sizes
– Appropriate constants provide TCP-friendliness
• Coupled with fine-grained adaptation– This is key.
– Will see more about this in the papers.
CS 294-9 :: Fall 2003
Binomial Congestion Control• Bansal and Balakrishnan, 2001• Non-linear congestion control law.
– Parameterized by k and l
– AIMD is simply one point in parameter space.
• Control laws:– wt+R = wt + a / wt
k
– wt+R = wt - b * wtl
• When k = 0, and l = 1, reduces to AIMD• Other parameter choices proven to be TCP-
compatible but generate smoother rate changes.
CS 294-9 :: Fall 2003
Rate-based Congestion Control• Previous analysis of TCP congestion
control is naïve. – Padhye et al. Provide a better analysis.
• Basic idea:– Keep measures of RTT and loss and modulate
rate in accordance to TCP analysis.– TCP Vegas proposes to do this with TCP itself.
( )23218
33,1min
32
llDl
tDl
t
MB
outRTT
TCP
+⎟⎟⎠
⎞⎜⎜⎝
⎛+
=
sizepacket =M
fraction loss =l
ACK oneby
edACK' packets ofnumber =D
CS 294-9 :: Fall 2003
TFRC• Motivation
– TCP-friendly congestion control without sudden rate changes.
• Equation-based– Estimates loss and RTT and plugs them directly into analytical
estimate for TCP throughput
• Estimating loss– Loss “event” as opposed to pure loss
• Want to avoid counting more than one loss per RTT
• Loss even interval = # of packets between loss events.
• Loss rate is weighted average of last 10 loss event intervals.