How To Make Streaming Traffic Fair

Transcription

1 Streaming Traffic Fairness Over Low Bandwidth WAN Links Rushabh Doshi Department of Computer Science Stanford University Pei Cao Cisco Systems, Inc. San Jose, CA Abstract Despite the rising popularity of streaming media in corporations, there is little understanding of how streaming traffic interacts with other corporate network traffic over low-bandwidth WAN links. We used simulations to study the issue, and found that the buffer-based rate adaptation algorithms used in popular streaming applications is effective at making the streaming traffic behave in a fair manner, even when UDP is used as the transport. The congestion control is affected by the buffer size: small buffers make the streaming application timid and large buffers make it more aggressive. However, regardless of the buffer size, the streaming traffic can be adversely affected by multi-session TCP traffic such as web traffic, and other QoS mechanisms are needed to preserve streaming quality in this case. 1. Introduction Demand for applications such as e-learning and communications is increasingly driving the use of streaming media in corporate environments. Powered by ever improving media players and servers, streaming media reduces the cost of corporate training and improves the effectiveness of communications within the corporation. Streaming media is particularly effective for enterprises with many geographically dispersed branch offices connected to the main office via a low bandwidth WAN link. A stream-splitting device, such as Cisco Systems Content Engine, is typically installed at the gateway for each branch office. This device splits one multimedia stream from a corporate data center into multiple copies going to different clients in the branch office. The device enables streaming over the WAN: only one stream needs to travel through the bottleneck link. The WAN link is shared by other programs and applications. Some of the traffic going over the WAN link is business critical (such as data updates) while other traffic is not (such as web surfing). The interaction between such traffic and streaming media traffic has previously not been studied in detail. Streaming traffic is different from other well-studied forms of traffic such as HTTP or traffic. Streaming sessions typically 1) have long durations 2) may run either over UDP or TCP and 3) are characterized by continuous rather than bursty traffic patterns. Streaming applications today can adapt to changing traffic conditions by making course grained adjustments to their bandwidth consumption. In this paper, we use simulations to study how streaming media traffic competes with other TCP traffic in a limited bandwidth environment. Our simulations model the existing streaming players and servers based on our experience implementing streaming media servers and our observations of player behavior. 2. Internet Streaming Applications There are three major Internet streaming systems in use today: Windows Media Technology (WMT) from Microsoft [1], RealNetwork streaming technology from RealNetworks [2], and QuickTime from Apple [3]. They all share the following characteristics: The underlying transport protocol can be UDP, TCP, or HTTP (one can treat HTTP as just another variant of TCP). The client uses a buffer to smooth out temporary variations in packet arrival rate. The streaming server always attempts to transmit the streaming media data at a constant bit rate, i.e. the encoded bit rate of the streaming media. It typically sends a block of data, waits for a fixed duration, then sends another block of data. When available bandwidth changes, the player selects among a fixed set of bit rates for the streaming media, and the server serves the selected stream. In other words, the streaming media server is a multi-cbr source. Unlike TCP based applications, it cannot take advantage of the available bandwidth in a continuous fashion; it can only switch among a set of constant bit rates. The selected bit rate is determined by the player which typically uses the data arrival rate to determine when to upgrade or downgrade the stream. We model the behavior of the streaming application based on these characteristics. 3. Evaluation Methodology We use simulations to study the interaction of streaming and other types of traffic. For this purpose we use the NS-2 [4] network simulator (henceforth referred to as ns) Network Topology and Simulations The network topology that was used to carry out the simulations is displayed in Figure 1. The multimedia streaming server and client simulate one streaming session while the

