and TCP-Friendly Congestion Control for Scalable ... - Semantic Scholar

196

IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 8, NO. 2, APRIL 2006

Media- and TCP-Friendly Congestion Control for Scalable Video Streams Jinyao Yan, Kostas Katrinis, Martin May, Member, IEEE, and Bernhard Plattner, Member, IEEE

Abstract—This paper presents a media- and TCP-friendly ratebased congestion control algorithm (MTFRCC) for scalable video streaming in the Internet. The algorithm integrates two new techniques: i) a utility-based model using the rate-distortion function as the application utility measure for optimizing the overall video quality; and ii) a two-timescale approach of rate averages (longterm and short-term) to satisfy both media and TCP-friendliness. We evaluate our algorithm through simulation and compare the results against the TCP-friendly rate control (TFRC) algorithm. For assessment, we consider five criteria: TCP fairness, responsiveness, aggressiveness, overall video quality, and smoothness of the resulting bit rate. Our simulation results manifest that MTFRCC performs better than TFRC for various congestion levels, including an improvement of the overall video quality. Index Terms—Algorithms, Internet, multimedia communication, optimal control.

I. INTRODUCTION

R

ESEARCH in the field of multimedia communication applications such as video-on-demand (VOD), real-time video, and Internet live broadcast has been ongoing for many years now. However, due to the heterogeneous nature of IP networks, the effective delivery of media streams produced by such applications is still facing many challenges. In particular, this is due to a) the variability of path capacity between media source and receiver; b) the heterogeneity of device capabilities; and c) the single best-effort forwarding service offered by the Internet infrastructure. Congestion control algorithms—typically in the form of rate-based congestion control (rate control) for streaming applications—are primarily necessary for multimedia communication applications to deal with the diverse and constantly changing conditions of the Internet [21]. Essentially, the goal of such algorithms is to prevent applications from either overloading or under-utilizing available network resources. The dominant congestion protocol in the Internet, namely TCP, reacts to packet loss by regulating the number of outstanding

Manuscript received March, 1 2005; revised October 18, 2005. This work was supported in part by the Natural Science Foundation of China under Grant 60502015. The associate editor coordinating the review of this manuscript and approving it for publication was Dr. Benjamin W. Wah. J. Yan was with the Computer Engineering and Networks Laboratory, Swiss Federal Institute of Technology (ETH), Zurich 8092, Switzerland. He is with the Network Center, Communication University of China, Beijing 100024, China (e-mail: [email protected]). K. Katrinis, M. May, and B. Plattner are with the Communication Systems Group, Computer Engineering and Networks Laboratory, Swiss Federal Institute of Technology (ETH), Zurich 8092, Switzerland (e-mail: katrinis@ tik.ee.ethz.ch; [email protected]; [email protected]). Digital Object Identifier 10.1109/TMM.2005.864265

unacknowledged data segments allowed in the network. In steady state, TCP adopts an additive-increase multiplicative-decrease (AIMD) strategy to detect additional available bandwidth and to react to congestion. Although TCP’s congestion control algorithm is suitable and efficient for bulk data transfers, however, it is not well suited for real-time applications. For instance, applying multiplicative decrease to the rate available to a real-time video stream can severely impact the video quality perceived by the end user [26]. Therefore, several congestion control algorithms, tailored to the rate acceleration and variability requirements of real-time applications, have been developed. Early enough, a main concern in the design of these algorithms has been the coexistence of traffic they induce with TCP traffic. Indeed, without congestion control, non-TCP traffic can cause starvation or even congestion collapse to TCP traffic, if both types of traffic compete for resources at a congested FIFO queue [1]. As a remedy, new TCP-compatible features have been integrated into congestion control algorithms for audio/video-streaming applications ([2], [3], [23]) in order to compete with TCP flows in a fair manner. These features have two important characteristics in common: i) slow responsiveness in order to smooth data throughput; and (ii) “TCP-friendliness”. As defined in [1], a flow is TCP-friendly if, and only if, in steady state, it uses in the long term no more bandwidth than a conforming TCP flow would use under comparable conditions. Among the principal representatives of the TCP-friendly congestion control algorithms is the TCP-friendly rate control (TFRC) algorithm [2]. TFRC is an equation-based congestion control mechanism that uses the TCP throughput function derived in [4] to calculate the actual available rate for a media stream. Previous work ([5], [6]) on TCP-friendly congestion control showed that TFRC exhibits better performance than other TCP-friendly alternatives in terms of a) smoothness of the sending rate; b) responsiveness; and c) aggressiveness with regard to network resource utilization. Still, TFRC and its alternatives are plagued with a fundamental shortcoming: they only focus on optimizing the consumption of network resources and omit maximizing the perceived quality of the media streams (audio/video). More precisely, in its initial phase, TFRC uses the slow start method to guarantee that the currently available network resources are not overloaded. It gradually increases its sending rate starting at 1 packet/second until the available path capacity is fully occupied. Thus, while being network-friendly, TFRC harms the quality of service for media streams [35]. In the congestion avoidance phase, even if media flows are not the cause of congestion, they could still suffer from short-termed congestion incidents [19]. Even though TFRC tries to smooth

1520-9210/$20.00 © 2006 IEEE

YAN et al.: MEDIA- AND TCP-FRIENDLY CONGESTION CONTROL

