VIDEO STREAMING OVER SOFTWARE DEFINED NETWORKS WITH SERVER LOAD BALANCING Selin Yilmaz, A. Murat Tekalp, Bige D. Unluturk College of Engineering, Koç University, 34450 Sariyer, Istanbul, Turkey ABSTRACT Software Defined Networking is a promising Internet architecture to deliver multimedia with end-to-end quality of service (QoS) since it enables optimal dynamic management of network resources and on-demand QoS provisioning by a network operator. We propose a framework for server load-balancing over a single-operator OpenFlow network to improve the quality of service levels of video streaming services. We design a new OpenFlow controller application for dynamic server load balancing by continuous monitoring of load of each video server and dynamic rerouting of clients to alternate servers with lower loads when an overload condition is detected. The proposed controller application is implemented on top of an open source OpenDaylight controller. Our results show that the proposed load-balancer improves the quality of streaming video experienced by end-users, and OpenFlow provides a powerful framework to provide video services with end-to-end quality of service over the future G Index Terms Software defined networking (SDN), OpenFlow networks, video streaming, QoS, load balancing 1. INTRODUCTION Over the past decade, the Internet Engineering Task Force (IETF) has explored several Quality of Service (QoS) architectures over the current Internet, but none has been truly successful and globally implemented. This is because QoS architectures such as IntServ [1] and Diffserv [2] are built on top of the current Internet s completely distributed hop-by-hop routing architecture, lacking a broader picture of overall network resources. Although tunneling with MPLS [3] provides a partial solution, it lacks real-time reconfigurability and adaptivity. As a result, in the current Internet, methods to provide some quality of service is often addressed at the application layer but without end-to-end service level guarantees. In contrast, Software Defined Networking is a promising Internet architecture to deliver multimedia with end-to-end quality of service (QoS) since it enables optimal dynamic management This work has been funded by TUBITAK Project 113E254. A.M. Tekalp also acknowledges support from Turkish Academy of Sciences (TUBA). Fig. 1. OpenFlow architecture. of network resources and on-demand QoS provisioning by a network operator. OpenFlow is a Software Defined Networking standard, in which the control and data forwarding layers of routing are decoupled [4]. OpenFlow started as an open source project which will offer a programmable and completely open network to test new Internet concepts such as routing and security that cannot be tested otherwise on the current Internet platforms [5]. The control function of routing is shifted to a central unit, called a controller, while the forwarding function remains within the routers, also called forwarders. OpenFlow enables defining different types of flows where different set of rules can be associated with each predefined flow. The controller makes routing decisions on a per-flow basis, and updates forwarding tables, called flow tables, associated with each flow to inform the forwarders how to direct traffic flows as depicted in Fig.1. Currently, OpenFlow is deployed on several university campuses including Stanford, Georgia Tech and Princeton. Commercially, Google started to use Open- Flow to manage its data centers [6]. We believe that Open- Flow will be adopted by large network operators and ISPs in the near future to manage communication networks for the features it supports including network virtualization. Decoupling of the control and forwarding functionalities of routing and providing controller capabilities to manage overall network resources (within a single domain or operator) make OpenFlow an effective platform to provide video streaming services with end-to-end QoS. With the OpenFlow Controller as the network operating system, applications on top of the controller can be written to manage end-to-end QoS. One of the earliest intra-domain single controller Open- Flow QoS applications is our OpenQoS application, which enables dynamic rerouting of QoS flows over a single op-
erator network when network congestion is detected [7]. It poses dynamic QoS routing as a constrained shortest path problem and proposes a real-time solution. An alternative approach to add QoS support to OpenFlow has been proposed in the European project OFELIA [8]. It is possible to extend dynamic QoS solutions to video services across multiple domains or operators by defining extensions to OpenFlow to allow controller-to-controller signaling/negotiation interfaces and software defined Internet exchanges [9]. This paper proposes a new server load balancing controller application to improve the quality of service for video streaming over single operator OpenFlow networks in case of server overload. Server load balance is achieved by continuous monitoring of the load of each server and dynamically redirecting ongoing or new service requests to available servers in such a manner that the end user experiences the lowest delay and distortion when one or more servers are overloaded. Content distribution networks (CDN) are also capable of serving content to end users with high availability and high performance. However, our SDN-centric solution has the advantage of providing a global view of the network to all clients at all times. This network information enables client applications to choose the most appropriate server according to their metrics. Our design is implemented over the open source OpenDaylight controller and test results show that load-balancing with OpenFlow significantly improves the video quality experienced by the end users when server overload occurs with introducing a slight delay. The proposed load-balancing application complements our previous OpenQoS application [7] such that the combined system can now provide video streaming with end-to-end QoS in case of both network congestion and server overload. The organization of the paper is as follows. Section 2 presents the design principles of the OpenFlow load-balancer application. Section 3 describes the implementation of the proposed load balancer application and the test scenarios. Section 4 discusses the results showing the performance of the load-balancer in terms of its effect on video quality experienced by end-users. Finally, Section 5 gives concluding remarks. 2. OPENFLOW CONTROLLER APPLICATION DESIGN FOR SERVER LOAD-BALANCING The proposed load-balancer design aims at efficient usage of video server cloud resources to improve the user experience of video quality and delay at the client side. The controller application manages two basic functions, namely server load monitoring and server selection/flow updating: Server load monitoring: This function continuously checks whether the server load is above a predefined capacity threshold. Server selection and flow updating: This function is invoked when an overload condition is detected. It selects the server with the least cost from the server cloud. Then, the controller application will delete the old routing tables and will push new flow entries to the switch. Server load monitoring is achieved by monitoring the bandwidth usage of the link between the servers and the switch connecting them to the rest of the network. We obtain the byte counts passing through the link within a time interval and calculate the bandwidth usage of that link by dividing the byte count by the time interval. A congestion event occurs if the bandwidth usage of the link exceeds a predetermined capacity threshold. Note that we also employ a counter for counting non-congestion events after congestion detection. This is because there may be momentary differences in the link congestion status which may lead to wrong decisions. See Appendix - Algorithm 1 for the pseudocode of server load monitoring. When server overload is detected, the controller application needs to select a new streaming server from the video server cloud. There are two significant factors that affect video server selection, which are the packet loss measure of the link connecting the server to the client and the delay/delay variation depending on the geographical location of the server. Therefore, the cost metric of a link (i,j), which is connecting the nodes i and j, is defined as follows: c ij =(1 β)d ij + βp ij for 0 β 1, (i, j) A where β is a scaling factor, A is the set of the links between a server and the client, d ij and p ij are the delay variation and the packet loss measure of the link (i,j), respectively [10]. The delay variation is found by taking the first derivative of the delay and time stamping is used to measure the delay [11]. The packet loss measures, p ij of the links are calculated with the following formula { Qij+T ij B ij Q p ij = ij+t ij, B ij <Q ij + T ij 0, B ij Q ij + T ij where Q ij, T ij and B ij are the QoS traffic, best effort traffic and the total bandwidth capacity on the link (i,j), respectively [10]. The summation of the first two variables, namely Q ij and T ij, is the bandwidth usage on the corresponding link (i,j) and found with the server load monitoring functionality of the OpenFlow controller. The bandwidth of the link, namely B ij, can be a predetermined value or it can be found experimentally. After the cost metrics are calculated for each route connecting the client to each server, the least cost server is determined to be the next streaming server for the client. Once a new server is selected, the new route from the server to the client is found with the LARAC algorithm as described 723
Fig. 2. Schematic of the implemented system. in our previous work [10]. Then, the old flows are deleted and new flow tables are pushed to all switches along the new route. This is realized with the flow updating task, which is included in the second function of the OpenFlow controller. The second function is server selection and flow updating as described in this section and the pseudocode for this function can be seen in Appendix - Algorithm 2. 3. IMPLEMENTATION AND TEST SCENARIOS The two basic functions of our controller application, the server load monitoring and server selection/flow updating, have been implemented over the open source OpenDaylight controller over a small OpenFlow test network that we set up in our laboratory. To test our OpenFlow controller application, we used an implementation setup illustrated in Fig.2. Two servers (Server 1 & Server 2) are connected to the OpenFlow switches. The OpenFlow switches are controlled by a distinct controller computer where our OpenFlow controller code runs and manages the switches. To simulate the load on a server, another computer is connected to the OpenFlow switch called traffic loader in our setup. On the other end of the network, a client is connected to the OpenFlow switch to observe the performance of video streaming under the overload condition. To compare the performance of the load-balanced operation and no load-balanced operation of the setup, we realized two scenarios given as follows. Scenario 1 Streaming Video From a Fixed Server Initialization: Client streaming video from Server 1 8MB additional traffic on Server 1 for 20 sec at t =10sec No change of routes, Loss of video on the client End of Video is back at the end of the traffic at t =30sec 8MB additional traffic on Server 1 for 20 sec at t =40sec No change of routes, Loss of video on the client End of Video is back at the end of the traffic at t =60sec Scenario 2 Load-balancing OpenFlow controller Initialization: N servers delivering the same video Client streaming video from Server 1 8MB additional traffic on Server 1 for 20 sec at t =10sec The route from Server 1 to the client is switched, now Server 2 is delivering video to the client Loss of video on the client only during the route switching Video starts to stream from Server 2 at t =16sec End of Video is continued to stream from Server 2 8MB additional traffic on Server 1 for 20 sec at t =40sec Operation Video is continued to stream from Server 2 (No loss of video) End of Video is continued to stream from Server 2 In the first scenario, there is no OpenFlow controller. Therefore, it realizes the current network scenario. However, in the second scenario, an OpenFlow controller is introduced to obtain better results. In our experimental setup, we had only 2 servers which are streaming video. There is only one assumption which is that server 2 is not loaded with additional traffic when server 1 is loaded. This way, we guarantee that there is a server that can stream the video. If both servers are loaded at the same time, video will be lost as in the first scenario. In this setup, all switches run the OpenFlow protocol and we use the OpenDaylight controller which is an open source OpenFlow controller. Furthermore, the network is monitored using FlowVisor which shows all OpenFlow switches and the data flow on the links. The two servers can be differentiated by the OpenFlow switch and the controller but they are seen as one machine to the other parts of the network. The OpenFlow switch is at the front door of the server cloud and routes the incoming requests to the servers according to the rules defined in the controller code. The video is delivered over the VLC player running on both the client and the servers. To meet the stringent delay requirements of video streaming applications, the video was sent by UDP packets. The client listens to these UDP packets coming from the specified port and the servers deliver these UDP packets to the network using the same port. 4. EXPERIMENTAL RESULTS A test network, shown in Fig.2, was built to implement the scenarios described in the Section 3. The scenarios included two servers and a client. A standard MPEG test sequence 724
Fig. 3. Scenario 1. into the tree which has 500 frames with the resolution of 1280x720 was used to demonstrate the scenarios. In order to have 2000 frames lasting about 80 sec, we looped the raw video sequence twice with 25 frames per second. We then encoded the video sequence at an average bit-rate of 1.8 Mbps using the ffmpeg AVC/H.264 encoder. The encoded test sequence was streamed from the two servers having the IP addresses 192.168.110.104 and 192.168.110.105. A client with IP address 192.168.110.101 received the video from one of these two streaming servers. In this implementation, UDP was used to stream the videos. The transportation ports 5004 and 5005 were used. Firstly, we implemented the first scenario in which the video was streamed from a fixed server. As stated in scenario 1, the traffic was loaded to Server 1 twice at t=10 sec and t=40 seconds. At both times the Server 1 was not able to send its packets to switch 1 as the bandwidth usage is approximately 10 Mbps which is the full capacity. As a result of overload, packets being sent from Server 1 to the client were dropped, which made it impossible for the client to receive the streamed video from Server 1. After the traffic returned to normal, we observed 20 sec delays in video playback. At both times the traffic was loaded as seen in Fig.3. Secondly, the second scenario was implemented which utilized our algorithm. For this implementation, we used the transportation port 5004. This time only a delay of 6 seconds was observed which was due to cost metric calculations and server switching. The link costs show that the bandwidth required is above the pre-defined threshold which is 8 Mbps. For that reason, the old flow entries were deleted and the new ones were pushed to the switches. In other words, the server streaming the video was switched with a 6 second delay. If the tests were done with more servers streaming the video, this delay will increase a little as there will be more cost metrics to calculate and compare; however, this increased delay Fig. 4. Scenario 2. Fig. 5. Delay characteristics of the two scenarios. will not be disturbing either. As seen in Fig.4, when the traffic was applied for the second time to Server 1, the video did not even stop since the video was streaming from Server 2. The graph shown in Fig.5 provides a comparison between two scenarios when the traffic is loaded to the Server 1 for the first time. As shown, the delays observed for scenario 1 increase linearly with the increase in traffic duration. However, when scenario 2 is implemented, the delay is always 6 seconds which is the server switching delay. The results indicate that there are improvements in QoS levels in Scenario 2 since the playback delay is significantly less under server overload conditions. 5. CONCLUSION Software Defined Networking is a very powerful paradigm as a future Internet architecture/protocol for video streaming with end-to-end quality of experience. This paper proposes 725
a new OpenFlow controller application design for load balancing for improved quality of service levels while streaming video from a cloud of servers. Our implementation shows that the delay characteristics of the streamed video can be improved under server overload conditions by using the proposed OpenFlow controller application. Furthermore, the proposed load-balancing application complements our previous OpenQoS application [7] such that the combined system can provide video streaming with end-to-end QoS in case of both network congestion and server overload. [10] H.E. Egilmez, S. Civanlar, and A.M. Tekalp, An Optimization Framework for QoS-Enabled Adaptive Video Streaming Over OpenFlow Networks, IEEE Transactions on Multimedia, vol. 15, no. 3, pp. 710 715, 2013. [11] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, [RFC 3550] RTP: A Transport Protocol for Real- Time Applications, July 2003. 7. APPENDIX 6. REFERENCES [1] R. Braden, D. Clark, and S. Shenker, [RFC 1633] Integrated Services in the Internet Architecture: An Overview, June 1994. [2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, [RFC 2475] An Architecture for Differentiated Service, December 1998. [3] E. Rosen and Y. Rekhter, [RFC 2547] BGP/MPLS VPNs, March 1999. [4] Open Networking Foundation, https://www. opennetworking.org/, Accessed: 2013-01-14. [5] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner, OpenFlow: Enabling Innovation in Campus Networks, SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, pp. 69 74, Mar. 2008. [6] OpenFlow@Google, http://www. opennetsummit.org/archives/apr12/ hoelzle-tue-openflow.pdf/, Accessed: 2013-01-14. [7] H.E. Egilmez, S.T. Dane, K.T. Bagci, and A.M. Tekalp, OpenQoS: An OpenFlow controller design for multimedia delivery with end-to-end Quality of Service over Software-Defined Networks, in Signal Information Processing Association Annual Summit and Conference (APSIPA ASC), 2012 Asia-Pacific, 2012, pp. 1 8. [8] B. Sonkoly, A. Gulyas, F. Nemeth, J. Czentye, K. Kurucz, B. Novak, and G. Vaszkun, On QoS Support to Ofelia and OpenFlow, in 2012 European Workshop on Software Defined Networking, 2012, pp. 109 113. [9] Arpit Gupta, Muhammad Shahbaz, Laurent Vanbever, Hyojoon Kim, Russ Clark, Nick Feamster, Jennifer Rexford, and Scott Shenker, SDX: A Software Defined Internet Exchange, http://hdl.handle. net/1853/49629/, 2013. Algorithm 1 Server Load Monitoring while (controller running, for each link) do Get byte count and calculate total bandwidth usage Find cost metric if ( total bandwidth usage > threshold) then iscongestednow if (iscongestednow and not iscongestedbefore) then delete flow iscongestedbefore = issomecongestednow if (iscongestedbefore) then if (noncongestioneventcounter > 3) then delete flow iscongestedbefore = iscongestednow if (iscongestednow) then noncongestioneventcounter = 0 noncongestioneventcounter++ end while Algorithm 2 Server Selection and Flow Updating while (controller running) do if (transportation port QoS port) then if (there is congestion) then if (the link being used is congested) then update the streaming server to have the least cost link drop all other server packets send from specified port end while 726