2 or Web Server Mbps Streaming Client Fig. 1. Switch 128 kbps Switch Mbps Mbps Mbps Streaming Server TCP background traffic streaming traffic Sink for or HTTP traffic Simulated network topology /Web server and client are used to generate competing traffic. Traffic from only one streaming session travels through the bottleneck bandwidth similar to a real world scenario where this would be accomplished by a stream splitting device. The servers and the clients are connected to their respective switches through Mbps links. The two switches are connected using a WAN link which represents the network bottleneck. We run two sets of simulations by varying the WAN link capacity: 128Kbps for one and 512 Kbps for the other. The router connected to the link uses drop-tail in the case of buffer overflow (i.e. network congestion) Models of Streaming Server, Player and the Media In our study, we chose a 2 minute video encoded in a Multiple Bit Rate (MBR) format. The encoded bit rates are 1kbps, 22kbps, 85kbps, 1kbps, and 2kbps. This is a typical video stream for applications such as Windows Media Player. The streaming server sends data at the bit rate selected by the client. The client maintains a buffer into which data is put upon arrival from the network, and from which data is pulled for rendering at the constant bit rate of the selected stream. The buffer size is fixed. In our simulation, we experiment with four buffer sizes: 25KB, 5KB, 25KB and 5KB, corresponding to roughly less than 1 second, 1 to 2, 7 to 8, and 15 to 16 of buffering for our example streaming media. The client initiates a downgrade of the stream bit rate when the buffer runs dangerously low. This occurs when the data arrival rate cannot keep up with the data consumption rate. In our simulations, we vary the threshold at which the client initiates the downgrade and experiment with three values: %, 7% and % empty. Putting it differently, the client decides to downgrade the stream when the amount of arrived data lags the expected data by the size of Ö, where B is the buffer size, andöis the degree of under-run in the buffer. The client decides when to upgrade based on the stability of the data arrival rate into the buffer. Lacking any other feedback mechanism, the only sign of stability is when data appear to arrive in the buffer smoothly at the expected rate. This is taken as an indication of spare bandwidth in the network. The client maintains a smooth running average of the buffer, and when that average remains more or less constant over a certain period of time, the client decides to upgrade the bit rate. The upgrade algorithm is tuned in such a way that the client requests a bit rate upgrade to the server if there is negligible packet loss for about 45 to. It must be noted that after the client has triggered either the upgrade or the downgrade, there is still data in the client s buffer that must be viewed at the old bit rates. The direct result of this is that when upgrading, the server starts streaming at a higher bit rate before the client starts consuming at that bit rate; this leads to an increase in the amount of data stored in the client s buffer. One final note is that during session setup, the client and server typically employ techniques such as packet-pair [5] to detect the bottleneck bandwidth, and the client starts by choosing the highest possible bit rate below that of the packet-pair estimated bandwidth, instead of the absolute highest possible bit rate. 4. Results We seek to answer the following questions: Can streaming traffic, running on top of UDP or TCP, give competing traffic their fair share of the network bandwidth? Are there cases where the competing traffic significantly deprives the streaming application of its share of the network bandwidth and leads to poor streaming quality? When the available bandwidth for streaming traffic falls between two pre-encoded bit rates, can the streaming application still fully utilize the bandwidth available to it? Clearly, answers to these questions may depend on whether the underlying transport is TCP or UDP, the buffer size and the under-run ratio to trigger a downgrade. In Figures 2 5 presented below, we plot two lines for the streaming application. The line represents the bandwidth utilized by the multimedia stream. The MM Server streaming rate is the bit rate of the stream that the server is sending, i.e. the bit rate of the stream that the client selected Streaming over TCP We first study the interaction between an session and a streaming session based on TCP. Figure 2 shows the results over a 128Kbps bottleneck link. Not surprisingly, when two TCP sessions are interacting with each other, they tend to share bandwidth fairly. However, the nature of the two TCP sessions are different here: the session can take advanatge of whatever spare bandwidth there is, while the streaming session can only