out rate variability, it does not take the properties of the overlying media application into consideration, when protecting media flows from short-term congestion. As it will be shown later in this paper, this deficiency harms the quality of rendered streams. Therefore, the clear challenge is to devise a congestion control algorithm that is TCP-friendly and media-friendly at the same time. Given a content distribution system with multiple video streaming sources, receivers and links, we seek to allocate a rate value to each source such that each media flow is both media- and TCP-friendly. We term a congestion control algorithm media-friendly (and similarly its induced flows), if it optimizes—according to some predefined criteria—the overall video quality of media streams, when rendered at the receivers. Herein, we focus on scalable video sources; namely sources that encode a raw video stream into a single base layer and an arbitrary number of enhancement layers. Typically, the quality significance of each layer decreases as we shift from the base layer to the last enhancement layer [8], [22]. We adopt a utility-based network model, where sources use a particular scalable video format to encode raw video streams. We introduce first the video quality function of the scalable encoding scheme and use this function as the utility function of the utility-based model. Subsequently, we deduce the optimal throughput response function, driving the maximization of overall video quality. Based on this throughput function, we design a new rate-based congestion control algorithm termed MTFRCC (Media- and TCP-friendly rate-based congestion control algorithm). We further improve the MTFRCC algorithm with a two-timescale approach to force TCP-friendliness in the long term. For this, we calculate according to the aggregated long-term congestion information the rate that should be enforced to meet TCP-friendliness in the long term and adapt the sending rate in the short-term according to the response function of MTFRCC. Throughout this work, we use the MPEG-4 fine-granularity scalable (FGS) coding scheme [8] as the scalable video coding technology of reference. FGS video streams can be dynamically adapted to the varying condition of the network by truncating the streams to any desired bit rate, as determined by underlying rate control algorithms like TFRC or MTFRCC. FGS coding allows for using a continuous rate-distortion function at the receiver or relay, instead of the step-like function adopted by layered encoding schemes. Especially the latter characteristic of FGS drives its superiority in state of the art video coding and is actually the main reason for using this particular scheme in the present work. Extending the specification of the MTRFCC algorithm to other scalable video codecs can be realized easily, following the methodology described later on. The main contribution of this paper is the development of the MTFRCC algorithm, which by integrating the utility-based model and the two-timescale approach, achieves better performance for scalable video streams compared to existing algorithms such as TFRC. We also show that TCP-friendliness does not lead necessarily to media-friendliness, i.e., we show and discuss the impact of TCP-friendliness to media quality. Finally, we show how to integrate the two (media- and TCP-) friendliness features under a single congestion control scheme. In

197

summary, we enable video streaming with better quality while abiding by established network-friendly streaming rules. This paper is organized as follows. In Section II, we review related work. Section III presents the utility-model of the network and the associated application utility, and specifies the MTFRCC algorithm. The results of our simulations are presented in Section IV. Section V discusses the scalability of the algorithm, while Section VI elaborates in using MTFRCC with heterogeneous video coding schemes. We conclude in Section VII with conclusions and future work. II. RELATED WORK The term “rate control” is frequently used in the scope of media streaming with two disparate meanings: i) bit-rate allocation performed within an encoding scheme (like adjustment of encoder parameters in real-time, transcoding or error control techniques); and ii) rate-based congestion control (like TFRC and MTFRCC) as opposed to window-based congestion control (like TCP). Comparing with bit-rate allocation within the encoder’s algorithm, rate-based congestion control algorithms need little interaction with the overlying encoding algorithm. Several bit-rate allocation methods have been developed for media streaming, and recently for FGS video streaming as well [9]–[12]. In [10], the author derives an optimal policy for maximizing bandwidth efficiency and minimizing bit rate variability (instead of video quality) using a prefetch buffer. In [11], the authors develop an optimal adaptation scheme together with an online heuristic to minimize the quality variability; they achieve this by bridging the mismatch between available bandwidth variability and the rate variability of encoded video. Sets of rate-distortion (R-D) points are extracted during the encoding process in [12] and linear interpolation is employed to estimate the actual R-D curve of the enhancement layer signal. The extracted R-D information is then used to determine the bit allocation per frame for constant quality. Rate control in the aforementioned publications is understood as bit-rate allocation without exceeding the maximum rate communicated by underlying congestion control algorithms, like TCP, TFRC, or our proposed MTFRCC. On the other hand, research activities have focused on end-to-end rate-based congestion control algorithms such as TFRC, which is one of the most frequently used rate based congestion control algorithms for TCP-friendly streaming. These endeavors [2], [23] have mainly focused on enhancing congestion control algorithms with TCP-friendly or network centric features, however, without consideration of media-friendliness. A utility-based network model for congestion control has been explored in the field of unicast congestion control algorithms [13], [14]. In this model, a “price” is associated with the congestion level of each individual network link. The link iteratively updates its price based on the aggregate rate of flows traversing it. In turn, a receiver collects the prices of all links on its unicast/multicast path and calculates the overall network price. Then, it adjusts the streaming rate so that its “net benefit”—the receiver’s utility minus the network cost—is maximized. It is shown that this iterative algorithm converges to the optimal point, where the aggregate utility of all receivers

198


B. FGS Video Rate-Distortion Function

TABLE I SUMMARY OF NETWORK MODEL NOTATION

In [16], the authors proposed a mixture-Laplacian statistical model of FGS video streams and derived the rate-distortion for FGS video: function (3) , and are parameters to be evaluated empirically stands for the streaming rate and for the distortion of a single frame. The values of , and vary depending on the source video stream. With the available R-D information, we and , either compute statistically values for the parameters during the encoding process for real-time operation as in [12], or as described in [32], by determining the parameter values from stored bit-streams after the entire video has been encoded [27], [32]. We compute these parameter values once for each video sequence and assume they remain constant throughout the entire streaming process. To tailor the utility function to application quality, we use the rate-distortion function (3) as the utility of our algorithm. In particular we substitute in (1): where

