Congestion control for multimedia Henning Schulzrinne Dept. of Computer Science Columbia University Fall 2003
Motivation Absence of resource reservation Thus, only end-to-end congestion control prevents congestion collapse Don’t want to favor one application over another TCP-friendly congestion control load goodput
Motivation From “TCP-friendly” web site:“TCP-friendly” web site – Applications which perform congestion control make more efficient use of the network and should generally see better performance because of it. – Applications which adapt to the network are capable of running over a much wider range bandwidths and are hence more useful in the Internet. – Congestion control algorithms prevent the network from entering Congestive Collapse. Congestive Collapse is a situation where, although the network links are being heavily utilized, very little useful work is being done. (Think of metropolitan traffic gridlock...) – The network will soon begin to require applications to perform congestion control, and those applications which do not perform congestion control will be harshly penalized by the network (probably in the form of preferentially dropping their packets during times of congestion). TCP Internet non-TCP Milan Vojnović
TCP-friendly congestion control “long-term throughput does not exceed the throughput of a conformant TCP connection under the same conditions”
Congestion control Keeps network operating at full capacity, but minimizes packet loss maximize “goodput” Two cases: – self-interference: link capacity < stream drop own packets typical for residential access links – mutual interference: multiple streams competing for bottleneck bandwidth loss as congestion indicator rude streams push aside polite ones unfairness Two common approaches: – rate-based: control rate of traffic e.g., token bucket (upcoming QoS lectures) – window-based: limit number of unacknowledged packets window size controls rate, so related Careful: ≠ flow control = prevents end-system buffer overflow – however, window-based control can be used for both
TCP Congestion Control TCP sources change the sending rate by modifying the window size: Window = min {Advertised window, Congestion Window} In other words, send at the rate of the slowest component: network or receiver. “cwnd” follows additive increase/multiplicative decrease (AIMD) – On receipt of Ack: cwnd += 1 – On packet loss (timeout): cwnd *= 0.5 ReceiverTransmitter (“cwnd”) Nick McKeown
Additive Increase D A DDAADDAADA Src Dest Actually, TCP uses bytes, not segments to count: When ACK is received: Nick McKeown
Leads to the TCP “sawtooth” t Rate halved Timeouts Could take a long time to get started! Nick McKeown
“Slow Start” Designed to cold-start connection quickly at startup or if a connection has been halted (e.g. window dropped to zero, or window full, but ACK is lost). How it works: increase cwnd by 1 for each ACK received. D A DDAADD AA D A Src Dest D A Nick McKeown
Slow Start halved Timeouts Exponential “slow start” t Rate Why is it called slow-start? Because TCP originally had no congestion control mechanism. The source would just start by sending a whole window’s worth of data. Slow start in operation until it reaches half of previous cwnd. Nick McKeown
But… Window control not really appropriate for multimedia applications: – time-scale too short (~ RTT) constantly switch codecs visible or audible transitions – may start or drop below minimum codec rate Flow control not needed since receiver will need to process data at the nominal (codec) rate TCP reliability mechanism may impose additional delay (> 500 ms) on packet loss Thus, only want to maintain same long-term rate as TCP – no encouragement to mask file transfer as video – react to congestion and bandwidth bottlenecks
Approaches for TCP-friendly congestion control 1. Mimic AIMD behavior, possibly with longer timescales can also change A and D parameters ( GAIMD) 2. Equation-based use TCP equation (Padhye, Firoiu, Towsley, Kurose, 1998): – Round-trip delay R – Packet size s – Loss event rate p (receiver feedback every RTT) – Retransmission timeout t RTO ~ 4R
Simple TCP model Bandwidth as function of packet loss: Assumes triple-duplicate-ACK triggering retransmission Does not take timeout into account Model: single saturated TCP pumping data into bottleneck – other flows only modeled through packet loss
TCP Friendly Rate Control (TFRC) Uses TCP throughput equation Defined as algorithm (RFC 3448), embedded in different protocols such as DCCP or (potentially) RTCP DCCP = UDP + congestion control modules + “connection” for DOS prevention
TFRC Computed from loss intervals Loss computed as w i = 1 - (i - (n/2 - 1))/(n/2 + 1) for i > n/2, 1 otherwise – n = 8 recommended TCP favored under changing conditions: – TFRC achieves 65% utilization after 20 round trips after bandwidth has doubled (TCP – 86%) Related: TCP Emulation at Receivers (TEAR)
TCP SACK +TFRC fair sharing Normalized TCP throughput =1 means perfect fairness N TCP flows + N TFRC flows NS Simulation Results UCLA CS 218 W 2002
Internet Measurements: 3 TCP connections – London to Berkeley. Throughput measured over 1 sec intervals TFRC much more stable than TCP UCLA CS 218 W 2002
Issues we ignored Inter-stream fairness – even for TCP, streams with different RTT get different throughput – no catching up later if stream doesn’t use resource TCP is not a single algorithm: – drop tail vs. RED – Reno vs. Tahoe vs. Vegas vs. … – SACK, ECN and other extensions
References S. Floyd, J. Padhye, J. Widmer “Equation Based Congestion Control for Unicast Applications”, Sigcomm J. Padhye, V.Firoiu, D. Towsley, J. Kurose, “Modeling TCP Throughput: a Simple Model and its Empirical Validation”, Sigcomm M. Handley, S. Floyd, J. Padhye, J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 3448, January 2003.