A New TCP-Friendly Rate Control Algorithm for Scalable Video Streams.

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221198399 A New TCP-Friendly Rate Control Algorithm for Scalable Video Streams. CONFERENCE PAPER in LECTURE NOTES IN COMPUTER SCIENCE JANUARY 2005 Impact Factor: 0.51 DOI: 10.1007/11422778_107 Source: DBLP CITATIONS 3 READS 44 4 AUTHORS: Jinyao Yan Communication University of China 30 PUBLICATIONS 106 CITATIONS Martin May Technicolor 94 PUBLICATIONS 2,585 CITATIONS SEE PROFILE SEE PROFILE Kostas Katrinis IBM 57 PUBLICATIONS 290 CITATIONS Bernhard Plattner ETH Zurich 260 PUBLICATIONS 4,371 CITATIONS SEE PROFILE SEE PROFILE Available from: Bernhard Plattner Retrieved on: 08 April 2016

A new TCP-friendly Rate Control Algorithm for Scalable Video Streams Jinyao Yan 1,2, Martin May 1, Kostas Katrinis 1, Bernhard Plattner 1 1 Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology,ETH Zurich, Switzerland 2 Communication University of China, Beijing, China jinyao, maym, katrinis, plattner@tik.ee.ethz.ch Abstract. This paper presents a new TCP-friendly rate control algorithm (i.e., MTFRC) for streaming media applications in the Internet. This algorithm integrates two new techniques: (i) the use of an application-utility function into the rate control algorithm; and (ii) a two-time-scale approach of rate averages (long-term and short-term) to satisfy TCP and application/media-friendliness. We use simulations and video quality measurement to evaluate the algorithm and compare the results with the commonly used TCP-Friendly Rate Control (TFRC) methods. We define five criteria to evaluate the two approaches, namely TCP fairness, responsiveness, aggressiveness, video quality, and the smoothness of the resulting bit rate. Simulation studies confirm that MTFRC, due to the two long and short-term averages, performs better in the different environments than TFRC and improves the overall video quality. 1 Introduction Today s dominant transport protocol, TCP, reacts to packet loss by controlling the number of outstanding unacknowledged data segments allowed in the network. In steady state, TCP uses an additive increase multiplicative decrease mechanism (AIMD) to detect additional available bandwidth and to react to congestion. TCP congestion control is suitable and efficient for bulk data transfers. However, it is not well suited for the growing number of audio/video streaming applications. Indeed, without congestion control, non-tcp traffic could cause starvation or even congestion collapse for TCP traffic if both types of traffic were competing for resources at a congested FIFO queue [1]. As a result, new TCP-compatible congestion control mechanisms [2] [3] were proposed for audio/video streaming applications in order to handle competing dominant TCP-flows in a fair manner and limit the variation of throughput accorded to the application (smoothed throughput). These mechanisms have two important characteristics in common: (i) slow responsiveness to smooth the throughput; and (ii) TCP-friendliness. TCP-friendliness is defined as a flow that, in steady-state, uses no more bandwidth than a conforming TCP flow running under comparable conditions [1].

TCP-Friendly Rate Control (TFRC) [2] is an equation-based congestion control mechanism that uses the TCP throughput function presented in [4]. Previous work [5] [6] shows that TFRC offers better performance than other responsive congestion control protocols, in terms of a) the smoothness of the sending rate, b) the responsiveness, and c) the aggressiveness with regard to the network resource utilization. But, there is a fundamental shortcoming of the existing rate based congestion control protocols: they are optimizing the consumption of network resources only and do not take the resulting application quality into account. Even though TFRC can smooth the rate variability for video streaming, it does not minimize the distortion of the streamed video or, in others words, does not maximize the video quality. To minimize the video stream distortion (or maximize the video quality), we introduced in our previous work [7] the video quality function of scalable video streams as the utility function into the utility-based network model. We derived the optimal throughput response function to maximize the overall video quality for scalable video streams (see Appendix). Based on this throughput function, we design a new rate control algorithm called MTFRC (Media- and TCP-friendly Rate Control Algorithm). Given a system with scalable video streaming sources, receivers and links, the difficulty is to allocate a rate value to each source that it is both TCP- and media-friendly. A media-friendly rate control algorithm is defined in a way that it optimizes the overall video quality for the video streams in the network. The main contribution of this paper is development of the TCP-friendly MT- FRC algorithm, which performs better with scalable video streams than TFRC. It optimizes the overall video quality, while maintaining TCP friendliness in long term. We use MPEG-4 Fine-Granularity Scalable (FGS) coding [8] as an example of scalable video coding technology. FGS video streams can be dynamically adapted to the varying condition of the network by truncating them to any desired bit rate determined by underlying rate control protocols like TFRC. FGS coding allows for using a continuous rate-distortion function at the receiver or relay, instead of the step-like function yielded by layered encoding techniques. The paper is organized as follows. In section 2, we review the related work; Section 3 analyzes and describes the new TCP-friendly rate control algorithm for scalable video streams. Then, we analyze the results of our simulations in section 4 and conclude the paper in section 5. 2 Related Work Rate control for video streaming has a two-fold mission, performing rate adaptation for streaming applications and performing rate-based congestion control. Several bit rate control methods have been developed for multimedia streaming, and recently also for FGS video streaming [9] [10] [11] [12]. In [11], the author derives an optimal policy for maximizing bandwidth efficiency and minimizing bit rate variability (instead of video quality) using a prefetch buffer. In [10], the authors develop an optimal adaptation scheme and an online heuristic to mini-