is maximized. We adopt the same price model and use it to formally formulate our problem statement. In our previous work [7], we have shown that the video quality obtained during scalable streaming over the MTFRCC algorithm is superior to the quality obtained with other rate-based congestion control algorithms, like TFRC. Still, the MTFRCC algorithm was not TCP-friendly during periods of severe congestion. In this paper, we further improve the MTFRCC algorithm to be TCP-friendly in the long term (using a two-timescale approach partially demonstrated in [20]). III. MTFRCC SPECIFICATION In this section, we first present our system model, then we specify the MTFRCC algorithm, and finally address the problem of long-term TCP-friendliness.

(4) The rate-distortion function in (3) is strictly decreasing and convex; hence, the utility function (4) is strictly increasing and concave. It follows that solving the problem (1) is equivalent to maximizing the overall video quality or minimizing the overall video distortion in the network. in (4) has to be, in the congestion In practice, the rate avoidance phase, not smaller than the bit-rate of the base layer ; otherwise the application quality will be significantly harmed and packet delivery will be unacceptably delayed.

A. Network Model and Problem Statement We borrow the model proposed in [13] and [15], where the network is abstracted as a set of unidirectional links , each link . The network is shared by a set of having a capacity the utility of source , when sources . We denote with transmits at rate . Let denote the range of for a source . We assume that is strictly increasing rate and concave, and twice continuously differentiable in . Let be the set of links that source traverses while also streaming. Last, for every link , we define as the set of sources that use link . We summarize the notations in Table I. Our objective is to choose source rates such that the overall utility is maximized:

C. Throughput Function of the Distributed Algorithm In the following, we solve the optimization problem (1). Due to the complex coupling of streams at shared links, such optimization schemes require coordination among all sources. For a distributed solution—without centralized coordination among the sources—we need to look at the dual problem. Using the Kuhn–Trucker theorem, we obtain the optimal solution, the (for a detailed derivation, see [13] and [32]): maximizer (5) where being the aggregate Lagrangian multiplier. Substituting (4) in (5) and given that is much smaller than (see [32]), we get

(1) (2) The utility function in the optimization problem (1) could be for instance the quality of the rendered scalable video stream. Note that we are aiming at optimizing the video quality of all streams. Also, it should be noted that the utility function varies according to video coding scheme used. We further elaborate in the utility function heterogeneity issue in Section VI.

(6) Finally, we obtain the optimal response function of our distributed algorithm in steady state (the stage of congestion avoidance):

(7)


199

Fig. 1. Comparison of the rate response function for TFRC and MTFRCC.

Source rate is now determined by the aggregate price (interpreted as aggregate congestion measure like packet loss rate) and the video quality function (rate-distortion function). This fits well with the intuition of the proposed rate control algorithm for scalable video streaming. Given the congestion measure and the rate-distortion function, source can solve (1) autonomously without coordination with other sources. If is dual optimal, then is primal optimal [17, Prop. 5.1.5]. decomposes the primal problem (1) to an individual rate optimization problem for each source. Once is available, can be specified using (7). As shown in [13], [15], the dual problem can be solved by the gradient projection algorithm, which adapts the link prices at links dynamically and the sending rates with a static response function (7) at sources. In fact, our proposed algorithm and the well known TCP congestion avoidance algorithm are both among the dual algorithms. In contrast to the dual algorithm, the source in the primal algorithm adapts the rate dynamically based on the route prices, and the links select a static law to determine the link prices [14]. We design the MTFRCC algorithm based on the gradient projection algorithm. We use the packet loss rate as the congestion information for MTFRCC algorithm. We assume that loss probabilities at links are small such that the end-to-end for all sources and for all are (assume probabilities ): (8) In practice, instead of , we use end-to-end probabilities to update the rate in (7). Note that can be evaluated at the end host without explicit feedback from the links on the data path. We use the Weighted Average Loss Interval method to specify packet loss event rates, similar to TFRC. The source is now determined by (end-to-end packet loss rate) rate and the parameters of the rate-distortion function. Therefore, the MTFRCC algorithm only needs a source algorithm (e.g., like the source rate response function defined in (7)) of a gradient

projection algorithm. Note that a source is capable of computing its target rate independently without coordination with other sources. We practically modify the gradient projection algorithm to the proposed MTFRCC algorithm. 1) A receiver measures and feeds this information back to is the aggregate congestion measure or the the sender aggregate price for all links in the path of and is equal to the end-to-end probabilities as in (8). 2) Sender updates the rate with the response function (7) for the next period; 3) Finally, sender streams video through the network path toward the receiver at the updated rate. D. TCP-Friendliness of MTFRCC In our previous work [7], we have shown that the MTFRCC algorithm is media-friendly. More precisely, we have shown that the induced video quality is superior to the quality obtained with other congestion control algorithms like TFRC. Additionally, the MTFRCC algorithm is also network-friendly and fair to each source under the condition that every streaming source in the network uses the same throughput response function (7) in steady state. The throughput of TCP depends mainly on the round trip time , the retransmission timeout value , the segment size , and the packet loss rate . Using these parameters, an estimate of TCP’s throughput function was derived in [4]. To behave TCP-friendly, the TFRC algorithm adjusts its sending rate based on the TCP throughput equation as illustrated in (9). A major advantage of TFRC is that it maintains a relatively stable sending rate, while providing sufficient responsiveness to changing network conditions: (9) Fig. 1 plots an example of the rate response function (in packets/s) for MTFRCC and TCP/TFRC for various packet loss rates. Note that TCP and TFRC use the same response function (9) in steady state. The figure conveys that, when

