Congestion control for multimedia

1
Congestion control for multimedia

• Henning Schulzrinne
• Dept. of Computer Science
• Columbia University
• Fall 2003

2
Motivation

• Absence of resource reservation
• Thus, only end-to-end congestion control prevents
  congestion collapse
• Dont want to favor one application over another
  ? TCP-friendly congestion control

goodput
load
3
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).

non-TCP
non-TCP
Internet
TCP
TCP
Milan Vojnovic
4
TCP-friendly congestion control

• long-term throughput does not exceed the
  throughput of a conformant TCP connection under
  the same conditions

5
Congestion control

• Keeps network operating at full capacity, but
  minimizes packet loss ? maximize goodput
• Two cases
• self-interference link capacity lt 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

6
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
7
Additive Increase
Src
D
D
A
A
D
D
A
A
D
A
D
A
Dest
Actually, TCP uses bytes, not segments to
count When ACK is received
Nick McKeown
8
Leads to the TCP sawtooth
Timeouts
Rate
halved
Could take a long time to get started!
t
Nick McKeown
9
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.
1
2
4
8
Src
D
D
D
A
A
D
D
D
D
A
A
A
A
A
Dest
Nick McKeown
10
Slow Start
Timeouts
Rate
halved
Slow start in operation until it reaches half of
previous cwnd.
Exponential slow start
t
Why is it called slow-start? Because TCP
originally had no congestion control mechanism.
The source would just start by sending a whole
windows worth of data.
Nick McKeown
11
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 (gt 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

12
Approaches for TCP-friendly congestion control

• Mimic AIMD behavior, possibly with longer
  timescales
• can also change A and D parameters (? GAIMD)
• 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

13
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

14
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

15
TFRC

• Computed from loss intervals
• Loss computed as wi 1 - (i - (n/2 - 1))/(n/2
  1) for i gt 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)

16
NS Simulation Results
TCP SACK TFRC fair sharing Normalized TCP
throughput 1 means perfect fairness
N TCP flows N TFRC flows
UCLA CS 218 W 2002
17
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
18
Issues we ignored

• Inter-stream fairness
• even for TCP, streams with different RTT get
  different throughput
• no catching up later if stream doesnt use
  resource
• TCP is not a single algorithm
• drop tail vs. RED
• Reno vs. Tahoe vs. Vegas vs.
• SACK, ECN and other extensions

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