CS 294-9 :: Fall 2003

TCP Friendly Streaming

Ketan Mayer-Patel

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

Steady State Control Laws• Increase:

wt+R = wt + a

• Decreasewt+R = wt *b

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 GraphicallyW

indo

w S

ize

of A

Window Size of B

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.