Flow control for multimedia streaming

using TEAR (TCP emulation at receivers)work in progress.Injong RheeDepartment of Computer Science North Carolina State University

Multimedia streaming over the Internet

• Video and audio streaming over the Internet becomes popular.– As last mile network bandwidth increases (ADSL, Cable modems,

Satellite), multimedia traffic will constitute a large portion of Internet traffic.

– The VoD market will grow accordingly (e.g., AOL + TW).

Internet

Congestion and flow ControlThe adaptive, best-effort, congestion control problem

• End-to-end congestion control.

• How can we make the best use of the (time varying) bandwidth that is available to our streams?– How can we determine what this bandwidth is?– How can we track how it changes over time?

SwitchFabric

SwitchFabric

TCP

•Constitutes more than 70%-90% of the Internet traffic.

•Employs AIMD (additive increase and multiplicative decrease) for fairness– Congestion indications (packet losses)

trigger multiplicative reduction in its transmission rate.

TCPbackground - AIMD

• Maintains cwnd (congestion window) at the sender by receiving acknowledgment from the receiver;• Transmits a cwnd number of packets per round (or per RTT).

Packet loss Packet loss Packet loss

Rounds(reception ofcwnd packets)

Congest

ion W

indow

ssThresh

Slow startCongestion avoidance

Fast recovery(cwnd is halved)

TIMEOUT

TCP and TCP-friendliness

•Non-responsive flows can lock out TCP flows completely; congestion collapse will result.

•TCP-friendliness: a TCP friendly flow uses the same bandwidth as a competing TCP flow on the same end-to-end path.

Multimedia applications

•Unfortunately, few multimedia streaming commercial applications today employ TCP-friendly flow control.

TCP+multimedia applications?Is TCP a good choice for multimedia applications?

•Not a good marriage.– TCP transmission is too

bursty• ack compression

especially under high RTT.

– TCP’s rate is highly fluctuating

• A single packet loss can swing the rate to half the current rate or to almost zero under timeout.

TCP+multimedia applications?Is TCP a good choice for multimedia applications?

•Poor performance under asymmetric networks (ADSL,Satellite)– Per-packet feedback causes congestion on the

reverse path.– Feedback loss in the reverse path can cause

rate reduction in the forward path.

•Scalability limitations in multicast environments.– Per-packet feedback can cause feedback

implosion.

Existing approachesSAD(sender-driven AIMD)

• Jacobs’97, Cen’98, Rejaie’99, etc.•Performs AIMD at the sender

– Provably stable and fair

•Contains the same limitations as TCP.– Per-packet feedback: its performance limitation

under asymmetric networks or multicast environments.

CWND

Time

Existing approachesMFC (Model-based flow control) or equation-based flow control.

•Use a stochastic TCP model – Mahdavi&Floyd’97,Floyd’99, Padhey’99,etc.– Gives a simple analytical formula for TCP

throughput in a function of packet loss rate and RTT.

– Receiver can estimate TCP throughput using the formula.

Compute TCP Throughputusing the formula.

The sender setsits xmission rate

to R

Sender Receiver

Report rate R.

Existing approachesMFC – fundamental problems.

• [Ramesh&Rhee’99] analytically shows that under certain circumstances, MFC does not converge to the fair bandwidth. – Due to inherent error in estimating loss rates and in the formula.

E.g.,

– Under a high transmission rate, the loss rate can be underestimated, and under a low transmission rate, the loss rate can be overestimated.

• Assumptions made by the model are not universally true.– E.g., loss rates or RTTs are not correlated to the transmission rate

of the MFC flows.

Loss Rate =Number of packets in a window

Probability of loss event within a window

TEAR: TCP Emulation At Receivers our approach – overview I

• Shift most of flow control functions to receivers.– Instead of reporting congestion signals, process them

immediately at receivers.

• Receivers emulate the TCP window adjustment protocol.– Increase: congestion avoidance and slow start.– Decrease: fast recovery and timeout.

Emulate TCP window

adjustment

The sender setsits xmission rate

to R

Sender Receiver

Report rate R.

CWND

TEAR: TCP Emulation At Receivers our approach – overview II

• Instead of reporting an instantaneous (oscillating) rate, the receiver can find the equilibrium operating point (more smoothed averaged rate)