3 (a) 5kB buffer, 128Kbps link (b) 5kB buffer, 128Kbps link Fig. 2. Bandwidth utilization graphs of TCP-based streaming competing with an session. The represents the bandwidth utilized by the session. We select two representative graphs from our simulation results. The graphs vary the buffer size but have the same under-run ratio of 7%. Results using other under-run ratios are similar. The full results can be found at [6]. choose from a fixed set of bit rates. Figure 2 shows that when the buffer size is large (25KB or higher), the streaming session can effectively take advantage of its fair share of the bandwidth, alternating between 22Kbps and 85kbps to maximize the quality of user experience. However, when the buffer size is small, the streaming application yields too quickly. Similar effects are observed when varying the buffer user-run threshold; higher threshold enables the streaming session to absorb the bandwidth available to it. Streaming over TCP, however, appears unable to cope with an onslaught of Web traffic. Web traffic is simulated using ns s built in model [7]. The web traffic model emulates a number of users issuing HTTP/1. requests to a set of web servers. Each request is essentialy a page which contains upto five web objects - such as HTML files, GIF and JPEG images. The size of these objects is modeled using a Pareto distribution with an average of 12KB. The average time interval between two page requests is about 3 [7]. Figure 3 shows the results of streaming traffic competing with ½ Web traffic of about ten users over the 128Kbps link. The ten users waits for an average of 3 between page requests. This is not an aggressive web traffic model; the average bandwidth needed would be: ½¼users objects objects ¼ download time which has an upper bound of 1Kbps. Unfortunately, by and large, the streaming application cannot keep its share of the link bandwidth, and streams at the lowest or secondlowest bit rates most of the time. In other words, the streaming quality is poor. The result is the same regardless of the buffer size, although large buffers help a little bit. page ½¾Ã The reason, we believe, is that the Web traffic consists of many TCP session. In the worst case, when all 1 users are issuing requests, there are on average 5 HTTP sessions competing with the streaming traffic. While TCP protocols achieve fairness between two TCP sessions, it does not guarantee fairness between two applications when one uses many TCP sessions Streaming over UDP Next we study the interaction between streaming traffic transported over UDP and or web traffic. Figure 4 shows how UDP-based streaming interacts with an session over a 128Kbps bottleneck link. The streaming application uses buffer sizes of 5KB and 5KB. The results show that when the buffer size is 5KB or less, the UDP-based streaming is relatively fair: it yields to the traffic in ways similar to that of TCP-based streaming. As the buffer size increases, however, the UDPbased streaming becomes more aggressive. At a buffer size of 5KB it almost never yields to traffic. To understand why, one should note that UDP has no congestion control and will always transmit data whenever the application wants it to. The application, however, does the congestion control by downgrading to a lower bit rate when the amount of under-run goes exceeds the threshold. Consequently, if the under-run threshold is small, the application is sensitive to competing traffic and yields in a manner similar to TCP. Conversely, if the under-run threshold is large, the application is aggressive and does not yield as TCP would. In our simulation, the behavior change seems to occur between an under-run threshold of KB and 15KB. The UDP session is also partly helped by TCP s reaction to packet loss. In our simulations, we use a TCP Reno implementation. Since the window size is halved every time a packet loss is detected, TCP Reno reduces the window size rapidly when there are multiple packet losses. This can be seen in the periodic sudden dips in the bandwidth. When this happens, the UDP session is able to take advantage of the spare capacity in the network and transmit more packets, reducing the under-run in the buffer. We also experimented with a TCP Vegas implementation. While TCP Vegas does not experience the periodic sudden dips in

4 (a) 5kB buffer (b) 5kB buffer Fig. 3. Bandwidth utilization graphs of TCP-based streaming competing with web traffic. The background web traffic line shows the bandwidth consumed by the web traffic. We select four representative graphs from our simulation results. The graphs vary the buffer size but have the same under-run ratio of 7%. The full results can be found at [6] (a) 5kB buffer, 128Kbps link (b) 5kB buffer, 128Kbps link Fig. 4. Bandwidth utilization when multimedia is streamed over UDP with competing traffic. The graphs vary the buffer size but have the same under-run ratio of 7%. Results using other under-run ratios are similar. The full results can be found at [6] bandwidth as in Reno, it does not obtain a higher average bandwidth for because its delay-based algorithm is already yielding to the UDP traffic. (Full results may be found at [6]) Figure 5 shows the results of UDP-based streaming competing with Web traffic, under the exact same setup as in Figure 3. Not surprisingly, larger buffers make UDPbased streaming perform better. With large buffers such as 25KB and 5KB, UDP-based streaming clearly holds onto its share of the bandwidth better than TCP-based streaming, delivering higher quality of streaming to the client. Clearly, the setting of the buffer size for UDP-based streaming can be used as a kind of QoS mechanism. This flexibility is only available for UDP-based streaming. If the buffer size is set small, the streaming traffic yields to other traffic; if the buffer size is set large, the streaming traffic will maintain its quality despite other competing traffic. This mechanism can be implemented in the stream-splitting device at the branch office gateway. The results above were obtained by carrying out simulations over a 128Kbps bottleneck link. We also simulated a higher capacity 512Kbps bottleneck link. The results from that simulation are similar and can be obtained from [6] Summary Through our simulations, we found that both streaming over TCP and streaming over UDP can behave fairly due to buffer-based rate adaptation, as long as the buffer size is set appropriately. For TCP-based streaming, it is better to bias toward larger buffers as they help the streaming application utilize available bandwidth. For UDP-based streaming, the buffer size can be used as a priority or QoS scheme, with small buffers making the traffic more friendly to competing traffic, and large buffers better at maintaining the quality of the stream when there is competing traffic. Furthermore, if a corporation decides to use TCP as the streaming protocol, then for important streaming events

