Flow control for multimedia streaming using TEAR (TCP emulation at receivers) work in progress. Injong Rhee Department 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 Control The 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? Switch Fabric Switch Fabric

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.

TCP background - 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 Rounds (reception of cwnd packets) Congestion Window ssThresh Slow start Congestion 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 approaches SAD(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 approaches MFC (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 Throughput using the formula. The sender sets its xmission rate to R SenderReceiver Report rate R.

Existing approaches MFC – 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 sets its xmission rate to R SenderReceiver 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 using Weighted averaging

TEAR in action 10MB droptail, 8 TCPs, 8 TEARs

TEAR Basic window emulation functions - round CWNDone TCP round CWND one TEAR round Round in TCP Round in TEAR A round contains roughly an arrival of cwnd packets.

cwnd TEAR Basic window emulation functions – window increase Slow start: cwnd is doubled per round. Congestion avoidance: cwnd is increased by one per round. Slow startCongestion avoidance

TEAR Fast Recovery cwnd:5 Triple duplicate acknowledgments TCP sender detects fast recovery here. TCP cwnd:5 TEAR receiver detects fast recovery here TEAR Ignore packet losses in next RTT period

TEAR Timeout - 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

TCP Timeout - 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, T timeout (= T interarrival * cwnd * 2DEV) has expired after the initial packet loss. cwnd:5 TEAR receiver detects timeout TEAR Ignore packet losses in next RTT period X X+4

Performance evaluation Simulation (NS) Internet experiments n0n1n2n3 20Mb/s, 10ms xx MB/s, 10ms 20Mb/s, 10ms NCSU UCSD NCSU Korea 40Mb/s – 186Mb/s RTT 60 – 100 ms 10Mbs (somewhere in Korea) RTT 205 ms

Simulation Fairness and TCP-friendliness - I 10Mbs, 8 TEARs (or TFRCs), 8 TCPs, Droptail TEAR TFRC

Simulation Fairness 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 3 rd week of March.

Simulation Rate fluctuations - I

Internet experiments Rate fluctuations (coefficients of variance) - II Coefficients of variable: ratio of one stand. Dev to average. TEARTCP

Simulation Feedback latency sensitivity - TEAR

Simulation Feedback 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 work multicast - 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. ABD E C 10Mbs 5Mbs 1Mbs 5Mbs

Future work multicast - Sender-based single rate multicast SSRM - sender picks the minimum rate reported by receivers. –Feedback implosion –Filtering for drop-to-zero problem. –…. Sender Feedback/filtering mechanism

Future work Middleware support Group membership, Delivery semantics (Convenient, but application malleable) Flow and Congestion Control (no dependency on particular recovery mechanisms) Loss Recovery reliable, best effort, or application specific Application Interface

TEAR Rate 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. Sampling instances TCP TEAR