TCP Friendly Streaming Ketan MayerPatel CS 294 9

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 Window Size • TCP congestion control mostly modeled as being in AIMD phase in steady-state. ssthresh Time CS 294 -9 : : Fall 2003

Steady State Control Laws • Increase: wt+R = wt + a • Decrease wt+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

Window Size of A AIMD Fairness Graphically 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

RED Graphically Instantaneous queue length Max queue length Forced drop Max threshold Probabilistic early drop Min threshold No drop Time Initial drop probability 100% maxp minth CS 294 -9 : : Fall 2003 maxth Weighted Average Queue Length

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 TCP Want an expression for bandwidth of connection in terms of loss and delay. B = # packets * S / #RTT * RTT # packets = 3/2 n 2 B = (3/2 n*S) / RTT Window Size (# Segments) Loss probability = L Expected loss = 1 # packets such that E(loss) = 1 given L is 1/L n = sqrt(2/(3 L)) 2 * ssthresh n Time (# RTT’s) B = sqrt(3/(2 L))*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 / wtk – wt+R = wt - b * wtl • When k = 0, and l = 1, reduces to AIMD • Other parameter choices proven to be TCPcompatible 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. 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. CS 294 -9 : : Fall 2003