Emulate TCP window

adjustment

Receiver

Report rate R.

Equilibrium operating point

Perform smoothing usingWeighted averaging

TEAR in action10MB droptail, 8 TCPs, 8 TEARs

TEARBasic window emulation functions - round

CWND one TCP round CWND

one TEAR round

Round in TCP Round in TEAR

A round contains roughly an arrival of cwnd packets.

cwnd 1 2 4 8 9 10

TEARBasic window emulation functions – window increase

•Slow start: cwnd is doubled per round.

•Congestion avoidance: cwnd is increased by one per round.

Slow start Congestion avoidance

TEARFast Recovery

cwnd:5 Triple duplicate acknowledgments

TCP senderdetects fastrecovery here.

TCP

cwnd:5 TEAR receiver detects fast recovery here

TEAR

Ignore packet losses innext RTT period

TEARTimeout - I

• In TCP, after an initial packet loss in a window, at least cwnd packets are sent (including the lost packet) – this is true no matter which packet is lost in that window.

• If TCP sender does not detect FR by the time that these packets wound be acknowledged (some of them would be lost), timeout will occur.

cwnd:5

TCP

Only two TDs received

Timeout

TCPTimeout - II

• If TEAR receiver does not detect FR before the reception of a packet with x+cwnd-1 or higher after the initial loss (including the lost packet), then TEAR enters timeout.

• Or, Ttimeout (= Tinterarrival * cwnd * 2DEV) has expired after the initial packet loss.

cwnd:5 TEAR receiver detects timeout

TEAR

Ignore packet losses innext RTT period

X

X+4

Performance evaluation

•Simulation (NS)

• Internet experiments

n0 n1 n2 n320Mb/s, 10ms xx MB/s, 10ms 20Mb/s, 10ms

NCSU UCSD NCSU Korea

40Mb/s – 186Mb/sRTT 60 – 100 ms

10Mbs (somewhere in Korea)RTT 205 ms

SimulationFairness and TCP-friendliness - I

• 10Mbs, 8 TEARs (or TFRCs), 8 TCPs, Droptail

TEAR TFRC

SimulationFairness and TCP-friendliness - II

• 2.5Mbs, 8 TEARs (or TFRCs), 8 TCPs, Droptail

TEAR TFRC

Simulation Fairness and TCP-friendliness - III

• Equivalence factor of two flows A, B : Min (A/B, B/A).

Min (TEAR/TCP, TCP/TEAR). Min (TFRC/TCP, TCP/TFRC).

Internet experiments (Korea, UCSD)Fairness and TCP-friendliness - III

UCSD

Korea

• Measured every hour in the 3rd week of March.

SimulationRate fluctuations - I

Internet experimentsRate fluctuations (coefficients of variance) - II

• Coefficients of variable: ratio of one stand. Dev to average.

TEAR TCP

SimulationFeedback latency sensitivity - TEAR

SimulationFeedback latency sensitivity - TFRC

Summary and Future work

•TEAR shifts most of functions to receivers.

•By emulating TCP functions at receivers, receivers find TCP-friendly rates.

•We report work-in-progress; needs more work. – what is the time scale of response?– What is the tradeoffs between different filtering

functions at receivers for rate smoothing?– Run experiments with real multimedia data.– ….

Future workmulticast - Layered multicast

•Receiver-driven layered multicast– Receivers can estimate their receiving rates using TEAR and join and leave multicast groups based on the

estimate rates.

A B D

E

C

10Mbs 5Mbs

1Mbs

5Mbs

Future workmulticast - Sender-based single rate multicast

•SSRM - sender picks the minimum rate reported by receivers.– Feedback implosion– Filtering for drop-to-zero problem.– ….

Sender

Feedback/filteringmechanism

Future workMiddleware support

Group membership, Delivery semantics(Convenient, but application malleable)

Flow and Congestion Control

(no dependencyon particular recovery

mechanisms)

Loss Recoveryreliable,

best effort, or application specific

Application Interface

TEARRate independence – basic assumption

• Rate independence: the probability of having at least a loss in a window of size x in TEAR is the same as that in TCP competing on the same end-to-end path.

Samplinginstances

TCPTEAR