200


Fig. 2. Network topology of the simulation experiment.

MTFRCC and TCP flows co-exist in the network, MTFRCC is not as aggressive as TFRC during periods of low congestion. However, during periods of severe congestion, MTFRCC reduces its sending rate slower than TFRC and thus, MTFRCC is not TCP-friendly during these periods. To overcome this shortcoming, we describe in the next section how we adapted our algorithm to meet both goals: Media- and TCP-friendliness. E. Transforming MTFRCC to TCP-Friendly When two traffic flows compete for resources at the same network bottleneck, both flows will obtain a fair share of the bandwidth, only if both flows use equivalent long-term response functions. In order to meet TCP-friendliness, we modify our algorithm using a two-timescale approach. 1) The sender (or receiver) estimates two congestion control parameters (packet loss rates) using the Weighted Average Loss Interval method: the long-term packet loss rate , and the short-term packet loss rate . The long-term packet loss rate is calculated with a long loss history size, reflecting the long term congestion is calcustatus, while the short-term packet loss rate lated with a short loss history size, reflecting the short term congestion status. 2) The server calculates its long-term sending rate using the according to the TFRC relong-term packet loss rate sponse function to meet TCP-friendliness criteria. However, the server reacts to the short-term congestion inforaccording to our MTFRCC response function mation (7) to meet media-friendliness and to achieve optimized overall video quality. Let the rate response function of MTFRCC illustrated in (7) ; and the rate response function of be denoted by . We enhance TFRC illustrated in (9) be denoted by MTFRCC to be TCP-friendly in the long-term by modifying the rate response function of MTFRCC as follows, denoted by :

(10) In (10), at average is:

stands for the gradient of . It follows that the long-term throughput

, and, as a result,that the MTFRCC algorithm is TCP-friendly in the long-term. IV. SIMULATIONS AND ANALYSIS A. Simulation Setup For our experimental evaluation, we use the ns-2 network simulator [18]. The scenario used throughout our simulation studies is illustrated in Fig. 2. To evaluate our algorithm, we use a network topology incorporating two bottleneck links, each of 2 Mbps capacity and 45 ms propagation delay. All other links have a capacity of 10 Mbps and 10 ms propagation delay. We run three point-to-point streaming flows on the described topology; each flow initiates from an FGS streaming source (nodes 3, 5, and 7 respectively) and terminates at an FGS video receiver (nodes 4, 6, and 8, respectively). In Fig. 2, the three flows are labeled as connections 1, 2, and 3, respectively. The FGS video sources dynamically adapt the sending rate by truncating it to any desired bit rate determined by the underlying congestion control algorithm (MTFRCC or TFRC). In an effort to verify fairness of the different algorithms, we add two point-to-point data flows (CBR traffic) to the simulation scenario (“connection 4” between nodes 9 and 10 and “connection 5” between nodes 5 and 8 respectively) to drive bottleneck links to congestion state. For MTFRCC and throughout the entire experimental sesand a shortsion, we use a long-term history size of term history size of , denoted as MTFRCC(256,8). Particular to TFRC, we experimented with two history sizes N: as suggested in [2], denoted as TFRC(8) in our rea) (denoted as sults and b) a rather longer history size TFRC(128) hereafter)—as proposed in [5]—to obtain smoother sending rates. B. Assessment Criteria and Metrics For a given rate control algorithm, we seek to assess its behavior across various criteria by measuring associated evaluation metrics. 1) Fairness to TCP: Expressed by pairwise comparison of sending rate values assigned to competing flows, when all algorithms (here MTFRCC, TFRC, and TCP) coexist in the network. Formally, it is quantified by the fairness index metric, defined as the long-term throughput of a congestion control algorithm divided by the long-term throughput of a TCP flow under same conditions.


2) Responsiveness: Reaction time of the algorithm, when decreasing its sending rate in the presence of severe network congestion. We define as stabilization time the time interval from the start of a severe network congestion incident until the time point, at which the network loss rate converges to its typical steady-state value for this particular level of congestion. Longer stabilization times indicate that an algorithm is less responsive [5]. 3) Aggressiveness: Time required by the algorithm to accelerate its sending rate after congestion, i.e., when additional bandwidth is made available on the streaming path. We quantify aggressiveness with the recovery time metric, defined as the time interval between the time point additional bandwidth becomes available until the moment that the newly available bandwidth is fully utilized. Longer recovery times correspond to longer periods of bandwidth under-utilization after a sudden increase in available bandwidth, thus indicating that a particular algorithm is less aggressive. 4) Smoothness: Rate variations over time for a particular flow in a stationary or dynamic environment. The average rate variability is defined as the average, relative change of the sending rate within two consecutive round-trip times. The smaller the variability of a flow, the higher is its media-friendliness and the more resilient is the streaming flow to network traffic noise. 5) Overall Video Quality: Long-term global video quality of multiple scalable streams. We use average peak signal-to-noise ratio (PSNR) and PSNR variance as the video quality metrics. C. Results In this section, we present the results obtained from simulations we conducted to evaluate our MTFRCC algorithm and to compare it with TFRC. 1) Fairness to TCP: To test the interprotocol fairness, when MTFRCC, TFRC, and TCP flows coexist, we run one single TCP connection on connection 5, one video streaming flow on connection 1 using TFRC, and one video streaming flow on connection 4 using MTFRCC. Connections 1, 4, and 5 encounter comparable conditions, since all flows traverse the same two bottlenecks and experience equal round trip times. To simulate background traffic as found in the real Internet, we add Pareto ON/OFF flows traversing the two congested links. The more Pareto ON/OFF flows we add, the more severe becomes the congestion (higher packet loss rate) in the network. We run simulations, using various number of Pareto ON/OFF flows, to simulate various levels of congestion and packet loss rates with session duration of 30 minutes. We plot the fairness index of MTFRCC and TFRC at various congestion levels in Fig. 3. We observe that the fairness index, for all algorithms and for the tested congestion levels, remained close to 1, indicating that both TFRC, and MTFRCC are TCPfriendly in the long term. Fig. 4 plots the throughput traces of MTFRCC, TFRC, and TCP respectively for 100 s of the simulation experiment (between 400 s and 500 s in absolute simulation time). Additionally the figure shows the aggregated throughput of the three background Pareto ON/OFF flows used (average packet loss rate %). The plot indicates that both TFRC and MTFRCC are

