1. CS 294-9 :: Fall 2003 TCP Friendly Streaming Ketan Mayer-Patel

2. 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

3. 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.

4. 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.

5. 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.

6. CS 294-9 :: Fall 2003 AIMD Graphically TCP congestion control mostly modeled as being in AIMD phase in steady-state. Window Size Time ssthresh

7. CS 294-9 :: Fall 2003 Steady State Control Laws Increase: w t+R = w t + a Decrease w t+R = w t *b

8. 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.

9. CS 294-9 :: Fall 2003 AIMD Fairness Graphically Window Size of A Window Size of B

10. 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.

11. 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.

12. 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.

13. CS 294-9 :: Fall 2003 Time Max queue length Min threshold Max threshold Instantaneous queue length RED Graphically 100% Initial drop probability max p WeightedAverage Queue Length min th max th Forced drop No drop Probabilistic early drop

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. CS 294-9 :: Fall 2003 Analyzing TCP Window Size (# Segments) Time (# RTT’s) ssthresh 2 * ssthresh Want an expression for bandwidth of connection in terms of loss and delay. n # packets = 3/2 n 2 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

20. 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.

21. 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: –w t+R = w t + a / w t k –w t+R = w t - b * w t l When k = 0, and l = 1, reduces to AIMD Other parameter choices proven to be TCP- compatible but generate smoother rate changes.

22. 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.

23. 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.