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:– 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 TCP

Internetnon-TCP

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

Receiver Transmitter (“cwnd”)

Nick McKeown

Additive Increase

D A D D A A D D A AD A

Src

Dest

Actually, TCP uses bytes, not segments to count:When ACK is received:

MSScwnd MSS

cwnd

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 ifa 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 D D A A D D

A A

D

A

Src

Dest

D

A

1 2 4 8

Nick McKeown

Slow Start

halved

Timeouts

Exponential “slow start” t

Rate

Why is it called slow-start? Because TCP originally hadno 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 tRTO ~ 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 wi = 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 sharingNormalized 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 2000.

J. Padhye, V.Firoiu, D. Towsley, J. Kurose, “Modeling TCP Throughput: a Simple Model and its Empirical Validation”, Sigcomm 1998.

M. Handley, S. Floyd, J. Padhye, J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 3448, January 2003.