mize the quality variability by accommodating the mismatch caused both by the available bandwidth variability and the encoded video variability. In [12], sets of rate-distortion (R-D) points are extracted during the encoding process 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 above-mentioned publications is understood as rate adaptation in application without exceeding the maximum rate communicated by underlying layers like TFRC or TCP. On the other hand, research activities have focused on end-to-end rate based congestion control algorithms such as TFRC, over which most scalable video nowadays is streamed. In [3] [2] [5], rate control algorithms are designed to be TCP-friendly however, without consideration for application or media-friendliness. A utility-based network model for resource allocation has been explored in the field of unicast rate control algorithms in [13]. In this model, a price is associated with each individual network link (congestion control information). The link iteratively updates its price based on the aggregate rate of flows traversing it. The receiver in turn 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 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 is maximized. We studied this price model and used it to solve our formulated problem in our previous work [7] (see also appendix). FSRC, the rate-based congestion control algorithm introduced in [7] optimizes both, the quality of streaming application and the consumption of network resources. We model the relation between the video quality of FGS video and its sending bit rate. Then, we introduce the resulting video quality of as the utility function to the utility-based network model. Specifically, maximizing the utility equals to maximizing the video quality in the network. Unlike TFRC, FSRC s rate control algorithm is not related to network congestion measures only to meet network friendliness, but also related to the application benefit, such as the video quality, to meet the media-friendliness criteria. In our previous work, we have shown that the video quality based on FSRC rate control algorithm is superior to the quality obtained with other rate control protocols like TFRC. However, the proposed FSRC algorithm was not TCP-friendly during periods of severe congestion. In this paper, we will improve FSRC to be a TCP-friendly rate control algorithm: improved TCP-friendly MTFRC. The idea is that we calculate the long-term rate according to the long-term congestion information to meet the TCP-friendliness, and the sending rate reacts to the short-term congestion concerning the rate-distortion function of FGS video like MTFRC.

3 Media- and TCP-Friendly Rate Control Algorithm In this section, we describe the basics of our MTFRC algorithm and how we address the problem of long-term TCP-friendliness. First, we explain the throughput response function, i.e., the algorithm used to determine the sending rate. 3.1 Deriving the throughput function The throughput response function of our MTFRC algorithm is derived from the price model described in [13]. For our model, we used the rate-quality function from the FGS video stream as utility function as described in [7]. The source rate x s is determined by p (the end-to-end packet loss rate) and the parameters of the rate-distortion function. Hence, we define the throughput response function of our MTFRC algorithm as follows: log x(p) =( 2 ( p a ln 2 ) c a a + b2 4a 2 b 2a )2 (1) The throughput of TCP depends mainly on the parameters round-trip time t RT T, retransmission timeout value t RT O, segment size s, andpacket loss rate p. Using these parameters, an estimate of TCP s throughput function Eq. (2) was derived in [4]. To behave TCP-friendly, the TFRC protocol adjusts its sending rate based on the TCP throughput equation shown in Eq. (2). A major advantage of TFRC is that it has a relatively stable sending rate while still providing sufficient responsiveness to competing traffic. x(p) = 2p R 3 + t RT O(3 s 3p 8 ) p(1 + 32p2 ) (2) 3.2 Discussion on TCP-friendliness in MTFRC The MTFRC algorithm is network friendly and fair to each source under the condition that every streaming source in the network uses the same throughput response function Eq. (1). But, MTFRC and TCP act with different response functions when they co-exist in the network. Figure 1 plots an example bit rate response function of MTFRC and TCP or TFRC (note that TCP and TFRC use the same response function (2) in steady state). Figure 1 shows that when MTFRC and TCP flows co-exist in the network, MTFRC is not as aggressive as TFRC during periods of small congestion. However, during periods of severe congestion, MTFRC reduces the bit rate slower than TFRC; thus MTFRC is not TCP-friendly during this period. To overcome this shortcoming of our algorithm, we describe next how the mechanism can be adopted to achieve both goals: TCP- and media-friendliness.

