Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

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

The importance of tcp-friendly congestion control for multimedia applications in preventing network congestion collapse and ensuring fairness among different applications. It covers the motivation behind tcp-friendly congestion control, the two main cases of self-interference and mutual interference, and two common approaches to congestion control: rate-based and window-based. The document also introduces tcp's slow start mechanism and its impact on network performance.

Typology: Slides

2012/2013

Uploaded on 01/02/2013

kid
kid 🇮🇳

4.3

(18)

111 documents

1 / 18

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Congestion Control for
Multimedia
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12

Partial preview of the text

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