5 (a) 5kB buffer (b) 5kB buffer Fig. 5. Bandwidth utilization graphs when multimedia is streamed over UDP with competing web traffic. We select two representative graphs from our simulation results. The graphs vary the buffer size but have the same under-run ratio of 7%. The full results can be found at [6] it needs to use network QoS mechanisms to protect the quality; otherwise applications that use many short TCP sessions, such as Web traffic, will degrade the quality of the stream. 5. Related work There have been many studies on techniques for quality adaptation for congestion control in streaming applications [8] [1], for example, the layered encoding approach [9]. In this paper we look at the existing algorithms embedded in commercial streaming applications as is and try to understand their implications rather than investigate techniques for improving quality adaptation. There have also been many studies on TCP-friendly congestion control algorithms for UDP for streaming applications [11] [13], some of which have the property of being slowly responsive to congestion situations [14]. Our work differs from these studies by investigating the efficacy of the current scheme employed by the exiting streaming media players. Current players can use either TCP or UDP as the underlying transport. Hence, our focus is not so much on TCP-friendliness, but rather on the circumstances under which streaming traffic may adversely affect other traffic, and other traffic may adversely affect streaming traffic. 6. Conclusion and future work We show that the perception that streaming multimedia over UDP is unfair to other data streams is not true. Buffer based rate adaptation mechanisms, employed in today s streaming media players, force streaming traffic to behave in a fair manner with regard to other competing traffic. However, streaming traffic can be adversely affected by bursty, aggressive web traffic, particularly when TCP is used as the underlying transport. In these cases, other QoS mechanisms such as DiffServ should be used. In the future, we hope to validate our simulations further by implementing the simulated setup in the lab and carrying out further testing with real multimedia streaming servers and clients. We would also like to validate our hypothesis that other QoS mechanisms such as DiffServ would indeed make way for a better user experience and preserve network fairness at the same time. Acknowledgments We are grateful for the helpful comments by Ted Kremenek, Priyank Garg and Milap Shah. References [1] Microsoft windows media. [Online]. Available: [2] Realone player. [Online]. Available: [3] Quicktime. [Online]. Available: [4] Network simulator ns-2. [Online]. Available: [5] J. Bolot, Characterizing end-to-end packet delay and loss in the internet, Journal of High Speed Networks, vol. 2, no. 3, pp , [6] Full simulation results. [Online]. Available: [7] A. Feldmann, A. C. Gilbert, P. Huang, and W. Willinger, Dynamics of IP traffic: A study of the role of variability and the impact of control, in Proceedings of ACM SIGCOMM, 1999, pp [8] S. Jacobs and A. Eleftheriadis, Real-time dynamic rate shaping and control for internet video applications, in Proceedings of Workshop on Signal Processing, [9] R. Rejaie, M. Handley, and D. Estrin, Quality adaptation for congestion controlled video playback over the internet, in Proceedings of ACM SIGCOMM, [1] R. Rejaie, H. Yu, M. Handely, and D. Estrin, proxy caching mechanism for quality adaptive streaming applications in the internet, in Proceedings of IEEE Infocom 2, 2. [11] D. Bansal and H. Balakrishnan, TCP-friendly congestion control for real-time streaming applications, MIT Technical Report, MIT- LCS-TR-6, 2. [12] M. M. Naoki, Mpeg-tfrcp: Video transfer with tcp-friendly rate control protocol. [13] N. Feamster, D. Bansal, and H. Balakrishnan, On the interactions between layered quality adaptation and congestion control for streaming video, in 11th International Packet Video Workshop, 21. [14] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, Dynamic behavior of slowly-responsive congestion control algorithms, in Sigcomm, 21.