Fig. 1. Comparison of the rate response function for TFRC and MTFRC 3.3 Transform MTFRC into a TCP-friendly Rate Control Algorithm When two traffic flows compete for resources at the same network bottleneck, both flows will only obtain a fair share of the bandwidth if both flows apply similar long-term response functions. In order to meet TCP-friendliness with our MTFRC algorithm, we modify the algorithm as follows: 1. The sender (or receiver) estimates two congestion control parameters (packet loss rates): the long-term packet loss rate p L, and the short-term packet loss rate p S. 2. The server calculates its long-term sending rate using the long-term packet loss rate p L according to the TFRC response function to meet the TCPfriendliness. However, the server reacts to the short-term congestion information p S according to our new MTFRC response function (1) to meet the media-friendliness and to achieve optimized overall video quality. Let the rate response function of MTFRC Eq. (1) be denoted by X MTFRC (p); and let the rate response function of TFRC Eq. (2) be denoted by X TFRC (p). Then, the rate response function of our improved TCP-friendly MTFRC is: X MTFRC (p S )=X TFRC (p L )+X MTFRC(p L ) (p S p L ) (3) Alternatively, one can adjust the parameters a, b, orc in Eq. (1) to achieve X MTFRC (p L )=X TFRC (p L ). Then, sending rate X MTFRC(pS) can be determined using the same values for a, b, orc. 4 Simulations and Analysis 4.1 Description of Simulation Setup For our studies, we use the ns2 network simulator [14]. The scenario implemented throughout our simulations is illustrated in Figure 2. Physical links are marked

with propagation delay and bandwidth. To evaluate our algorithm, we designed a network topology with two bottleneck links, each of a capacity of 2 Mbps. All other links have a capacity of 10 Mbps, introducing 10ms delay. Three FGS video streaming servers (node 3, 5 and 7) as well as three FGS video streaming clients (node 4, 6 and 8) are plotted as connections 1,2 and 3 as shown in figure 2. The FGS video servers dynamically adapt the sending rate by truncating it to any desired bit rate determined by the underlying rate control protocol (MTFRC or TFRC). Connection 4, between node 9 and node 10, will be used to verify TCP-friendliness as well as to inject heavy cross traffic into the network (sending CBR traffic) in order to decrease the available bandwidth (discussed in section 4.2). Fig. 2. Network Topology of the simulation environment 4.2 Results and Analysis In this section, we present the results obtained from simulations we conducted to evaluate our MTFRC algorithm, compared to TFRC. For evaluation, we identified the following five criteria: 1) Fairness: variations over the sending rates of competing flows; 2) Responsiveness: reaction time of the protocol to decrease the sending rate if severe network congestion occurs; 3) Aggressiveness: acceleration of protocol sending rate after congestion (increase of the available bandwidth); 4) Smoothness: rate variations over time for a particular flow in a stationary or dynamic environment; and 5) Overall FGS video quality. Fairness, responsiveness and aggressiveness stand for the friendliness of the algorithm with regard to the network. The last 2 properties (smoothness and video quality) stand for the friendliness of the algorithm with regard to the application quality. Paper [2] suggests a window size of N=8 as a default value for loss history size in TFRC, i.e. TFRC(8). While in order to achieve smoother rates, authors in [5] and [15] suggest to set the history size to N=128, i.e. TFRC(128). In this paper, we will compare the characteristics of our proposed MTFRC algorithm to the properties of TFRC(8) and TFRC(128). For MTFRC as used in the simulation study, we use a long-term history size of N L =256 and a short-term history size of N s =8, i.e. MTFRC (256, 8). The method used to calculate the loss event rate