201

Fig. 3. levels.

Fairness of MTFRCC to TCP and TFRC under different congestion

TCP-friendly, since the long-term throughput of both TFRC and MTFRCC is roughly equal to that of the TCP connection. Due to size limitations we omit here presenting the entire throughput traces of the experiment. 2) Responsiveness, Aggressiveness and Smoothness: We evaluate these properties for each algorithm (MTFRCC and TFRC) separately, however always under the same simulation conditions. For this, we install three flows (connections 1–3) using the very same algorithm (either MTFRCC or TFRC) during the entire session. Additionally, we activate a CBR source at 1Mbps on connection 4 to decrease the available s (severe network conbandwidth at absolute time s to gestion) and deactivate it again at absolute time increase available bandwidth. Fig. 5–7 plot the bit rate evolution of each of the two algorithms in the event of severe network congestion and of sudden increase of available bandwidth. From the sending rate traces in these plots, we observe that i) the sending rate obtained with MTFRCC is smoother than the one obtained with TFRC(8) and similar to that obtained with TFRC(128); ii) the aggressiveness of MTFRCC is better than TFRC(128) and close to TFRC(8); and iii) the responsiveness with MTFRCC is better than with TFRC(128), but worse than TFRC(8). We conclude that the intra protocol fairness of MTFRCC is sec). But, similar to that of TFRC in steady state (before after the 60th second, the short-term response function takes effect and MTFRCC reallocates the bit rate differently to TFRC. Compared to TFRC, the MTFRCC algorithm re-allocates the bit rates between the various connections after the sudden increase (respectively decrease) of available bandwidth with the goal to improve the overall video quality of all streaming connections. In this context, MTFRCC penalizes connection 1 with higher packet loss rates and assigns higher bit rates to the two “shorter” connections 2 and 3, which experience lower packet loss rates (as shown in Fig. 6). The bit rate of connection 2 is roughly similar to the bit rate of connection 3, since both encounter comparable packet loss rates. Smoothness: The goal of TFRC and other slow responsive congestion control algorithms is to smooth out the sending rates. Rate variability is used as a metric to quantify how often and to what extent a congestion control algorithm changes its sending rate. The smaller the variability of a flow, the better is its media-friendliness and the more resilient it is to network

202


Fig. 4.

Interprotocol fairness of MTFRCC, TFRC, and TCP with noise (400 s–500 s, p = 0:0074).

Fig. 5. Bit rate traces of connection 1, 2, and 3 with TFRC(8) and connection 4 with CBR traffic.

Fig. 6.

Bit rate traces of connection 1, 2, and 3 with MTFRCC(256, 8) and connection 4 with CBR traffic.


Fig. 7.

203

Bit rate traces of connection 1, 2, and 3 with TFRC(128) and connection 4 with CBR traffic.

Fig. 8. Responsiveness of MTFRCC and TFRC to a sudden decrease of the available bandwidth.

traffic noise. In our experiments, the average rate variability of TFRC(8), TFRC(128) and MTFRCC(256, 8) was 0.041, 0.0274 and 0.028. Hence, the sending rate obtained with MTFRCC is smoother than the one obtained with TFRC(8) and roughly equal to the one obtained with TFRC(128). Responsiveness: Fig. 8 plots the dropping rate of each algorithm at Router 0 of Fig. 2 around the absolute time sec, when congestion is suddenly increased at the 60th second of the simulation. We compare the stabilization time measured with the TFRC algorithm to that measured with MTFRCC algorithms. Longer stabilization times indicate suboptimal congestion control, due to their longer periods of congestion in case of a sudden decrease in the available bandwidth (i.e., algorithms are less responsive). In our evaluation, stabilization times for TFRC(8), TFRC(128), and MTFRCC(256, 8) were 3, 16, and 9 s, respectively. Hence, the responsiveness of MTFRCC is better than the one obtained with TFRC(128), still worse than TFRC(8). We also observe that MTFRCC creates less oscillation in packet loss rates than TFRC(8) and TFRC(128) in steady state.

Aggressiveness: Fig. 9 shows bandwidth utilization after a sudden increase of available bandwidth at time point s for MTFRCC and TFRC. Longer recovery times indicate that a congestion control algorithm will suffer “longer than necessary” periods of bandwidth under-utilization after a sudden increase of available bandwidth (i.e., algorithm are less aggressive). The measured recovery time for TFRC(8), TFRC(128), and MTFRCC(256, 8) was 5, 19.5, and 13.5 s, respectively. We conclude that in terms of aggressiveness, MTFRCC is positioned between TFRC(128) and TFRC(8). 3) Overall Video Quality: We recorded the sending rates s to s of the simulated from absolute time network connections and applied FGS video scaling to these traces. Next, we compare the resulting video quality (luminance component) of the MTFRCC traces with those obtained with TFRC for a specific test video sequence (“Highway”), illustrated in Table II. Note that experimentation with other video sequences yielded similar results. From the video quality results, we observe that the MTFRCC algorithm re-allocates bit rates among the streaming sources in

