TCP-Friendly Congestion Control for Multimedia: Ensuring Fairness and Efficiency, Slides of Computer Applications

Download TCP-Friendly Congestion Control for Multimedia: Ensuring Fairness and Efficiency and more Slides Computer Applications in PDF only on Docsity!

Congestion Control for

Multimedia

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

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

Additive Increase

D (^) A D^ D^ A^ A^ D^ D^ D^ A^ A A

Src

Dest

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

MSS

cwnd MSS

cwnd

+ = ^ 

  Nick McKeown

Leads to the TCP “sawtooth”

t

Rate

halved

Timeouts

Could take a long time to get started!

Docsity.com^ 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 previouscwnd.

Docsity.com^ 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

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

TCP SACK +TFRC

fair sharing Normalized TCP throughput = means perfect fairness

N TCP flows + N TFRC flows

NS Simulation Results

UCLA CS 218 W 2002Docsity.com

Internet Measurements : 3 TCP connections – London to Berkeley. Throughput measured over 1 sec intervals

TFRC much more stable than TCP UCLA CS 218 W 2002Docsity.com