in MTFRC is the same as the Weighted Average Loss Interval (WALI) method applied in TFRC. TCP fairness Conn. 1 and 4 encounter comparable conditions, since both of them go through the same 2 bottlenecks and both have the same round trip time. To examine TCP-friendliness, we run one single TCP connection on conn. 1 and one single video stream on conn. 4 using TFRC (in Figure 3(a))or MTFRC (in Figure 3(b)). The throughput obtained with TFRC and MTFRC is plotted in Figure 3(a) and 3(b). (a) (b) Fig. 3. TCP fairness of TFRC (a) and MTFRC (b) with noise (Connection 1 with TCP, Connection 4 with TFRC(8) and MTFRC(256,8) ) We add background traffic (5 Pareto ON/OFF flows, each with a mean sending rate of 100kbps) to the network traffic running over the two bottlenecks. Figure 3(a) and Figure 3(b) indicate that both, TFRC and MTFRC, are TCPfriendly, since the long-term throughput of TFRC and MTFRC is roughly equal to that of the TCP connections. The average bandwidth-share ratio of TFRC to TCP (from the 0th to the 100th second) is 0.82 (see Figure 3(a)) and 0.83 with MTFRC (see Figure 3(b)). The intra protocol fairness of MTFRC will be examined in the following subsection and is in illustrated in Figure 4(b). Responsiveness, Aggressiveness and Smoothness The next 3 figures (Fig. 4(a), Fig. 4(b), and Fig. 4(c)) plot the bit rate evolution of the two protocols in the event of severe network congestion and sudden increase of bandwidth. We use a CBR source (sending rate: 1Mbps) on conn. 4 to decrease the bandwidth at the 60th second (severe network congestion) and to increase the available bandwidth at the 120th second. From the sending rate traces of the plotted connections in Figures 4(a), 4(b), 4(c), we follow that: (i) The sending rate obtained with MTFRC is smoother than

(a) (b) (c) Fig. 4. Bit rate traces of connection 1, 2 and 3 with TFRC(8) (a), MTFRC(256,9) (b), and TFRC(128)(c) the one obtained with TFRC(8) and similar to that obtained with TFRC(128); (ii) the aggressiveness of MTFRC is better than TFRC(128) and close to TFRC(8); (iii) the responsiveness with MTFRC is better than with TFRC(128), but less responsive than TFRC(8). More generally, we conclude that the intra protocol fairness of MTFRC is similar to that of TFRC in steady state (before 60th second). But after 60th second, the short-term response function takes effect and MTFRC reallocates the bit rate differently to TFRC. The MTFRC algorithm penalizes conn. 1 with higher packet loss and assigns higher bit rates to the two short conn. 2 and 3, which suffer less packet losses (as shown in figure 4(b)). Comparing with TFRC, the MTFRC algorithm re-allocates the bit rates between the streaming connections after steep increase or decrease of bandwidth with the goal to improve the total video quality of all streaming connections. The bit rate of conn. 2 is roughly similar to the bit rate of conn. 3 since both encounter comparable packet loss rates on similar network topologies.

Smoothness The goal of TFRC and other responsive congestion control algorithms is to smooth the sending rates. The variability metric of the sending rate is used to analyze how often and to what extent a protocol 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 traffic noise. The average rate variability is defined as the average, relative change of the sending rate in two consecutive round-trip times. In this simulation, the average rate variability of TFRC(8), TFRC(128) and MTFRC(256, 8) are respectively 0.041, 0.0274 and 0.028. Hence, the sending rate obtained with MTFRC is smoother than that obtained with TFRC(8) and roughly equal to that obtained with TFRC(128). Responsiveness The following figure plots the dropped-bit rate of each protocol at router 0 when the network congestion is suddenly increased at the 60th second of the simulation. We define the stabilization time as the time, between the start of the severe network congestion and the moment, when the network loss rate converges to the typical steady-state value for such level of congestion. Fig. 5. Responsiveness of MTFRC and TFRC to a sudden decrease of the available bandwidth We compare the stabilization time measured with the TFRC algorithm to that measured with MTFRC algorithms. Longer stabilization times indicate suboptimal congestion control algorithms, due to their longer periods of congestion in case of a sudden decrease in the available bandwidth [5] (i.e., algorithms are less responsive). In this simulation study, stabilization time of TFRC(8), TFRC(128) and MTFRC(256, 8) are respectively 3 seconds, 16 seconds and 9 seconds. Hence, the responsiveness of MTFRC is better than TFRC(128), but slower responsive than TFRC(8). We also observe that MTFRC has less oscillation of packet loss than TFRC(8) and TFRC(128) in steady state.