204


Fig. 9.

Aggressiveness of MTFRCC and TFRC after a sudden increase of available bandwidth at t = 120 sec.

TABLE II VIDEO QUALITY COMPARISON OF MTFRCC AGAINST TFRC

TABLE III SUMMARY OF SIMULATION RESULTS

V. SCALABILITY OF MTFRCC IN THE INTERNET

a manner that improves the overall video quality. Intuitively, flows traversing longer paths should be allocated lower rates, for they consume more network resources (correspond to higher prices). Therefore, MTFRCC in our experiment penalized the longer flow (conn.1) and assigned higher bit rates to the two “shorter” connections (conn.2 and conn.3). Although, MTFRCC allocated bit rates unevenly, it achieved still a better overall performance compared to TFRC in terms of video quality, and thus, it satisfied our initial optimization goal. Note that the unequal video quality for different streams occurs due to the video quality function being nonlinear to the bit rate [see (3)]. In our simulation setting the video quality of connection 1 using MTFRCC is worse than the quality obtained with TFRC. This is due to the network model employed by TCP (TFRC) that uses a different utility function than MTFRCC [29]. Pertaining to variability in video quality, MTFRCC yielded lower fluctuation as compared to TFRC. To enhance overview, we summarize in Table III the assessment results for each algorithm we evaluated. Essentially, the table manifests that the MTFRCC algorithm offers the best tradeoff between network- and media-friendliness among the three options.

In large and dynamic networks, congestion information—or equivalently prices—are sent back to sources with varying (nonuniform) delays. This phenomenon could potentially harm the stability and scalability of the proposed algorithm. In theory, the model used in this paper is scalable to arbitrary network topologies, link capacities and delays: as shown in [13], the convergence of the distributed gradient projection algorithm for this model is guaranteed in large and asynchronous networks. A more thorough analysis of the stability and scalability of the optimization framework can be found in [29]–[31]). As a matter of fact, the congestion control algorithm prominent in the Internet, namely TCP, can be considered as an algorithm using the same network model with a different utility function (specifically, TCP’s utility function). We have build a preliminary prototype implementing the MTFRCC algorithm and conducted several experiments to explore the scalability of MTFRCC in PlanetLab [33]. Our experimental session incorporated one host located in the U.S., one host in Europe, and one host in China. As the connections in our experiments shared only few common links and we have not been able to get the global utility of all the flows coupled in the Internet to compare the global utility, we explored only the fairness and smoothness properties of MTFRCC. For each


205

VII. CONCLUSION

Fig. 10.

Smoothness of MTFRCC and TCP for the flows (China-EU).

pair of endpoints, we set up two concurrent flows with identical source/destination systems: one MTFRCC and one TCP flow. Our preliminary results manifest that the MTFRCC flow was stable, with a smoother rate than the competing TCP flow. A sample of the smoothness comparison results is shown in Fig. 10. As for fairness, the results indicate that the TCP fairness index values of MTFRCC for various paths were all close to one or equivalently that MTFRCC was TCP-friendly [32]. Note that Planetlab nodes in our experiment used BI-TCP [34] stacks, whereas all simulation results presented previously in this paper have been obtained with Sack-TCP. VI. MTFRCC AND VIDEO-ENCODING SCHEMES HETEROGENEITY Since the rate distortion function varies depending on the used video-encoding scheme, it is straightforward that the utility function for other schemes—like MPEG-4 or H.264—will differ from the one obtained with FGS [28]. Throughout this paper, we used the FGS encoding scheme as our reference scheme. However, the primary concept introduced in this work, namely incorporating the rate-distortion function of a video-encoding scheme into congestion control, is directly applicable to other video-encoding schemes beyond FGS. In fact, the specification given in the paper is detailed enough to allow one to apply MTFRCC to any encoding scheme. For this process, the only step not covered herein is the derivation of the optimal response function for non-FGS schemes. Additionally, a real-time bit-rate adaptation [24] or transcoding step must be taken to adapt the application rate to the transmission rate determined by the underlying MTFRCC algorithm. As demonstrated in [25], when two congestion control algorithms with different utility functions coexist in the network, the intra-protocol fairness of each algorithm equals the proportional fairness. With our two-timescale approach, we obtain , where MTFRCC1 stands for the MTFRCC algorithm with response function for the first coding technique and MTFRCC2 stands for the MTFRCC algorithm with the response function for the second coding technique. Therefore, the interprotocol fairness of MTFRCC algorithms will be guaranteed in the long term, i.e., all MTFRCC algorithms are TCP-friendly and meet long-term fairness.

