TCP Friendly Streaming

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

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

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

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

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

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

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

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

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

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

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

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

13. Forced drop Maxthreshold Probabilisticearly drop Minthreshold No drop Initial drop probability 100% maxp Weighted Average Queue Length minth maxth RED Graphically Instantaneous queue length Maxqueue length Time CS 294-9 :: Fall 2003

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

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

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

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

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

19. Analyzing TCP B = # packets * S / #RTT * RTT Want an expression for bandwidth of connection in terms of loss and delay. # packets = 3/2 n2 B = (3/2 n*S) / RTT Loss probability = L Expected loss = 1 2 * ssthresh Window Size (# Segments) # packets such that E(loss) = 1 given L is 1/L ssthresh n = sqrt(2/(3L)) n B = sqrt(3/(2L))*S/RTT Time (# RTT’s) CS 294-9 :: Fall 2003

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

21. 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 / wtk • 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

22. 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. CS 294-9 :: Fall 2003

23. 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. CS 294-9 :: Fall 2003