Aggressiveness The next figure shows the utilization of bandwidth after the sudden increase of available bandwidth at the 120th second. We define the recovery time as the time, between the moment when the new bandwidth is available, and the time until the newly available bandwidth is occupied. We compare the Fig. 6. Aggressiveness of MTFRC and TFRC to a sudden increase of the available bandwidth recovery time of TFRC with that of MTFRC algorithms. Longer recovery time indicate congestion control algorithms that suffers longer than necessary periods of bandwidth under-utilization after a sudden increase in available bandwidth (i.e., algorithms are less aggressive). We measured recovery time for TFRC(8), TFRC(128) and MTFRC(256, 8) with respectively 5 seconds, 19.5 seconds and 13.5 seconds. We conclude that in terms of aggressiveness MTFRC performs between TFRC(128) and TFRC(8). Overall FGS video quality We apply the obtained sending rate traces of the simulated network connections to FGS video scaling and compare the resulting video quality (luminance component) obtained with the MTFRC algorithm with that achieved by TFRC (depicted in the following table 1) for different streaming examples. 4.3 Summary of evaluation results In table 2, we summarize the results of our evaluation. Overall, our improved TCP-friendly rate control algorithm (MTFRC) offers the best tradeoff between network- and media-friendliness.

Measurement Results from Video Sequence Highway Connection 1 Connection 2 Connection 3 PSNR over MTFRC 29.41 35.26 35.20 PSNR over TFRC 30.65 34.28 34.25 Total quality gain Increase of PSNR over MTFRC=0.71 Measurement Results from Video Sequence Akiyo PSNR over MTFRC 28.54 32.07 32.17 PSNR over TFRC 29.25 31.40 31.46 Total quality gain Increase of PSNR over MTFRC= 0.67 Measurement Results from a long Video Sequence Highway PSNR and its variance 27.9 32.35 32.36 with MTFRC σ = 0.020 σ = 0.0099 σ = 0.010 PSNR and its variance 29.39 30.70 30.69 with TFRC σ = 0.018 σ = 0.020 σ = 0.020 Total quality gain Increase of PSNR over MTFRC=1.7 Table 1. Rate traces from different video stream examples. (PSNR: Peak Signal-to- Noise Ratio) MTFRC(256,8) TFRC(8) TFRC(128) Fairness to TCP all algorithms are TCP-friendly Smoothness of bit rate Smoother than Smooth bit rate Smoother TFRC(8), roughly than TFRC(8) same as TFRC (128) similar to MTFRC Responsiveness Middle Fast Slow Aggressiveness Faster than Faster than Slower than TFRC (128), slower TFRC (128) TFRC(8) and MTFRC than TFRC(8) and MTFRC Video quality Better video quality Similar quality Similar quality (8) than TFRC (8) to TFRC (128) to TFRC and TFRC(128) worse than MTFRC worse than MTFRC Table 2. Summary of the simulation results 5 Conclusion and future work In this paper, we studied a new, optimized, TCP-friendly rate control algorithm for scalable video streams. We modified our previous work, which improved the global video quality of scalable streaming sources, to be conforming to the TCPfriendly rate control protocol. The resulting algorithm introduces two interesting new features to rate control: (i) the integration of an application-utility function into the rate control algorithm; and (ii) a two-time-scale approach of rate averages (long-term and short-term) to satisfy TCP and application/mediafriendliness. Using simulations, we showed that our algorithm is TCP-friendly and achieves an improved network-friendly behavior (evaluated in terms of responsiveness, aggressiveness and fairness). We also measured the media-friendliness of our

