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.