In this paper, we addressed the problem of incorporating media-friendliness in TCP-friendly scalable video streaming. Using FGS as the reference encoding scheme, we first integrated the codec-specific application-utility function into conventional rate-based congestion control. Additionally, we used a two-time scale approach of rate averages (short- and long-term) to force TCP-friendliness in the long term. We have shown that the resulting congestion control algorithm (MTFRCC) achieves smoother sending rates than both TFRC alternatives. Also, we found that MTFRCC produces comparable results to TFRC in terms of responsiveness and aggressiveness in situations of sudden changes in available bandwidth; at the same time however, MTFRCC produces lower oscillations to the sending rate during transitional states. Most importantly, MTFRCC achieves better overall video quality at various congestion levels and with less variance compared to TFRC. Additionally, we discussed the necessary steps to adapt the algorithm presented herein to various other video encoding schemes, beyond MPEG-4 FGS. The main contribution of this work is the proof that incorporating media-awareness into congestion control indeed increases the overall quality of streaming video. We also have shown that this is achieved without violating the established concepts of network-centric congestion control (TCP-friendliness). In addition, we described the methodology for applying media- and TCP-friendly rate control to standard scalable video encoding schemes, together with a vast evaluation framework. Currently, we are about to finalize a prototype implementation of the MTFRCC algorithm that we will deploy on multiple Planetlab nodes. This will use this test infrastructure to test the performance of MTFRCC under real Internet conditions, including its ability to scale to a large number of flows. Beyond the point-to-point paradigm, we plan to extend this work to multicast communication, studying media-friendliness in multi-point scenarios. ACKNOWLEDGMENT The authors would like to thank the anonymous reviewers for their insightful comments. The first author thanks Prof. Q. Zhang, Dr. X. Wang, and Dr. T. Peng, for their valuable comments. REFERENCES [1] S. Floyd and K. Fall, “Promoting the use of end-to-end congestion control in the Internet,” IEEE/ACM Trans. Networking, vol. 7, no. 4, pp. 458–472, Aug. 1999. [2] S. Floyd, M. Handley, and J. Padhye, “Equation-based congestion control for unicast applications,” in ACM SIGCOMM, Sep. 2000, pp. 43–56. [3] D. Bansal and H. Balakrishnan, “Binomial congestion control algorithms,” in Proc. IEEE INFOCOM’01, 2001, pp. 631–640. [4] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, “Modeling TCP throughput: A simple model and its empirical validation,” in SIGCOMM Symp. Communications Architectures and Protocols, Aug. 1998, pp. 303–314. [5] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, “Dynamic behavior of slowly-responsive congestion control algorithms,” in Proc. ACM SIGCOMM’01, Aug. 2001, pp. 263–274. [6] R. Yang, M. S. Kim, and S. S. Lam, “Transient behaviors of TCPfriendly congestion control protocols,” in Proc. IEEE INFOCOM’01, 2001, pp. 1716–1725.

206

[7] J. Yan, K. Katrinis, M. May, and B. Plattner. Optimizing rate control for multiple fine-granular scalable video streams. presented at IEEE ICNP 2004. [Online]. Available: http://people.ee.ethz.ch/~katrinis/pubs/Jinyao_ICNP04.pdf [8] W. Li, “Overview of fine granularity scalability in MPEG-4 video standard,” IEEE Trans. Circuits Syst. Video Technol., vol. 11, no. 3, pp. 301–317, Mar. 2001. [9] P. D. Cuetos and K. W. Ross, “Unified framework for optimal video streaming,” in INFOCOM 2004, vol. 3, Hong Kong, China, Mar. 2004, pp. 1479–1489. [10] P. D. Cuetos and K. W. Ross, “Adaptive Rate Control for Streaming Stored Fine-Grained Scalable Video,” in Proc. NOSSDAV, Miami, FL, May 2002, pp. 3–12. [11] T. Kim and M. H. Ammar, “Optimal quality adaptation for MPEG-4 finegrained scalable video,” in Proc. INFOCOM 2003, vol. 1, San Francisco, CA, Mar. 2003, pp. 641–651. [12] X. Min Zhang, A. Vetro, Y. Q. Shi, and H. Sun, “Constant quality constrained rate allocation for FGS-coded video,” IEEE Trans. Circuits Syst. Video Technol., vol. 13, no. 2, pp. 121–130, Feb. 2003. [13] S. Low and D. E. Lapsley, “Optimization flow control, I: Basic algorithm and convergence,” IEEE/ACM Trans. Networking, vol. 7, no. 6, pp. 861–874, Dec. 1999. [14] F. P. Kelly, A. Maulloo, and D. Tan, “Rate control in communication networks: Shadow prices, proportional fairness and stability,” J. Oper. Res. Soc., vol. 49, pp. 237–252, 1998. [15] R. Srikant, The Mathematics of Internet Congestion Control. Boston, MA: Birkhauser, 2003. [16] M. Dai and D. Loguinov, “Analysis of rate-distortion functions and congestion control in scalable internet video streaming,” in NOSSDAV’03 Monterey, CA, Jun. 2003, pp. 60–69. [17] D. P. Bertsekas, Nonlinear Programming. Boston, MA: Athena Scientific, 1995. [18] Network Simulator (NS-2) [Online]. Available: http://www.isi.edu/ nsnam/ns/ [19] Z. Wang, S. Banerjee, and S. Jamin, “Media-friendliness of a slowly-responsive congestion control protocol,” in NOSSDAV’03 Cork, Ireland, Jun. 2004, pp. 82–87. [20] J. Yan, M. May, K. Katrinis, and B. Plattner, “A new TCP friendly rate control algorithm for scalable video streams,” in Lecture Notes in Computer Science 3462 Waterloo, ON, Canada, 2005. IFIP Networking 2005. [21] D. Wu, Y. T. Hou, and Y.-Q. Zhang, “Transporting real-time video over the Internet: Challenges and approaches,” Proc. IEEE, vol. 88, no. 12, pp. 1855–1877, Dec. 2000. [22] F. Wu, S. Li, and Y.-Q. Zhang, “A framework for efficient progressive fine granularity scalable video coding,” IEEE Trans. Circuits Syst., Video Technol., vol. 11, no. 3, pp. 332–344, Mar. 2001. [23] I. Rhee, V. Ozdemir, and Y. Yi, “TEAR: TCP Emulation at Receivers—Flow Control for Multimedia Streaming,”, NCSU Tech. Rep., Apr. 2000. [24] “Proposed draft of adaptive rate control,” in Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG (ISO/IEC JTC1/SC29/WG11 and ITUT SG16 Q.6) 8th Meeting, Geneva, Switzerland, May 20–26, 2003. [25] A. Tang, J. Wang, S. Hegde, and S. H. Low, “Equilibrium and fairness of networks shared by TCP Reno and Vegas/FAST,” Telecommun. Syst., Special Issue on High Speed Transport Protocols, pp. 417–439, 2005. [26] D. Tan and A. Zakhor, “Real-time internet video using error resilient scalable compression and TCP-friendly transport protocol,” IEEE Trans. Multimedia, vol. 1, no. 2, pp. 172–186, Jun. 1999. [27] P. D. Cuetos, M. Reisslein, and K. W. Ross, “Evaluating the Streaming of FGS-Encoded Video with Rate-Distortion Traces,”, Inst. Eurecom Tech. Rep. RR-03-078, Jun. 2003. [28] L. U. Choi, M. T. Ivrlac, E. Steinbach, and J. A. Nossek, “Sequence-level models of distortion-rate behavior of compressed video,” in Proc. ICIP, vol. 2, Sep. 2005, pp. 486–489. [29] S. H. Low, F. Paganini, and J. C. Doyle, “Internet congestion control,” IEEE Control Syst. Mag., vol. 22, no. 1, pp. 28–43, Feb. 2002. [30] L. Massoulie, “Stability of distributed congestion control with heterogeneous feedback delays,” Microsoft Research, Cambridge, U.K., Tech. Rep. TR 2000-111, 2000. [31] G. Vinnicombe, “On the stability of end-to-end congestion control for the Internet,” Cambridge Univ., Cambridge, U.K., Tech. Rep. CUED/FINFENG/TR.398, Dec. 2000. [32] J. Yan, K. Katrinis, M. May, and B. Plattner, “Media- and TCP-Friendly Congestion Control for Scalable Video Streams (Extended Version),” Swiss Fed. Inst. Technol., Zürich, Switzerland, http://www.tik.ee. ethz.ch/~katrinis/pubs/TIK-Report234.pdf, TIK Rep. 234, Nov. 2005.