algorithm in terms of sending rate smoothness and video quality. Results confirm that our protocol outperforms standard TFRC algorithms while being more flexible due to the use of two rate averages. We will continue to evaluate our algorithm in more generalized simulation scenarios, and implement the algorithm in existing streaming applications. Finally, we will conduct additional experiments to explore the performance of our proposed algorithm on the Internet and on PlanetLab. References 1. Sally Floyd and Kevin Fall, Promoting the use of end-to-end congestion control in the Internet, IEEE/ACM Transactions on Networking, vol. 7, 1999. 2. Sally Floyd, Mark Handley, Jitendra Padhye, and Jorg Widmer, Equation-based congestion control for unicast applications, in Proceedings of SIGCOMM, Stockholm, Sweden, August 2000, pp. 43 56. 3. Deepak Bansal and Hari Balakrishnan, Binomial congestion control algorithms, in INFOCOM, 2001, pp. 631 640. 4. J. Padhye, J. Kurose, D. Towsley, and R. Koodli, A model based TCP-friendly rate control protocol, UMass-CMPSCI Technical Report TR 98-04, 1998. 5. D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, Dynamic behavior of slowly-responsive congestion control algorithms, Proceedings of ACM SIGCOMM, 2001. 6. Yang Richard Yang, Min Sik Kim, and Simon S. Lam, Transient behaviors of TCP-friendly congestion control protocols, in INFOCOM, 2001, pp. 1716 1725. 7. Jinyao Yan, K. Katrinis, M. May, and B. Plattner, Optimizing rate control for multiple fine-granular scalable video streams, Proceedings of ICNP 2004, 2004. 8. W. Li, Overview of fine granularity scalability in mpeg-4 video standard, in Transactions on Circuits and Systems for Video Technology, 2001. 9. Philippe De Cuetos, Unified framework for optimal video streaming,. 10. T. Kim and M. Ammar, Optimal quality adaptation for mpeg-4 fine-grained scalable video, in Proceedings of IEEE INFOCOM, 2003. 11. Philippe de Cuetos and Keith W Ross, Adaptive rate control for streaming stored fine-grained scalable video, in Proceedings of NOSSDAV 02, May 2002. 12. Xi Min Zhang, Anthony Vetro, Yun-Qing Shi, and Huifang Sun, Constant-quality constrained-rate allocation for fgs video coded bitstreams., in VCIP, 2002, pp. 817 827. 13. Steven H. Low and David E. Lapsley, Optimization flow control I: basic algorithm and convergence, IEEE/ACM Transactions on Networking, vol. 7, no. 6, pp. 861 874, 1999. 14. ns-2 network simulator, http://www.isi.edu/nsnam/ns/. 15. Zhiheng Wang, Sujata Banerjee, and Sugih Jamin, Media-friendliness of a slowlyresponsive congestion control protocol, in Proceedings of NOSSDAV. 2004, pp. 82 87, ACM Press. 16. Seong ryong Kang, Yueping Zhang, Min Dai, and Dmitri Loguinov, Multi-layer active queue management and congestion control for scalable video streaming, in Proceedings of ICDCS 04. 2004, pp. 768 777, IEEE Computer Society.

A Appendix A.1 Network model We use the model proposed in [13], where the network consists of a set L of unidirectional links of capacities c l, l L. The network is shared by a set S of sources. U s (x s ) is the utility of source s when s transmits at rate x s.let I s =[m s,m s ] denote the range of rate x s for a source s. We assume that U s is strictly increasing and concave, and twice continuously differentiable on s.for each link l let S(l) ={s S l L(s)} be the set of sources that use link l. Our objective is to choose source rates x s so as to maximize the overall utility in the network: subject to max m x M s S(l) U s (x s ) (4) s x s c l l L (5) A.2 Model for the FGS video In [16], the authors propose the mixture-laplacian statistical model of FGS video data and derived the rate-distortion function for FGS video as follow: D(R) =2 ar+b R+c (6) A.3 Throughput response function of the MTFRC algorithm Solving the dual problem of Eq. (4) we get: x s (p) =[U s 1 (p)] Ms m s (7) p being the aggregate Lagrangian multiplier (congestion control information). We set U s (x s )= D s (x s ) in Eq. (7). The responses function of MTFRC: x s (p) =[( log 2 p aln2 a c a + b2 4a 2 b 2a )2 ] Ms m s (8) The source sending rate x s is determined by aggregate congestion control information p and the parameters of the rate-distortion function of FGS video streams. We make an assumption that loss probabilities p l are small so that the end-to-end probabilities p e for all sources and for all t is: p e (t) =1 l (1 p l ) l p l = p (9) Practically, we use end-to-end probabilities p e as p to update the rate.