Performance Evaluation of End-to-End TCP-friendly Video Transfer in the Internet

Transcription

1 Performance Evaluation of End-to-End TCP-friendly Video Transfer in the Internet Suhaidi Hassan and Mourad Kara ATM-Multimedia Research Group School of Computing, University of Leeds Leeds LS2 9JT, United Kingdom { suhaidi I mourad 0comp.leeds.ac.uk) Abstract In this paper; we use network simulator ns2 to evaluate the performance of a TCP-friendly rate-based control protocol for transfering high-quality video in the Internet. Apart from studying the friendliness property of the TCPfriendly protocol, we define and use the rate-uniformness metric to study the degree of mismatch in the video transfer rate. The latter metric suggests the delivered quality of the MPEG2 video traffic at the receiver side. Using these metrics, we evaluate the performance using the best and the worst RED configurations determined in our previous work. We use TFRCe an equation-based TCP-friendly protocol for transporting the MPEG2 video trafic against the competing TCP Sack sources. Our results shows that under the best RED configuration, TCP-friendly protocol is capable preserving the friendliness behavior while delivering high-quality video. 1. Introduction The new set of multimedia applications is emerging to satisfy the growing demands of Internet users. Nowadays, applications such as real-time and streaming audio and video not only become more typified in the Internet but also account for a significant, and increasing portions of the Internet traffic. These applications produce traffic that must coexist and share Internet resources with the majority of traffic comprising TCP flows. In addition, they require real-time performance guarantees such as bounded delay and minimum bandwidth. Therefore, supporting these traffic over heterogeneous multi-protocol networks such as the Internet is not a trivial task. Most of these real-time applications are non-tcp-based, they are usually not built with adequate congestion control, mainly for simplicity reason. These applications produce traffic flows that are considered unresponsive with respect to the congestion control mechanisms deployed in the network. Widespread deployment of these traffic in the Internet threatens fairness to competing TCP traffic and may lead into possible congestion collapse [2]. Congestion collapse is a situation where although the network links are heavily utilized, very little useful work is being done, and packets transmitted will simply be discarded before reaching their final destinations. One possible approach to overcome the unfairness problem is by deploying the rate-based congestion control mechanisms within such applications, making them adaptive to the network conditions. Since dominant portion of today s Internet traffic is TCP-based, such congestion control mechanisms must be TCP-friendly. For this purpose, several unicast TCP-friendly rate-based control protocols have been proposed such as in [13, 7, 11, 3, 101. In these works, the adjustment of the transmission rate largely relies upon the indication of packet loss in the network during congestion. During this congestion period, packets are dropped by the network routers in the effort to reduce the congestion level. The higher loss rate can give negative effects on the TCP-friendliness of the rate-based sources. The cooperation from the congestion avoidance mechanisms such as Random Early Detection (RED) [4] at the network routers are needed to support and improve the TCP-friendliness. This paper describes our work on evaluating the performance of a TCP-friendly rate-based control protocol for transferring high-quality video in the Internet. For this purpose, we use the network simulator ns2 [I] as the tool for performance evaluation. In this work, apart from exploring the friendliness property of the TCP-friendly protocol, we define and use a new metric called rate-uniformness to study the degree of mismatch in video transfer rates. The latter metric is used to suggests the delivered quality of the $ IEEE 56

2 I MPEG2 [I61 video traffic at the receiver s side. In addition, we use the packet loss count as another indicator for implying the delivered video data. Using these metrics, we evaluate the performance of the best and the worst network scenarios determined in our previous work [5]. We use TFRCP, an equation-based TCP-friendly protocol [ 151 for transporting the MPEG2 video traffic against the competing TCP sources. Our motivations for this work are threefold: (1) The high global demands for avoiding congestion collapse in the Internet by employing TCP-friendliness rate-based control protocols, (2) our desire to evaluate the quality of transmitted video using TCP-friendly protocol, and (3) the lack of current work on establishing links between TCPfriendliness and quality aspects of transmitted video. This paper is organized as follows. In Section 2, we present a brief background and description of the TCPfriendly rate-based control protocols and introduce the protocols used in this work. We describe the experimental design and its rationale in Section 3. In Section 4, we discuss the experiments and subsequently evaluate the performance results. Section 5 gives a conclusion. 2. Background 2.1. TCP-Friendliness TCP-unfriendliness among competing traffic is a major threat to the stability of the current Internet. The classic example of TCP-unfriendliness of the UDP-based applications which do not employ congestion control mechanisms and their negative impact are discussed in [2]. This problem appears because the UDP traffic does not respond to congestion signals which cause TCP flows to back off. The UDP traffic continues to dominate the bandwidth which negatively affect the throughput of the other good network citizen. To overcome this problem, it is crucial for such applications to employ TCP-friendly congestion control mechanisms. In addition, since the streaming multimedia applications are rate-based, it is more appropriate to utilize the ratebased congestion control mechanism. In the rate-based congestion control scheme, the source does not use congestion window (as in window-based TCP) to control the amount of data in the network. Instead, the source directly adjusts its sending rate based on what is appropriate for the applications. The rate-based source constantly monitors overall packet loss in the network while sending data. Monitoring is normally done by means of loss feedback sent by the receiver. The source then calculates the rate and sends the data appropriately. In order to be TCP-friendly, the source s average sending rate must not be higher than that achieved by a TCP connection along the same path. Estimation of the steady state throughput of a long live TCP connection, in the absence of timeouts, as proposed by [8, 131 is given by: k*m TTCP = R*& with k as constant value of 1.22 or depending respectively on the whether delayed or non-delayed acknowledgement type used, M as maximum segment (packet) size, R as round trip time experienced by the connection and 1 as probability of loss [ 101 (during the lifetime of the connection). This simple throughput estimation formulae does assume that the retransmission timeout never happen and packet loss occurs at random. The assumption does not correctly reflect the reality of the current Internet. Retransmission timeout occurs as results of network congestion while packet loss may not appear at random. Padhye [9] suggests that the throughput estimation the should take into account the retransmission timeout and the current advertised window size which results in the following throughput equation 2 below: where M = maximum segment (packet) size; R = round trip time; p = probability of loss event; To = Retransmission timeout and b = 2 (if delayed ACK is used, otherwise equals 1). From this equation we know that the throughput is inversely proportional to the round trip time and the square root of loss probability. Hence we give special attention to these two parameters in this work. TCP-friendliness would results from the implementation of TCP-friendly control protocols. In general there are many classes of such protocols. Some of these protocols such as [3, 151 use explicitly use equation 2 to calculate the TCP-friendly rate while others such as [ 11, 131 implicitly use the more general equation 1. Many of these protocols are designed to work at the sender s side, while at least one protocol [ 121 is implemented at the receiver s side MPEG TCP-Friendly Rate Control Protocol (TFRCP) TFRCP is a rate-based end-to-end congestion control protocol, which is designed for transporting MPEG2 video. It was developed at the Osaka University by Wakamiya et. al. [15]. TFRCP is a sender-based scheme that works by continuously adjusting the source s sending rate based on equation 2. TFRCP protocol is initially implemented in ns simulator version 2.lb5 (and we make it work with the latest version of ns 2.1 b7a). 57

3 TFRCP is source- and loss-based rate control protocol. The sender is to adjust its transmission rate based on observed loss rate and RTT. The adjustment of sending rate to achieve TCP-friendliness is based upon the TCP throughput model described in [9, 31. In TFRCP, packet losses are identified by gaps in the sequence number of the transmitted packet at the receiver module. The receiver sends feedback to the sender at regular intervals. The sender then adjusts the rate accordingly based on this feedback. When the receiver notices the loss, it immediately notify the sender and the sender adjusts its sending rate based on the TCP-friendly equation 2. The TFRCP has been proven in [15] to ensure TCPfriendliness. However, the work relies on results obtained from simulating TFRCP over a hypothetical model consisting FIFO queues. In this work however, we completely use different scenarios (network models). For example, we use two set of network scenarios which utilize RED active queue management algorithm in the routers, instead of FIFO queues. We also use FTP traffic over TCP Sack instead of TCP Reno. We believe that our models are more realistic in representing today's Internet. 3. Experimental Design 3.1. Description of Experiments and Rationale The main objective of this work is to evaluate the performance of the TCP-friendly protocol in transferring highquality stored video. We study the performance in terms of its friendliness behavior in sharing the network resources such as bandwidth and explore the transmission behavior of the MPEG2 data. We wish to investigate the possibility that by using the TCP-friendly rate control protocol and using the optimal gateway configuration, we can perform highquality application-level video transmission without undermining fairness towards the competing connections. For this purpose, we evaluate the performance using three important metrics: 1) Friendliness, 2) Rate-uniformness and 3) Packet loss count. We explain these metrics as follows: Friendliness We measure the throughput of each TFRCP and TCP flows respectively and calculate the average bottleneck bandwidth share of each flow based on their average throughput. We determine the degree of friendliness of the TFRCP protocol by comparing their average bandwidth share against that of the TCP flows. Simply stated, we calculate the friendliness ratio, F, as follows[9, 111: (3) where T, is the average throughput of the TCP-friendly flows and Tt is the throughput of the TCP flows. Having obtained the value of F,, we use our friendliness characterization scheme proposed in [6] to evaluate the friendliness. Rate-uniformness We explore the transfer rate variation to understand the inherent network fluctuations. This criteria is important since big variation in transfer rate may cause unstable quality of the video application at the receiver side. For this purpose, we propose a metric called rate-uniformness defined as follows: Definition 3.1.2: Rate-uniformness. The degree of uniformity of means of a flow's transmit and the receive rates, evaluated using the rate mismatch index 6 such as 6 = COV(F,t,F,') (4) - - where F: : mean transmit rate, : F,T : mean receive rate. The higher value of 6 shows lack of rate-uniformness of the flows, which is an undesired characteristic of video transmissions. Packet loss count We measure the amount of packet loss for each TFRCP flows. The higher the amount of packet loss during the entire transmission would imply that the video is received at the receiver side at a relatively lower in quality Scope of Experiments Our performance investigation of TCP-friendly video transfer involves transmitting the high-quality MPEG2 video trace obtained from [ 141 over the simulated network scenario that would produce the best and the worst friendliness results. Our best and worst case scenarios uses the sets of respective configuration parameters determined in our related paper [5]. For each experiment, we evaluate the metrics of TCP-friendliness, rate-uniformness and packet loss. The TCP-friendly protocol sources used for transporting the MPEG2 video traffic competes against the TCP Sack sources. We use TCP Sack [3] as our choice of TCP implementations. TCP Sack is designed to overcome the problem of poor performance when multiple packets are lost from one window of data. It allows the TCP sender to intelligently transmit only those segments that have been lost. In addition, it decouples the determination of which segment to transmit from the decision about when it is safe to re-send 58

4 RED Parameters RED buffer size (packets) Min-max thresholds Best Case Worst Case Max drop probability max(p) I 1/10 I 1/1 Oueue weigh factor w(a) I I 0.02 Table 1. RED parameter settings for video transfer experiments Figure 1. Simulation topology for MPEGP experiments a packet. The work in [8] explore the desirable performance results of the similar TCP-friendly protocol when competing with TCP Sack in terms of TCP-friendliness Simulation Scenario We use the simulator ns-2 [l] from the VINT project at U.C. BerkeleyLBNL to perform our simulation experiments. The simulator is event-driven and runs in a nonreal-time fashion. In ns-2, the user defines arbitrary network topologies that composed of nodes, routers, links and shared media. A rich set of protocol objects can then be attached to nodes, usually as agents. For this simulation, we use TCP Sack, as well as the simulated TFRCP protocol. Correspondingly, the user may choose between various types of applications. In this simulation, we use the FTP application for the TCP agent to represent the conventional real-world TCP application. We configure the routers using Random Early Detection (RED) policies using parameters described in Section 3.4. Packet losses are simulated by packet drops at overflowed router buffer. Figure 1 illustrates the simulated scenario used in our experiments. We use 2 sets of (n+l) competing sources, where O<n<m. One set of these sources transmit the MPEG2 video traces into the network, using the TFRCP congestion control protocol. The other set of sources are running as TCP agents with TCP Sack, transmitting continuous FTP data. The TCP-friendly source TF(s,) sends data to (and receives acknowledgments from) the receiverhink agent TF(r,). Similarly, TCP source TCP(s,) sends data to (and receives acknowledgments from) TCP(r,) receiver agent Simulation Parameters A fair evaluation can only be achieved with careful selection of simulation parameters. We have used similar parameter values for all the flows wherever possible. The intermediate routers are connected by a bottleneck link with bandwidth set to 155 Mbps (OC-3 transfer rate) and link delay of 20 ms. The capacity of the bottleneck bandwidth is carefully chosen to enable the transfer of the MPEG2 traffic. The traffic from all sources are sharing this bottleneck bandwidth. The TCP flows are FTP sessions and have unlimited data to send. Side links connecting to the bottleneck link have bandwidth of 10 Mbps with 6ms delay factor. The routers have a single output queue for each attached link, and uses RED active queue management. All simulations were run long enough until they achieved steady state behavior. In our work, we use TFRCP to transport MPEG2 video data [14]. The data consists sequence of 150 frames of 704x480 pixels with 30 different quantization levels. The video frame rate is framehecond. In order to avoid video quality fluctuation, TFRCP utilizes rate control interval of 32 times as long as the smooth RTT. Table 1 summarizes the RED parameters used in this work. 4. Results and Discussions We have conducted a substantial number of experiments to study the performance of the TCP-friendly video transfer. The following subsections present our results for these different experiments. All the results, where appropriate are obtained using level of confidence of 95% TCP-friendliness In our experiments for evaluating TCP-friendliness property, we observed that, in general both test cases, i.e. the Best Case and the Worst Case demonstrate that TFRCP is capable of behaving in a friendly manner when competing with TCP Sacks. Figure 2 and Figure 3 show the results of these experiments. It can be seen from Figure 3 that TFRCP flows receive less bottleneck bandwidth as compared to that of their TCP counterparts. The average friendliness ratio for all the flows is 0.85 which means that TFRCP flows obtain about 45% of the bandwidth. One might conclude that this is a favorable result according to the TCP-friendliness definition [SI 59

5 5w mean sending rate 4M mean r"bn1"g rats I so 70 eo Totel Flows 250 t 1 Figure 2. TCP friendliness of the Best Case scenario Figure 4. TFRCP with Best Case scenario I eo Total Flown I Figure 3. TCP friendliness of the Worst Case scenario but it is surely unfair for the TFRCP flows. In contrast, we believe that the results of the Best Case (as in Figure 2) scenario is better and more desirable. This is so because on average TFRCP flows are capable to obtain greater amount of bottleneck bandwidth (i.e. about 48%). In addition, some TFRCP flows are capable of getting slightly bigger bandwidth share, but we believe that the situation is not detrimental to the TCP flows Rate-uniformness Table 2 compares the rate-uniformness metrics for both of the cases. These results are obtained by averaging all the individual transmit and receive rates of 40 TFRCP flows. For the purpose of comparison, we also perform similar experiment using the same amount of TCP Sack sources that send the same video trace over the network (i.e in the absence of the TCP-friendly sources). The later experiment is also to show the ineffectiveness of transmitting video traffic over TCP. Figure 4 and Figure 5 show the performance of both TFRCP and TCP using the Best case scenario. It is very obvious to see that rate fluctuation in the TCP cases is higher than those of the TFRCP cases. Such rate fluctuation is generally undesired when transmitting video, making TCP is unpopular for this cause. In contrast, both TFRCP cases demonstrate their uniformness (i.e. smoothness) when transmitting video traffic. Although the Best Case scenario obtained less effective transfer rate than its Worst Case counterpart, it obtains 50 c 1: 4 Figure 5. TCP with Best Case scenario lower value of rate mismatch index 6. This indicate that its transfer rates are relatively more uniform than that of the Worst Case scenario. The higher and lower rates of both cases is the result of the flows' attempt to obtain the bottleneck bandwidth. In the Worst Case scenario, the flows are more aggressive obtaining bandwidth at the expense of bigger rate mismatch. In the Best Case scenario, such attempts are less fruitful possibly due to the stringent RED configurations Packet Loss Count We also measure packet loss count in our experiments. The results of our measurement is presented in Table 3. From the result, the TFRCP flows transporting the video data over the Best Case scenario obtain relatively less number of packet losses compared to the case of using the Worst Case scenario. We can therefore conclude that by having Experiments TFRCP with Best Case Scenario TCP with Best Case Scenario TCP with Worst Case Scenario Table 2. Rate-uniformness of the Best and Worst Case scenario 60

6 I ExDeriments 1 Best Case 1 Worst Case 1 Mean Packet Loss Count I 157 I 194 Table 3. Packet loss amount of the Best and Worst Case scenarios lesser number of packet losses, the Best Case scenario is capable to provide a platform for a better video transfer. 5. Conclusions In this work, we conducted a simulation-based performance evaluation of TCP-friendly video transfer using carefully selected network scenarios. In addition to exploring the TCP-friendliness and packet loss properties of the TFRCP, we have defined and used a new performance metric called the rate-uniformness metric to study the degree of mismatch in the video transfer rate to suggest the delivered quality video traffic at the receiver side. Using these metrics, we evaluate the performance of the best and the worst network scenarios determined in our previous work [5]. From our results, we can conclude that in general, TFRCP is capable of transporting high quality video while preserving video quality and TCP-friendliness behavior. The results also support our claim in [5] that proper parameterization of RED router can further support TCP-friendly protocol in transferring video and other multimedia traffic in the Internet. Our future works include exploring the possibility of using the rate-uniformness metric and mean loss packet count to evaluate quality of actual video transmission on a network testbed and compare our results with the perceived quality at the receiver s end. 6. Acknowledgements The authors wish to thank Dr. Naoki Wakamiya of Osaka University for discussions and assistance on the MPEG- TFRCP protocol. We also wish to thanks Dr. Karim Djemame, Somnuk Puangpronpitag, Riri Fitri Sari and Paavan Mistri for their useful discussions and contributions during the preparation of this paper. References [l] L. Breslau, D. Estrin, K. Fall, S. Floyd, J. Heideman, P. Huang, S. McCanne, K. Varadhan, Y. Xu, and H. Yu. Advances in Network Simulation. IEEE Computer, pages 59-67, May [2] S. Floyd and K. Fall. Promoting the Use of End-to-End Congestion Control in the Internet. IEEE/ACM Transcactions on Networking, May [3] S. Floyd, M. Handley, J. Padhye, and J. Widmer. Equationbased Congestion Control for Unicast Applications. In Proc. of ACM SIGCOMM2000, volume 30 of Computer Communication Review, pages 43-56, Stockholm, Sweden, September ACM SIGCOMM, Association of Computing Machinery. [4] S. Floyd and V. Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, 1: , August [5] S. Hassan and M. Kara. Effects of RED Dynamics on TCP- Friendliness of Rate-based Control Protocol. In P. Pacyna and Z. Papir, editors, Proc. of Protocols for Multimedia Services (PROMS2000), pages , Krakow, Poland, October IEEE. [6] S. Hassan and M. Kara. Simulation-based Performance Comparison of TCP-Friendly Congestion Control Protocols. In Proceedings of the 16th Annual UK Performance Engineering Workshop (UKPEW2000), Durham, UK, July [7] S. Jacobs and A. Eleftheriadis. Streaming Video using TCP Flow Control and Dynamic Rate Shaping. Journal of Visual Communication and Image Representation, Special Issue on Image Technology for Word- Wide- Web Applications, 9(3): , September [8] J. Mahdavi and S. Floyd. TCP-Friendly Unicast Rate-Based Flow Control. Technical note sent to the end2end-interest mailing list, January [9] J. Padhye. Towards a Comprehensive Congestion Control Framework for Continuous Media Flows in Best Effort Networks. PhD thesis, University of Massachusetts Amherst, March [lo] J. Padhye, J. Kurose, D. Towsley, and R. Koodli. A Model Based TCP-Friendly Rate Control Protocol. In Proceedings of IEEE NOSSDAV 99, Basking Ridge, New Jersey, June [ll] R. Rejaie, M. Handely, and D. Estrin. RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet. In Proceedings of IEEE Infocom 99, New York, NY, March [12] I. Rhee, V. Ozdemir, and Y. Yi. TEAR: TCP Emulation at Receivers - Flow Control for Multimedia Streaming. Technical report, NCSU Department of Computer Science, North Carolina State University, Raleigh, April [I31 D. Sisalem and H. Schulzrinne. The Loss-Delay Adjustment Algorithm: A TCP-friendly Adaptation Scheme. In Proc. of International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), Cambridge, England, July [14] N. Wakamiya, M. Murata, and H. Miyahara. MPEG2 video trace. November [ 151 N. Wakamiya, M. Murata, and H. Miyahara. On Video Coding Algorithms With Application Level QoS Guarantees. Computer Communication Journal, 23( 14-15): , August [16] I. J. WGl1. The Moving Picture Experts Group (MPEG). June