[33] PlanetLab [Online]. Available: http://www.planet-lab.org/ [34] L. Xu, K. Harfoush, and I. Rhee, “Binary increase congestion control for fast long distance networks,” in INFOCOM 2004, Hong Kong, Mar. 2004. [35] J. Schmitt, M. Zink, S. Theiss, and R. Steinmetz, “Improving the start-up behavior of TCP-friendly media transmissions,” in Proc. Int. Network Conf. (INC’02), Plymouth, U.K., Jul. 2002, pp. 73–80. ISBN 1-84 102105-9.

Jinyao Yan received the B.E. degree from Tianjin University, Tianjin, China, in 1995 and the M.E. degree from the Communication University of China, Beijing, in 1998. His research interests are multimedia communications, congestion control, p2p/overlay networks.

Kostas Katrinis received the Diploma in computer engineering from the Computer Engineering and Informatics Department (CEID), University of Patras, Greece, in 2000. He is pursuing the Ph.D. degree with the Communication Systems Group at the Swiss Federal Institute of Technology (ETH Zürich), Zürich, Switzerland. His principal research interests include group and multimedia communication, overlay networks and self-organization in computer networks.

Martin May (M’97) received the M.Sc. degree in computer science from the University of Mannheim in 1996 and the Ph.D. degree from the University of Nice, France, in 1999. He did most of his thesis work on Internet QoS mechanisms at INRIA, Sophia Antipolis, France, but was also Technical Staff Member of Lucent Bell-Labs Research, Holmdel, NJ and Sprintlabs, Burlingame, CA. Until the beginning of 2000, he continued his research as a post-doctoral Member of the Research Staff at Sprintlabs. From 2000 until 2003, he founded a start-up company in France, where he worked in the field of content delivery networking. He is now a Senior Researcher at the Swiss Federal Institute of Technology (ETH Zürich), Zürich, Switzerland. His research interests are in self-organizing networks, mobile ad-hoc networks, and network security. Dr. May is a member of the ACM and the Internet Society. He served on the programm committees for multiple networking conferences and is an active member of the IETF, where he is co-editor of multiple Internet drafts and RFCs.

Bernhard Plattner (S’75–M’83) is a Professor of computer engineering at at the Swiss Federal Institute of Technology (ETH Zürich), Zürich, Switzerland, where he leads the communication systems research group. He has been the principal investigator or Co-PI of numerous national and international projects in the area of computer networking. His current research interests are in self-organizing networks, mobile ad-hoc networks, as well as practical aspects of information security. He has also directed research on active networks, starting as early as 1996, and multimedia applications for high-speed networks. In 1996–1998, he served as the Head of Faculty of Electrical Engineering at ETH Zürich. He currently is the Vice-Rector of ETH for Bachelor/Master studies. Dr. Plattner is a member of the ACM and the Internet Society. He served as the program or general chair of various international conferences, such as ACM SIGCOMM’91, INET’94, and IWAN 2002.