Contribution to Multiuser Videoconferencing Systems Based on Cloud Computing

UNIVERSIDAD POLITÉCNICA DE MADRID

Escuela Técnica Superior de Ingenieros de Telecomunicación

CONTRIBUTION TO MULTIUSER VIDEOCONFERENCING SYSTEMS BASED ON CLOUD COMPUTING

TESIS DOCTORAL

Javier Cerviño Arriba Ingeniero de Telecomunicación

Madrid, España 2013

Departamento de Ingeniería de Sistemas Telemáticos

Escuela Técnica Superior de Ingenieros de Telecomunicación

CONTRIBUTION TO MULTIUSER VIDEOCONFERENCING SYSTEMS BASED ON CLOUD COMPUTING

Autor: Javier Cerviño Arriba Ingeniero de Telecomunicación

Director: Joaquín Salvachúa Rodríguez Doctor Ingeniero de Telecomunicación

2013

Tribunal nombrado por el Magníﬁco. y Excelentísimo. Sr. Rector de la Universidad Politécnica de Madrid, el día 6 de mayo de 2013.

Presidente:

Vocal:

Secretario:

Suplente:

Realizado el acto de defensa y lectura de la Tesis el día 6 de mayo de 2013 en Madrid, habiendo obtenido la caliﬁcación de

El presidente, El secretario, Los vocales,

ABSTRACT

Multi-user videoconferencing systems offer communication between more than two users, who are able to interact through their webcams, microphones and other components. The use of these systems has been increased recently due to, on the one hand, improvements in Internet access, networks of companies, universities and houses, whose available bandwidth has been increased whilst the delay in sending and receiving packets has decreased. On the other hand, the advent of Rich Internet Applications (RIA) means that a large part of web application logic and control has started to be implemented on the web browsers. This has allowed developers to create web applications with a level of complexity comparable to traditional desktop applications, running on top of the Operating Systems. More recently the use of Cloud Computing systems has improved application scalability and involves a reduction in the price of backend systems. This offers the possibility of implementing web services on the Internet with no need to spend a lot of money when deploying infrastructures and resources, both hardware and software. Nevertheless there are not many initiatives that aim to implement videoconferencing systems taking advantage of Cloud systems. This dissertation proposes a set of techniques, interfaces and algorithms for the implementation of videoconferencing systems in public and private Cloud Computing infrastructures. The mechanisms proposed here are based on the implementation of a basic videoconferencing system that runs on the web browser without any previous installation requirements. To this end, the development of this thesis starts from a RIA application with current technologies that allow users to access their webcams and microphones from the browser, and to send captured data through their Internet connections. Furthermore interfaces have been implemented to allow end users to participate in videoconferencing rooms that are managed in different Cloud provider servers. To do so this dissertation starts from the results obtained from the previous techniques and backend resources were implemented in the Cloud. A traditional videoconferencing service which was implemented in the department was modiﬁed to meet typical Cloud Computing infrastructure requirements. This allowed us to validate whether Cloud Computing public infrastructures are suitable for the trafﬁc generated by this kind of system. This analysis focused on the network level and processing capacity and stability of the Cloud Computing systems. In order to improve this validation several other general considerations were taken in order to cover more cases, such as multimedia data processing in the Cloud, as research activity has increased in this area in recent years. The last stage of this dissertation is the design of a new methodology to implement these kinds of applications in hybrid clouds reducing the cost of videoconferencing systems. Finally, this dissertation opens up a discussion about the conclusions obtained throughout this study, resulting in useful information from the different stages of the implementation of videoconferencing systems in Cloud Computing systems.

RESUMEN Los sistemas de videoconferencia multiusuario permiten la comunicación entre más de dos usuarios que pueden interactuar a través de cámaras de video, micrófonos y otros elementos. En los últimos años el uso de estos sistemas se ha visto incrementado gracias, por un lado, a la mejora de las redes de acceso en las conexiones a Internet en empresas, universidades y viviendas, que han visto un aumento del ancho de banda disponible en dichas conexiones y una disminución en el retardo experimentado por los datos enviados y recibidos. Por otro lado también ayudó la aparación de las Aplicaciones Ricas de Internet (RIA) con las que gran parte de la lógica y del control de las aplicaciones web comenzó a ejecutarse en los mismos navegadores. Esto permitió a los desarrolladores la creación de aplicaciones web cuya complejidad podía compararse con la de las tradicionales aplicaciones de escritorio, ejecutadas directamente por los sistemas operativos. Más recientemente el uso de sistemas de Cloud Computing ha mejorado la escalabilidad y el abaratamiento de los costes para sistemas de backend, ofreciendo la posibilidad de implementar servicios Web en Internet sin la necesidad de grandes desembolsos iniciales en las áreas de infraestructuras y recursos tanto hardware como software. Sin embargo no existen aún muchas iniciativas con el objetivo de realizar sistemas de videoconferencia que aprovechen las ventajas del Cloud. Esta tesis doctoral propone un conjunto de técnicas, interfaces y algoritmos para la implentación de sistemas de videoconferencia en infraestructuras tanto públicas como privadas de Cloud Computing. Las técnicas propuestas en la tesis se basan en la realización de un servicio básico de videoconferencia que se ejecuta directamente en el navegador sin la necesidad de instalar ningún tipo de aplicación de escritorio. Para ello el desarrollo de esta tesis parte de una aplicación RIA con tecnologías que hoy en día permiten acceder a la cámara y al micrófono directamente desde el navegador, y enviar los datos que capturan a través de la conexión de Internet. Además se han implementado interfaces que permiten a usuarios finales la participación en salas de videoconferencia que se ejecutan en servidores de proveedores de Cloud. Para ello se partió de los resultados obtenidos en las técnicas anteriores de ejecución de aplicaciones en el navegador y se implementaron los recursos de backend en la nube. Además se modificó un servicio ya existente implementado en el departamento para adaptarlo a los requisitos típicos de las infraestructuras de Cloud Computing. Alcanzado este punto se procedió a analizar si las infraestructuras propias de los proveedores públicos de Cloud Computing podrían soportar el tráfico generado por los sistemas que se habían adaptado. Este análisis se centró tanto a nivel de red como a nivel de capacidad de procesamiento y estabilidad de los sistemas. Para los pasos de análisis y validación de los sistemas Cloud se tomaron consideraciones más generales para abarcar casos como el procesamiento de datos multimedia en la nube, campo en el que comienza a haber bastante investigación en los últimos años. Como último paso se ideó una metodología de implementación de este tipo de aplicaciones para que fuera posible abaratar los costes de los sistemas de videoconferencia haciendo uso de clouds híbridos. Finalmente en la tesis se abre una discusión sobre las conclusiones obtenidas a lo largo de este amplio estudio, obteniendo resultados útiles en las distintas etapas de implementación de los sistemas de videoconferencia en la nube.

Agradecimientos

Ante todo quiero agradecer el trabajo de mi director de tesis, Joaquín Salvachúa, por su apoyo y por contagiarme en innumerables ocasiones su optimismo en los momentos malos de mi investigación. Igualmente me gustaría agradecérselo al resto de personal del departamento, en especial a Juan Quemada, Gabriel Huecas, Santiago Pavón y Mónica Cortés por su ayuda para preparar esta tesis, y anteriores proyectos, clases y conferencias.

Muchísimas gracias a todos los que están o han pasado por nuestro laboratorio B-323, es decir, a los Isabelinos. No voy a poner nombres porque, para alguien que hace una tesis es ocupar dos o tres páginas, y si veis ésta comprenderéis que me he pasado del límite ya. Voy a agradecer momentos y anécdotas que entre todos me habéis dado durante todo este tiempo: la bienvenida al departamento, que para mi fue como una ﬁesta continua que duró un mes entero, con varias conferencias, cenas, etc., de las que recuerdo gente bailando con parejas extrañas y gente saliendo con urgencia del coche de Santi, etc. Gracias por tantas y tantas lecturas de proyecto ﬁn de carrera, tras las que siempre hemos conversado tranquilamente en el B-122. Por aquellas sobremesas que pasamos probando nuevas tecnologías de comunicación en tiempo real en la web, y aprendimos términos como one frag left. Por los viajes que hemos hecho juntos, como Bilbao, Washington o el último a Barcelona, en los que siempre han pasado cosas dignas de recordar. Gracias por los partidos de fútbol, voley playa, pádel o paint ball! También por inventaros las cenas moñas. Gracias por todas las conversaciones que me habéis dado durante las comidas: tema de veganos por delante de todos, por supuesto. Y por muchas, muchas otras historias que no caben aquí, pero que me han servido durante este tiempo que he realizado la tesis.

Gracias a mis "amigos por el mundo" (Gon, Ire, Ana y Ol), porque vosotros me animasteis como los que más a empezar esta aventura y me habéis seguido ayudando todo este tiempo, sin importar lo lejos que estéis.

Mil gracias a mi familia: mis padres, mis hermanos, Sonia, Pietro, Román y María, porque siempre, siempre, me habéis ayudado, y habéis creído en mí. Sin vosotros no habría sabido ni empezar.

Como siempre, y como con todo, la que más me ha apoyado eres tú, Bea. Gracias a ti, porque nadie como tú ha "sufrido" tanto esta tesis, y nadie como tú me ha sabido dar consejos tan buenos a cada paso. Por eso para mí tu opinión es la que más vale. Por eso, como me dijiste otras veces: podemos! Por eso, y porque eres lo más bonito y maravilloso, te quiero.

Y por último, gracias a los más importantes! Dani, Nerea, Anna y Marco. Porque no hay mejores sobrinos en el mundo entero!

Muchísimas gracias a todos!

Contents

Abstract Resumen Acknowledgments List of Illustrations List of Tables

1 Introduction 1 1.1 Objectives ...... 2 1.2 Research Methodology ...... 4 1.3 Related Projects ...... 5 1.3.1 ITECBAN ...... 6 1.3.2 ECOSPACE (IST-2005-35208) ...... 7 1.3.3 C@R (IST-2006-034921) ...... 7 1.3.4 GLOBAL ...... 8 1.4 Structure of this Document ...... 9 1.4.1 Chapter 2: State of the Art ...... 9 1.4.2 Chapter 3: Interface for Videoconferencing in the Cloud ...... 9 1.4.3 Chapter 4: Videoconferencing System Architecture ...... 9 1.4.4 Chapter 5: Methodologies for Testing Cloud Computing Infrastructures . 10 1.4.5 Chapter 6: Cost-Effective Videoconferencing for Hybrid Clouds . . . . . 10 1.4.6 Chapter 7: Validation And Results ...... 10 1.4.7 Chapter 8: Conclusions ...... 10

2 State of the Art 11 2.1 Cloud Computing Systems ...... 11 2.1.1 Overview of Cloud Computing ...... 11 2.1.2 Cloud Computing Providers ...... 19 2.1.3 Cloud Computing Platforms ...... 25 2.1.4 Related Cloud Research ...... 28 2.2 Technologies for Rich Internet Applications ...... 32 2.2.1 Adobe Flash Player ...... 36 2.2.2 Java FX ...... 38 2.2.3 Silverlight ...... 41 2.2.4 AJAX Frameworks ...... 43 2.2.5 HTML5 ...... 45 2.3 Multiparty Videoconferencing Systems ...... 48 2.3.1 History of Multiparty Videoconferencing Systems ...... 49 2.3.2 Signalling Protocols ...... 54 2.3.3 Technologies For Sending Media Flows ...... 58 CONTENTS

2.3.4 Web VideocOnferencing Systems ...... 62

3 Interface for Videoconferencing in the Cloud 65 3.1 Introduction ...... 65 3.2 Objectives ...... 66 3.3 Marte Web Videoconferencing Architecture ...... 67 3.3.1 Objectives ...... 67 3.4 Videoconferencing and Cloud Computing ...... 71 3.5 Nuve: Conceptual Model ...... 72 3.5.1 Users ...... 73 3.5.2 Rooms ...... 74 3.5.3 Services ...... 74 3.5.4 Tokens ...... 75 3.6 Nuve API ...... 75 3.6.1 User ...... 76 3.6.2 Room ...... 77 3.6.3 Service ...... 79 3.6.4 Token ...... 80 3.7 Security ...... 81 3.7.1 Description of the problem and experiences ...... 82 3.7.2 Security in Nuve: MAuth ...... 85 3.8 Results ...... 88 3.8.1 Implementation ...... 88 3.8.2 Test environment ...... 89 3.9 Contribution ...... 92 3.10 Conclusions ...... 92

4 Videoconferencing System Architecture 95 4.1 Introduction ...... 95 4.2 Objectives ...... 96 4.3 Design ...... 97 4.3.1 Conference Manager ...... 97 4.4 Implementation ...... 103 4.4.1 Isabel-based videoconferencing ...... 104 4.4.2 Flash-based videoconferencing ...... 105 4.4.3 SIP-based videoconferencing ...... 105 4.4.4 VNC and desktop sharing ...... 106 4.4.5 Recording ...... 106 4.5 Contribution ...... 106 4.6 Conclusions ...... 107

5 Methodologies for Testing Cloud Infrastructures 109 5.1 Introduction ...... 109 5.2 Objectives ...... 111 5.3 Amazon Network Measurements ...... 112 5.3.1 Important network features ...... 113 5.3.2 Architecture of the measuring environment ...... 115 CONTENTS

5.3.3 Measurement results ...... 116 5.3.4 Network Measurements for Stream Processing Systems ...... 120 5.3.5 Processing measurements for Stream Processing Systems ...... 122 5.3.6 Discussion For Stream Processing Systems in the Cloud ...... 123 5.4 Multimedia Streaming Experiments ...... 124 5.4.1 Tools and statistics ...... 124 5.4.2 Scenario architecture description ...... 126 5.4.3 Results ...... 128 5.5 Adaptive Cloud Stream Processing Algorithm ...... 129 5.5.1 Algorithm ...... 130 5.5.2 Implementation ...... 132 5.5.3 Experimental Evaluation ...... 132 5.6 Contribution ...... 133 5.7 Conclusions ...... 134

6 Cost-Effective Videoconferencing for Hybrid Clouds 137 6.1 Objectives ...... 138 6.2 Motivation and Context ...... 138 6.3 Validation of Hybrid Cloud for a Videoconferencing System ...... 140 6.3.1 General methodology ...... 140 6.3.2 Cost analysis ...... 144 6.3.3 Results Validation and Performance Evaluation ...... 145 6.4 Test scenarios ...... 146 6.4.1 Project resource usage ...... 147 6.4.2 Research using Conference Manager ...... 147 6.5 Contribution ...... 148 6.6 Conclusions ...... 148

7 Validation And Results 149 7.1 Validation in European Projects ...... 149 7.1.1 ECOSPACE ...... 149 7.1.2 Collaboration At Rural ...... 151 7.1.3 GLOBAL ...... 152 7.2 Validation in National Projects ...... 155 7.2.1 ITECBAN ...... 155 7.2.2 IBA and CyberAula 2.0 ...... 158 7.3 Dissemination of Results ...... 159 7.3.1 Publications ...... 159 7.3.2 Research Visit ...... 162 7.3.3 Teaching and Seminars ...... 163

8 Conclusions 165 8.1 Videoconferences Interfaces in Cloud? ...... 166 8.2 Factors to be considered in the implementation on Clouds? ...... 168 8.3 How to adapt videoconferencing to Hybrid Clouds? ...... 169 8.4 Contributions ...... 169 8.5 Future Research ...... 173 CONTENTS

Bibliography 177 Illustrations

2.1 Layered design of a cloud datacentre network architecture ...... 17 2.2 Amazon EC2’s main components ...... 21 2.3 Percentage of clients with RIA sandboxes installed ...... 34 2.4 JavaFX 2.0 Architecture Diagram ...... 39 2.5 HTML5 APIs and related technologies ...... 47 2.6 Multiparty Videoconferencing Technical Components ...... 49 2.7 AT&T’s Picturephone component diagram ...... 50 2.8 Example of Messages Sent During a SIP Session ...... 55 2.9 List of Messages Used in Jingle ...... 57 2.10 Overview of real-time protocols and standards ...... 62

3.1 Nuve Layer Architecture ...... 76 3.2 Authentication Sequence Messages ...... 87 3.3 Service Deletion Programming Logic ...... 90 3.4 Bandwidth and CPU consumption in different scenarios ...... 91

4.1 Conference Manager Architecture ...... 98 4.2 Conference Manager REST API ...... 99 4.3 Conference Manager Components ...... 104 4.4 Videoconferencing real scenarios ...... 108

5.1 Architecture of the measuring environment ...... 112 5.2 Measurement results between datacentres EU-US ...... 117 5.3 Measurement results between datacentres EU-AP ...... 118 5.4 Measurement results between datacentres US-AP ...... 119 5.5 Experimental set-up for network measurements ...... 120 5.6 Jitter experienced when sending streams to Amazon EC2 ...... 121 5.7 Comparison of network- and application-level delay on Amazon EC2 ...... 121 5.8 Performance of Esper as a function of time on Amazon EC2 ...... 122 5.9 Increase in throughput with different instance sizes on Amazon EC2 (Different shades/colours correspond to different VMs.) ...... 123 5.10 Node distribution ...... 127 5.11 The 99.7th percentile of jitter in each scenario ...... 135 5.12 Bytes received in each scenario ...... 135 5.13 Packet losses in each scenario ...... 135 5.14 Elastic DSPS with query partitioning across processing VMs ...... 136 5.15 Dynamic adaptation of VM numbers based on changes in input rates ...... 136 ILLUSTRATIONS

6.1 Typical Cloud Node Costs ...... 141 6.2 Cloud Architecture ...... 143 6.3 Cost differences between Cloud architectures ...... 145 6.4 Cost of an Isabel Hybrid Session ...... 147

7.1 ECOSPACE’s Primitives for Managing Nuve Functionalities ...... 150 7.2 Videoconferencing Login Page in ECOSPACE ...... 151 7.3 Example of Marte Room ...... 152 7.4 Screenshot of a recorded event in GlobalPlaza ...... 154 7.5 Form to create an event in GlobalPlaza ...... 155 7.6 Global Plaza Events ...... 156 7.7 Global Plaza Videos ...... 157 7.8 iTecSoft Architecture ...... 158 7.9 iTecSoft Login Page ...... 159 7.10 iTecSoft Videoconferencing Client ...... 160 7.11 CyberAula Architecture ...... 161 Tables

2.1 Layered Architecture Of Cloud Computing ...... 15 2.2 List of Cloud Infrastructure Providers ...... 25 2.3 List of Rich Internet Application Frameworks ...... 35 2.4 Comparison of Web Videoconferencing Systems ...... 64

3.1 Types of HTTP Encapsulations ...... 69 3.2 Resources From The Conceptual Model ...... 73 3.3 HTTP methods used for XML/JSON contents ...... 81 3.4 HTTP methods used for HTML contents ...... 82

4.1 HTTP methods used for XML resources ...... 99

7.1 Hosting Requirements for Conference Manager in GLOBAL project ...... 153 TABLES Chapter 1

Introduction

Videoconferencing systems are widely used throughout the Internet nowadays. In the recent years, the heterogeneity of terminals, such as TV, laptops, mobile phones, tablets, etc. along with the variety of network access connections including ADSL, Cable Modem, Wi-Fi, UMTS, etc. has become to involve more complexity for real-time multimedia systems. But on the other hand they have also given rise to new opportunities for this kind of systems, with new scenarios, and new possibilities for users to talk, collaborate, participate in conference sessions, etc. The maturity of multimedia codecs, formats and protocols has become a reality in the last decade and a lot of videoconferencing applications and solutions arise every year. The use of these systems to handle sessions with multiple participants in a meeting, conferences, course, etc. has been accepted in different scenarios, and many solutions have come about to overcome the problems they present. Among these problems we can ﬁnd those that are related to any type of videoconferencing (transport protocols, codecs, QoS, signalling protocols, etc.) and those that are closely related to multiple users who are sending their videos to the other participants. The most common problems are related to the need for a centralized architecture that can handle all the streams generated in the session and the implementation of advanced services that can be provided within the sessions: whiteboard sharing, application sharing, instant messaging, and so on. In some cases many of these streams can be produced in distant places that introduce more latency and decrease the overall quality of the session, in other cases the participants can access to the session through different devices, which means more complexity during the management of the session. At the same time, Cloud computing has emerged as a ﬂexible paradigm for facilitating resource management for elastic application deployments at an unprecedented scale. Cloud providers offer a shared set of machines to cloud tenants, often following an Infrastructure-as-a-Service (IaaS) model. Tenants create their own virtual infrastructures on top of physical resources through virtualisation. Virtual machines (VMs) then act as implementation environments for applications. 2 CHAPTER 1. INTRODUCTION

The scattered nature of Cloud datacentres allows their clients to set their resources at different locations around the world, making it possible for videoconferences to set up a new centralized architecture focusing on a speciﬁc continent or even country. Furthermore, the availability of different datacentres around the world and their dedicated connectivity could allow these systems to take advantage of new Internet paths around the world. These new paradigms, moreover, could provide "inﬁnite" videoconferencing resources to the extent that it could simplify the scalability of sessions with multiple participants, video streaming, etc. Based on this idea, this dissertation aims to answer this question: How could Cloud Computing platforms leverage the quality and performance of traditional videoconferencing systems with multiple participants? In fact, this work addresses three open challenges to the research community:

1. What kinds of interface are suitable for providing multi-party videoconferencing services in Cloud Computing platforms?

2. Which factors need to be considered in the implementation of real-time multimedia systems in the Cloud?

3. How can we adapt videoconferencing systems to advanced Cloud Computing platforms with multiple providers and heterogeneous infrastructures?

This research embraces the study of Cloud Computing as a catalyst for improving several technological challenges in the videoconferencing domain: starting from the study of Cloud interface alternatives that could manage real-time multimedia systems, fol the analysis of different aspects and technological barriers that have to be considered in its implementation and ending with advanced Cloud-oriented mechanisms that could increase the performance of these systems while their costs are minimized. The main outcome is the proposal of new Cloud-oriented videoconferencing architectures with improved performance, especially in the context of sessions with multiple participants.

1.1 Objectives

The main objective of this dissertation is the proposal of new techniques and methodologies to improve current multiuser videoconferencing systems based on the new technologies proposed 1.1. OBJECTIVES 3 by Cloud Computing platforms. Our purpose is the study of new interfaces, implementation architectures and methodologies that could increase the quality of these services, while the costs remain low or even get lower. The speciﬁc objectives of this work can be summarized as follows:

• To identify open challenges in the implementation of traditional videoconferencing interfaces in Cloud Computing platforms. This study should overcome the strengths and weaknesses of such interfaces for their implementation in Cloud-based architectures.

• To propose new interfaces for videoconferencing architectures in Cloud Computing platforms. As a result of the previous study, this proposal should include a set of functionalities to handle these architectures.

• To identify which elements are needed for videoconferencing in cloud environments. We will deﬁne a set of resources that will take part in a system deployed in Cloud platforms.

• To implement a videoconferencing system architecture fully implemented in Cloud datacentres. It should take advantage of the main Cloud features: scalability, self-service, automatic resource management, etc.

• To test the suitability of Cloud Computing networks in the context of real-time multimedia data. The main network characteristics will be evaluated to check whether they could support data sent through the Cloud network: latency, bandwidth and packet losses.

• To test whether Cloud Computing virtual machines are suitable for processing real-time multimedia data. We will evaluate if best-effort VMs are appropriate and have the sufﬁcient level of predictability to support the strict requirements of real-time multimedia systems.

• To provide cost-effective mechanisms for deploying videoconferencing systems in multiple Cloud providers. We will design new mechanisms to reduce costs in scenarios with multiple Cloud providers.

• To validate the feasibility of the research approach. In order to validate these contributions the objectives described in this document should be validated. 4 CHAPTER 1. INTRODUCTION

1.2 Research Methodology

The implementation of videoconferencing systems using Cloud Computing technologies presents significant research challenges. The work carried out in the ITECBAN, ECOSPACE i, C@R ii and GLOBAL iii projects has helped me to identify these challenges. In the next section I will give details on the work carried out in these projects and how they helped me to design, implement, test and validate the architecture. As regards the methodology I followed to make this dissertation, I started from the main objectives explained in section 1.1. I carried out wide-ranging research into the architectures, technologies, and interfaces related to videoconferencing systems in the cloud. Taking into consideration the conclusions of this initial study we started to design an interface to provide Cloud-based videoconferencing resources. As a result, a novel resource-oriented interface was designed, based on traditional standardized videoconferencing interfaces. Moreover, the work carried out at ITECBAN helped the author to implement security mechanisms within the interface to be compatible with business environments with strict authentication requirements. And during the ECOSPACE project the author was able to adapt the interface to interoperable environments. To develop the videoconferencing architecture we based on the previous interface and started to identify the different components that take part in any multimedia session. As regards multimedia components, the author participated in the ITECBAN, ECOSPACE and C@R projects to start the development of this system in different scenarios. Once we had identified these components we implemented the architecture following the Cloud Computing principles. In the process of developing a videoconferencing system architecture based on Cloud Computing technologies we had to take into account the problems and challenges it can present for real-time multimedia systems. This kind of system usually involves strict requirements as regards of the special conditions of the traffic they generate and handle. All these challenges and problems were identified during the development of these architectures in the GLOBAL project. In particular, the author contributed to the definition and validation of a common videoconferencing architecture partially hosted on public Cloud datacentres that were used by

ihttp://www.ip-ecospace.org/ iihttp://www.c-rural.eu/ iiihttp://www.global-project.eu/ 1.3. RELATED PROJECTS 5 many European projects to set up virtual conferences. An extensive review of the literature was carried out related to Cloud Computing performance evaluations. A series of tests were carried out in order to check whether Cloud Computing infrastructures were suitable for processing real-time data and managing the multimedia trafﬁc through their networks. Many conclusions were drawn from this study that validated the suitability of Cloud systems to host videoconferencing resources. Further research was required for extending the results to more general streaming services, such as the case of stream processing systems. During a three-month research stay in the Department of Computing at the Imperial College London, in the United Kingdom, the author carried out an extended evaluation of Cloud systems in the context of stream processing engines that are hosted in their infrastructures. Once the technical validation was completed the author designed a new cost-effective methodology for Hybrid Cloud scenarios. These scenarios consist of applications and services that are distributed on multiple Cloud providers at the same time, either public of private Clouds. As a result, the author was able to validate the feasibility of videoconferencing systems in these scenarios economically reducing Cloud costs in cases where the services can be dividing into several components. A ﬁnal validation was carried out throughout the different projects in which the author participated. In the next section we will see details of those projects in which the author actively participated and whose work was crucial in validating this dissertation. Additional projects were equally helpful during these tasks, such as IBA and CyberAula 2.0 national projects, in which the architecture implemented by the author was used to support videoconferencing and lecture recording services through the integration of three platforms: UPM Moodle, the Global Plaza platform and Isabel videoconferencing tool. In these projects the author was able to validate the usage of these videoconferencing systems in the Cloud in real scenarios.

1.3 Related Projects

The research of this dissertation has been partially supported by projects related to collaborative spaces and videoconferencing technologies. This allows the author to validate the theoretical development in real scenarios, the interoperability with external services and the integration into Cloud Computing systems. A brief description of these projects is presented in chronological 6 CHAPTER 1. INTRODUCTION order.

1.3.1 ITECBAN

The ITECBAN project, part of the CENIT program of the Ministerio de Industria, has as its main objective the creation of an infrastructure, both methodological and technological through which the removal of the current limitations of information systems used in ﬁnancial environments is achieved. To this end, the author participated in building additional software tools to the core banking process, oriented towards the collaborative activities of a virtual organization. ITECBAN had to support different collaborative activities such as the software development process within a banking core, videoconference, content management, etc. These activities imposed a series of requirements that the platform needed to support. This platform must satisfy, at least, the following functional requirements:

• Asynchronous communication for organizing f2f (face-to-face) meetings or coordinating activities.

• Synchronous communication for sharing management information in different standardized formats.

• The ability to use this information from geographically distributed facilities.

• Coordinating a group of people with quite similar skills and business expertise through a project/group leader, manager or community expert.

• Scheduling virtual or f2f meetings, keeping track of them.

• Using workﬂow management to coordinate their daily activities.

• Each component is independent of the others and they communicate through the services that each of them offers.

This provided an opportunity to validate some of the contributions of this dissertation. In particular, the author was able to implement the videoconferencing interface and a ﬁrst architecture based on this interface, and test it in a business environment. 1.3. RELATED PROJECTS 7

1.3.2 ECOSPACE (IST-2005-35208)

ECOSPACE is an integrated project pursuing the vision that every professional in Europe is empowered for seamless, dynamic and creative collaboration across teams, organisations and communities through a personalised collaborative environment. The main project objective is the realisation of new collaborative working environments based on a better understanding of the work environment, the development of collaboration services as a collaboration platform, and new innovative user-centric collaboration tools that reduce the complexity of todayâA˘ Zs´ technology-centric applications. Accordingly, the objective of ECOSPACE, embedded in several living labs within different application areas, is to develop:

• Innovative working paradigms through research and understanding of eProfessional work and organisation.

• A reference architecture and interoperability concepts for a user-centric integration of collaboration tools

• Collaboration layer middleware services to ensure seamless and instant collaboration between knowledge workers in group forming networks, beyond organisational boundaries.

• New collaboration-aware tools that reduce the complexity of collaboration in dynamic work environments supporting users for creative and knowledge intensive tasks. Instant collaboration is supported by the integration of asynchronous and synchronous collaboration tools, which results in augmented virtual presence/social networks and rich virtual collaboration.

The author contributed with the deployment of the videoconferencing architecture and interface in the Cloud and its integration into the rest of collaborative tools in the project.

1.3.3 C@R (IST-2006-034921)

C@R, short for Collaboration at Rural, is an Integrated Project, funded by the IST programme of the European Commission’s 6th Framework Programme. Its main objective is to promote the introduction of collaborative working environments as key enablers of sustainable development in 8 CHAPTER 1. INTRODUCTION rural areas iv. C@R proposes a technological response to the barriers preventing rural development and will use the Living Labs methodology as a way to involve rural constituencies in Research & Technological Development (RTD) activities in collaborative technologies. This project proposed a set of collaboration tools, in which we included the videoconferencing architecture provided in this dissertation.

1.3.4 GLOBAL

The objective of the GLOBAL project is to increase the impact, dissemination and promotion of e-Infrastructure research projects in Europe and around the world by means of the service provision of a Virtual Conference Centre (VCC). The VCC uses advanced communication technologies to allow project and training events to reach a wider audience located in multiple geographical locations through the organisation of virtual conferences. GLOBAL enables the remote participation as virtual connections via Internet to events, by deploying a well-developed system called Conference Manager. Participation may allow any type of remote contribution, from just asking questions, remote demonstrations or giving remote presentations with slides. As an example, GLOBAL enabled the integration of remote participation at TNC2009 from keynote speakers and auditoria worldwide. The VCC provides a user-centric interface for the planning, creation, announcement, coordination, content management, and realisation of virtual conferences with open and wide participation. Focusing on usability, it provided three main functions:

• A Virtual Auditorium, for planning, co-ordination, and management of the virtual events.

• An Event Repository, to store the recordings and outputs of the events.

• A Virtual Corridor, which supported networking and partnership building between the participants.

The author collaborated in this project by implementing the Conference Manager, which is the central videoconferencing architecture of this dissertation and the project. During the project the

ivAccording to the EC deﬁnition, a rural area is an area with a population density below 100 inhabitants per km2.This creates special conditions for the development of an infrastructure that are different from the more populated city areas. It is also important to research into the conditions for development of IT applications in environments where there is traditionally a low educational level. 1.4. STRUCTURE OF THIS DOCUMENT 9 author also evaluated the suitability of Cloud Computing platforms as tools to host the Conference Manager’s resources.

1.4 Structure of this Document

1.4.1 Chapter 2: State of the Art

In this chapter, an in-depth study of current technologies and related work is presented to give a general overview of videoconferencing interfaces, protocols and tools on the one hand, and Cloud Computing systems and technologies on the other. The study includes the current state of the art in evaluations of how Cloud Computing systems can host high-performance systems, research applications and others with strong real-time and processing requirements. Other studies related to cost-effective mechanisms for hybrid Cloud Computing systems are also detailed in this chapter.

1.4.2 Chapter 3: Interface for Videoconferencing in the Cloud

In this chapter, results of the deﬁnition and design of new interfaces for providing videoconferencing applications by means of Cloud Computing platforms are presented. A model was designed resulting from the work made in projects ITECBAN, ECOSPACE and CR. This interface follows the Resource Oriented Architecture and is considered so as to instantiate different components in Cloud Computing systems. Furthermore, this interface aims to handle virtual conference with multiple participants who are sharing video, audio, desktop applications and instant messaging.

1.4.3 Chapter 4: Videoconferencing System Architecture

In this chapter, a new videoconferencing architecture is introduced that implements the interface designed in the previous chapter. This architecture is completely deployed in the Cloud, following its principles to improve scalability and resource distribution around the world. Several real tests were carried out to validate the architecture, and it was also partially supported by the GLOBAL project. The modular nature of the system provides new methods to optimize it in Cloud platforms. 10 CHAPTER 1. INTRODUCTION

1.4.4 Chapter 5: Methodologies for Testing Cloud Computing Infrastructures

In this chapter, the author present results of the evaluation of Cloud Computing infrastructures. The main purpose of this evaluation is to check whether current infrastructures (network and CPU virtualization) are suitable for hosting real-time multimedia resources and trafﬁc, and test whether those world Internet paths that connect different datacentres of the same Cloud provider are of better quality than standard Internet routes. This work was also extended during a research visit at Imperial College by studying similar scenarios for stream processing systems.

1.4.5 Chapter 6: Cost-Effective Videoconferencing for Hybrid Clouds

In this chapter, a new method to optimize the cost in applications in Cloud scenarios with multiple providers is introduced. The aim of the optimization is to reduce costs in these scenarios. To be able to exploit the hybrid clouds effectively two things are required. First we need to provide a uniform and homogeneous view of virtualized resources, regardless of the underlying virtualization platform. Second, we need to split the service into three parts: CPU, bandwidth and storage intensive modules.

1.4.6 Chapter 7: Validation And Results

In this chapter, general results from the different projects are presented along with validation of every contribution. It also details the results of this validation, dissemination details in the research community and additional information on the results of the dissertation.

1.4.7 Chapter 8: Conclusions

In this chapter, the author summarizes the main contributions and outlines some future research activities based on this work. Chapter 2

State of the Art

2.1 Cloud Computing Systems

”Cloud Computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction” [Mell 2011], according to the National Institute of Standards and Technology (NIST). Apart from this, there are thousand-and-one ways of defining Cloud Computing. As an example, the work in [Vaquero 2009] compared more than 20 different definitions from a variety of sources trying to extract a consensus definition. It is a new computing model in which resources are provided as general utilities (the same as water, electricity, gas, and telephony), that can be leased and released by users through the Internet in an on-demand fashion. The emergence of Cloud Computing has the potential to transform the Information Technology (IT) as we know it today [Kalapatapu 2012]. Business enterprises seek to reshape their business models to gain benefit from this new paradigm. Indeed, Cloud Computing provides several compelling features that make it attractive to business owners: No up-front investment, lowering operating cost, highly scalable, easy access, and reducing business risks and maintenance expenses [Zhang 2010]. In this section we provide an overview of Cloud Computing and give details about some Cloud Providers and different platforms that offer Cloud services at different levels.

2.1.1 Overview of Cloud Computing

The basic idea of Cloud Computing, which is related with Utility Computing, is not a new one. The concept of computing as public utility was announced in 1955 [Parkhill 1966], and remained just a concept for near 50 years. Actually, the term ”Cloud” has also been used in other contexts like telephony, Internet, etc. The term "Cloud Computing" was ﬁrst used by NetCentric, when they tried to trademark the term 12 CHAPTER 2. STATE OF THE ART in a patent. They abandoned it in April 1999. The New York Times used the phrase "cloud of computers" when talking about a new Microsoft .Net services platform called Hailstrom. Finally in 2006 Google’s CEO Eric Schmidt described Google’s approach to SaaS as Cloud Computing in the Search Engine Strategies Conference. A few weeks later Amazon included the word "cloud" in EC2 when it was launched. Since then the term cloud has been widely used in a marketing fashion without any other standard deﬁnition but the one from NIST. The main reason for the existence of different perceptions of Cloud Computing is that it is not a new technology, but rather a new model using a set of existing technologies to run business and computing in a novel way. Actually many of the technologies of Cloud Computing are not new, such as virtualization and utility-based pricing. But it uses these technologies to meet the actual technological requirements of today’s demand for IT.

Cloud Computing Features

According to NIST deﬁnition these would be the essential features of Cloud Computing:

• On-demand self-service: A client can provision computing resources as needed without requiring human interaction with each provider. Typical computing resources would be server time, storage capacity, network access to the server, etc.

• Broad network access: Capabilities and resources are available over the network and can be accessed from anywhere. The access is made through standard mechanisms that promote use from different client platforms, such as laptops, mobile devices, or tablets. Several protocols are being implemented in order to access both interfaces and cloud resources. In the case of the interfaces the most common is HTTP and in the case of the resources it depends on the type of resources, operating system and services that are running.

• Resource pooling: This is a principle which means making a collection of resources behave like a single pooled resource [Wischik 2008]. Here the provider’s computing resources are shared amongst multiple users.

• Location Independence: There is a sense of location independence in that the consumer generally has no knowledge over the exact location of the provided resources. In contrast the 2.1. CLOUD COMPUTING SYSTEMS 13

user may be able to specify the location at a higher level of abstraction. In order to reduce the latency many commercial cloud providers deploy datacentres in different location around the world. And example is Amazon EC2, that currently has installed several datacentres in USA, Europe and Asia.

• Multi-Tenancy: The resources are pooled to server multiple consumers using a multi-tenant model, i.e., with different physical and virtual resources dynamically assigned and reassigned according to user demands. There are examples like OpenStack platform, which takes into account different tenants, which can be dynamically associated with projects, users, etc.

• Rapid elasticity: Capabilities and resources can be rapidly and elastically provisioned to quickly scale out and scale in. Actually, the capabilities to be provisioned often appear to be unlimited and can be purchased in any quantity at any time. There are different auto-scaling solutions used by several cloud, proposals, commercial ones and others developed by academia. In [Marshall 2010] they developed a resource manager that adapts services provided within a site (schedulers, storage archives, Web services, etc), and to avoid over- and under-provisioning the resources they proposed three different policies to schedule resource deployment based on demand. These policies are on demand (booting new VMs when there are new jobs in the queue and terminating them when the queue is empty), steady stream (leaving always at least one VM running becuase it assumes that there will potentially be a "steady stream" of jobs arriving at the queue), and bursts (calculating the amount of machines to boot when a burst of jobs arrives, basing on the amount of work in the queue). Similar works also monitor a job queue [Murphy 2009] or individual jobs [de Assuncao 2009]. VioCluster [Ruth 2005] is a scaling solution that works with clusters of physical and virtual machines similar to the previous one. In [Ruth 2006] the authors create an adaptive environment of VMs which adjusts the number of machines by measuring the current load within each VM. We will see commercial and Open Source solutions in sections 2.1.3 and 2.1.2.

• Measured Service: Resource usage can be maintained for both provider and the consumer of the utilized service. In general users have less work in terms of resource upgrades and management. With the evolution of grid computing some authors published their work on 14 CHAPTER 2. STATE OF THE ART

monitoring large-scale distributed platforms built on top of these systems. For example in [Wolski 1999] they provided short-term performance forecasts based on historic performance measurements by means of a distributed system. To increase fault tolerance they used an adaptive and replicated control strategy by an adaptive time-out discovery and a distributed election protocol. They used sensors grouped into heriarchical set called cliques, which can only perform intra-clique measurements increasing scalability of the system. In [Massie 2004] Ganglie addresses the problem of wide-area multi-cluster monitoring using a hierarchy of arbitrary number of levels. Finally, Supermon [Sottile 2002] focus on a ﬁne-grained sampling of measurements in order to provide a high-speed cluster monitoring tool, and RVision [Ferreto 2002] follows a master-slave architecture which communicate by using TCP and UDP sockets with a low-overhead protocol used for monitoring clusters.

Typical problems of Cloud Computing related with these features have been often reported in several studies. In [Armbrust 2009] the authors discussed about different Cloud Computing challenges, such as the need for availability of cloud service, data lock-in due to poor interoperability among platforms, privacy, data transfer bottlenecks between providers and consumers, performance unpredictability in the virtualized software, licensing, etc.

Cloud Computing Architecture

Cloud Computing architecture is based on the classical 7-layer OSI model of data networks i. The layered model in Cloud Computing serves the same general purpose. The components of a basic layered architecture are shown in Table 2.1, namely the Client, its required Services, the Applications that the Client runs, the Platform on which these applications run, the Storage requirement and ﬁnally the Infrastructure required to support the Client’s computing needs. Clients: The clients of Cloud Computing could be hardware or software devices with the computational capability for making requests to cloud APIs to consume any type of service. Services: Typically there would be Web Services with special APIs or interfaces. These could leverage features not only from the Web, but also infrastructure and platform capabilities. For

iITU-T X-Series Recommendations: http://www.itu.int/rec/T-REC-X/en 2.1. CLOUD COMPUTING SYSTEMS 15

Table 2.1 : Layered Architecture Of Cloud Computing

Cloud Computing users. Consumers of any cloud CLIENTS service.

Web services. Flickr API, Google Maps API, SERVICES Storage

Web-based applications. Google apps, APPLICATIONS salesforce.com, tax preparation, Flickr

Virtual hosting. Use a preconﬁgured appliance or a PLATFORMS custom software stack, AMP, GlassFish, etc.

Rent a preconﬁgured OS. Add your own

OPERATING SYSTEM CLOUD INFRASTRUCTURE HARDWARE & SOFTWARE STACK applications. Example: DNS server

Rent a virtual server. Deploy a VM image or install VIRTUAL SERVERS your own software stack

Rent a compute grid. Example of this would be HPC PHYSICAL SERVERS applications

example, different cloud service models like SaaS (Software as a Service), IaaS (Infrastructure as a Service) and PaaS (Platform as a Service) could made available through these interfaces. Applications: Cloud Computing allows users to access applications remotely via Internet, rather than installing them at each customer’s own computer, thereby simplifying maintenance and support at the customer’s end. Platforms: Cloud also facilitates deployment of applications without the need for buying and managing underlying hardware and software components. This layer often use Cloud infrastructure and using this layer consumers create Cloud applications. Operating System: These usually are preconﬁgured Operating Systems prepared to be used with a set of applications in the upper layers. Users only need to install these applications to support or offer other cloud services. Virtual Servers: This layer delivers computer infrastructure, including management of virtual resources such as CPU, network, storage capacity, etc. Clients of this layer buy these resources as a fully outsourced service. 16 CHAPTER 2. STATE OF THE ART

Physical Servers: These are the physical resources that are going to be used by the virtualization layer. Clients also could use these layer as a compute grid, especially for High-Performance Applications (HPC). Frequently components that are related to one of the layers make use of components which reside on the underlying layers. But there could be some resources that could be related to more than one layer at the same time. It does not only depend on each particular service, but also on the deployment methodology, if the cloud service is going to be commercial, or if it is going to be deployed in a private datacentre. Typical architecture design for a cloud datacentre, private or public, is explained in the next part of the section.

Cloud datacentre architecture

The datacentre is the home for the computation power and storage, In Cloud Computing systems it is the core of the platform and usually contains numerous devices such as routers, switches, servers, hard disks, etc. Thus, the planning of its architecture is a critical step in the design of a cloud system, as it will heavily influence service performance and communication throughput, while other features like scalability and auto-scaling have to be considered in its implementation. Nowadays a datacentre is implemented with a layered approach, like the one in figure 2.1. The architecture is based on three layers: Access layer: Here the servers that are in racks physically connect to the network. According to [Zhang 2010] typical values are 20 to 40 servers per rack, each connected to an access switch with a 1 Gbps link. Access switches are connected to two aggregation switches in order to have redundancy. This connection is made of links with 10 Gbps. Aggregation layer: Some functions such as domain service, location service, load balancing, etc. are provided at this layer. Core layer: This layer provides connectivity to multiple aggregation layers using core routers that manage traffic into and out of the datacentre. This layer provides provides a resilient router traffic with no single point of failure. According to [Al-Fares 2008, Greenberg 2009, Guo 2009] a datacentre network architecture should meet the following objectives: Uniform high network capacity, a communication topology that supports free VM migration, resiliency, scalability to allow for incremental expansion and 2.1. CLOUD COMPUTING SYSTEMS 17 backward compatibility with switches and routers running.

Internet

Core

Aggregation …...

Access

Figure 2.1 : Layered design of a cloud datacentre network architecture

Cloud Deployment Techniques

Typical Cloud deployment techniques comprise the Public deployment, the Private deployment and the Hybrid deployment. We discuss each of these deployment methodologies briefly below: Public Cloud: With this technique the Cloud deployment resources are dynamically provisioned by third party providers who bill the users on a fine grained utility computing basis. They traditionally offer easy resource management, scalability and flexibility with an economical pay-as-you-go model. These services are often publicly available to the users through Web user interfaces. 18 CHAPTER 2. STATE OF THE ART

Private Cloud: This deployment maintains the services and infrastructures on a private network. Traditionally these clouds offer greater level of security and control, but on the other hand they require the company to still purchase and maintain all the resources, software and other infrastructure element, which could reduce the cost savings. Today the lines between private and public clouds are blurring because some public cloud providers are now offering private versions of their public clouds. These clouds are commonly known as Virtual Private Clouds. And at the same time some companies more specialized in private clouds have started to offer public services with their products in a public cloud fashion. Hybrid Cloud: This term has been widely discussed among a variety of authors. Here we will consider a Hybrid Cloud as a variety of public and private options with multiple providers and private technologies. Typically in this scenario the consumers keeps each aspect at its business in the most efﬁcient environment possible. The problem here is that the consumer has to keep track of multiple different platforms and ensure that all aspects of their business can communicate with each other. We will further discuss advantages and disadvantages later when we talk about Hybrid Clouds and their beneﬁts. In section 2.1.4 we will further discuss its state-of-the art and research challenges.

Cloud Computing Services

Cloud Computing is the delivery of computing, software, information, network and platforms as a service. Actually another way to describe it would be to term it as "Everything as a Service", or XaaS. The Cloud can provide its users with thousands of service models and services. These are the most known: Infrastructure as a Service (IaaS): It covers Operating System, Virtual Server and Physical Server layers seen in the previous section, when we talked about the Cloud Computing architecture. Thus, this service provisions for hardware related services: storage, virtual servers, network, etc. Consumers can use IaaS to quickly build new versions of applications or environments, and they do not need to purchase for updates. Features like on-demand self service and pay-as-you-go model makes IaaS competent enough for any kind of business. Examples of this service are Amazon, Rackspace, GoGrid, Microsoft Azure, CloudSigma, etc. But there are also technologies such as OpenNebula, Eucalyptus, OpenStack, etc. that provide this 2.1. CLOUD COMPUTING SYSTEMS 19 functionality to organizations that are going to implement a private cloud. Furthermore there are standard and non-standard interfaces such as OCCI, vCloud, CIMI, Amazon EC2 API, etc.

Platform as a Service (PaaS): It covers the Platform layer. It offers facilities for application development, design, testing, deployment and hosting. Several platforms also include extra features like team collaboration, external APIs, security, database integration, etc. Typical commercial examples are Google App Engine, Microsoft Azure, Force.com, Heroku, etc.

Software as a Service (SaaS): It covers service and application layers. In this case the cloud provides applications as fully or partially remote services. Typically these applications are based on web interfaces and users can access them using a thin client (with the RIA solutions we will comment in section 2.2), but other times it consists of non-remote applications which interact with some part of the service via Internet. Examples are Salesforce.com, GMail, google docs, Hotmail, etc.

Apart from these services we can also ﬁnd references to a more granular classiﬁcation of them, which includes:

Database as a Service(DaaS): It provides database software and related physical database storage as a service. The users can access the service on a pay-as-you-go basis that provides on- demand access to a database deployed in the Cloud. There are examples such as Amazon S3 or Force.com. There are also standard interfaces such as CDMI.

Process as a Service (PraaS): It refers to a remote resource that is able to bind many resources together, either hosted within the same Cloud resource or remote, in order to create business processes. Typically these processes are easier to change than standard applications so they can be updated more frequently. Providers include Appian Anywhere, Akemma and Intensil.

Videoconference as a Service (VaaS): It provides videoconferencing capabilities such as video and audio communication among users. Videoconferencing resources are running in the cloud and users are connected with them using traditional or private communication protocols such as RTP or RTMP. Examples include BigBlueButton, Flash Meeting, and Tok Box.

2.1.2 Cloud Computing Providers

This section depicts the most important IaaS providers nowadays, showing main characteristics and additional features, and making a comparison among them. 20 CHAPTER 2. STATE OF THE ART

Amazon AWS It is composed of Amazon EC2 (Elastic Compute Cloud) and Amazon S3 (Simple Storage Service) among other services. Currently the highest proﬁle IaaS operation is Amazon Web Services set of Cloud services. Thus, the term "cloud infrastructure" is largely synonymous with Amazon EC2 and S3 for a majority of people working with clouds according to [Reese 2009].

Amazon did not start implementing its cloud from the scratch thinking in a cloud-based service. Instead they initially built a massive infrastructure to support its retail business and lately they discovered it was underused. Then they decided to offer these useless CPU cycles and resources as a web service. And they realized that customers began to use it massively. Amazon’s EC2 and S3 were launched in 2006 and has evolved since then by adding new features and support for different systems.

Amazon S3: S3 is cloud-based persistent storage. It is independent from the rest of Amazon services to the extend that traditional applications could use it without any need to otherwise be in the cloud.

Access to Amazon S3 can be made through SOAP or REST APIs. And both APIs support the ability to fin buckets and objects, discover their metadata, create new buckets, upload objects to these buckets, and delete existing buckets and objects. Currently there are myriads of API wrappers for a wide variety of programming languages. Thus, Amazon S3 is not a traditional file system, it has no directories or files. Instead it uses buckets in which users can store objects of data.

Amazon EC2: EC2 represents the user’s virtual network with all of the virtual servers running inside this network. It depends on Amazon’s S3 because machine images and other resources are stored there.

There is a set of concepts related to Amazon EC2 that are part of that service and are related to each other, see ﬁgure 2.2. Thus, Amazon EC2 is composed of: an instance is a virtual server running a guest operating system based on the machine image from which the instance was cloned; an Amazon Machine Image (AMI) is a copy of the server that can be used to launch any number of instances, with at least an operating system along with common pre-installed tools; Region is a single geographic cluster made up of several availability zones; Availability Zones are virtual datacentres, which do not share any common points of failure; a Security Group is a group of machines governed by the same ﬁrewall; Block Storage volumes are similar to SAN (Storage Area 2.1. CLOUD COMPUTING SYSTEMS 21

Network) disks that can be attached to instances; and Snapshots that could be use to backup or replicate block volumes and store them in Amazon S3.

Region – Geographic Location

Availability Zone – Data center

Security Group

I Volume Snapshot AMI Instance

Figure 2.2 : Amazon EC2’s main components

Other Amazon services: Amazon AWS is a portfolio of products related with Cloud environments. Apart from EC2 and S3, there are additional services that provide additional support for storage (such as Amazon Elastic Block Store), databases (such as Amazon DynamoDB and Relational Database Service), networking (such as Amazon Virtual Private Cloud and Route53) and monitoring (with Amazon CloudWatch).

Rackspace It is another example of cloud platform that bills on a utility computing basis. It provides hosting capabilities similar to Amazon EC2. It was initially launched as Mosso LLC in 2006, but this name was dropped in favour of Rackspace Cloud in 2009. Finally in 2011 the word cloud was taken out from its name, resulting in Rackspace. As part of its services user can ﬁnd storage, cloud infrastructure, and even web platforms. The storage is offered through the service Cloud Files, that also offers Content Delivery Network (CDN) and it is quite similar to Amazon’s S3 service. Cloud infrastructure is provided with the service Cloud Servers. The technology behind this service was purchased by Rackspace in 2008, when they acquire Slicehost. Finally they also offer web platform functionalities in the service Cloud Sites, which supports web platforms such as PHP, Python, Perl, .NET, etc. 22 CHAPTER 2. STATE OF THE ART

The servers of Cloud Servers can be physically located in places such as Chicago, London or Hong Kong. According to [Clark 2010] both NASA and Rackspace donated technology to the OpenStack that provides IaaS functionalities such as Nova, which is a compute provider similar to Amazon EC2, and Swift, which offers cloud storage.

CloudSigma Its aim is to provide IaaS capabilities targeting the European market. As previous cases CloudSigma also employs a combination of an API and a GUI web console. Their business model is different from other existing solutions in the market because they sell four different products: CPU, RAM, data storage and data transfer. They offer standard subscription pricing but also have an on-demand burst pricing mechanism based on the utilisation of their cloud.

Windows Azure This is a cloud platform used to deploy web applications in Microsoft datacentres. It is mainly focused on offering PaaS capabilities, but in essence it also provides IaaS functionalities. The whole platform consists of several on-demand services hosted in Microsoft datacentres. These services are Windows Azure, which provides scalable compute and storage facilities, SQL Azure as a version of SQL server, and Windows Azure AppFabric, which is a collection of APIs supporting applications both in the cloud an on premise. Microsoft also offers CDN services within Windows Azure, in addition to libraries for .NET, Java and Node.js. There are several studies that also measure Azure’s performance. For example, in [Hill 2010] Hill et al. observed overall good performance of the Azure mechanisms and they proposed recommendations for potential users of Windows Azure based on their observations. Others have used Azure for developing science applications, e.g. in [Lu 2010] Lu et al. examine the best practices of handling the large scale parallelism and large volumes of data using Microsoft’s Windows Azure.

GoGrid This is a cloud infrastructure provider that provides the virtualization of Linux and Windows virtual machines. It also enables the management of these virtual machines through a web portal and RESTful APIs. Among their services cloud consumers could ﬁnd CDN, cloud storage, load balancers, dedicated servers and the possibility of locating virtual machines in different locations: San Francisco, and Ashburn. 2.1. CLOUD COMPUTING SYSTEMS 23

Terremark vCloud Terremark is’s vCLoud Express is another cloud infrastructure in which users can start virtual machines in a pay-as-you-go basis. The VMs are built on top of VMWare infrastructure, so they support a wide range of different operating systems running on them, including Windows servers. They also enables the management and conﬁguration of virtual machines through a web portal and through a RESTful API. And among other features they offer hardware load balancing, integrated ﬁrewalls, server cloning and redundant architecture. As an example the portal usa.gov, one of the busiest US government Web sites, was migrated to Terremark’s IaaS platform [Paquette 2010].

Joyent Joyent offers cloud infrastructure capabilities in addition to some PaaS environment using Node.js as development language. Originally they focused on providing a cloud suite of applications such as mail, calendar, and so on. In 2011, Joyent open sourced SmartOS, its specialized distribution of Illumos, along with its port of KVM (Kernel-based Virtual Machine). They are also supporters of these open source projects and of others like Node.js. As an example the Major League Baseball Advanced Media, the company that develops and maintains the Major League Baseball Web sites in the United States, decided to deploy their web sites on Joyent’s cloud infrastructure [Klems 2009].

Flexiscale Flexiscale was launched as the ﬁrst European product offering utility computing and world’s second Cloud Computing platform. It uses the open source Xen hypervisor, and technology from Sun Microsystems to provide the storage solution. Their current release of their service uses Extility, which is a fully automated software suite that enables managed service providers, hosting providers, and datacentre operators to offer cloud- computing services to their customers. It can use Xen, KVM or even VMWare hypervisors.

Skytap Skytap is a Cloud Computing platform which imports existing virtual machines and applications into a clou environment. Its infrastructure supports different hypervisors, such as VMWare and Xen, in addition to different operating systems like Microsoft Windows and Linux. It also provides customization management and automation capabilities for hosted systems. 24 CHAPTER 2. STATE OF THE ART

It also provides a virtual lab automation product as part of this solution. It provides virtual infrastructure on demand, a Web site in which users can manage the virtual lab, and a virtual machine library for creating new virtual machine conﬁgurations. Skytap offers the ability to access virtual machines from any location using a Web browser, including mobile devices.

ElasticHosts It provides a cloud infrastructure service from different datacentres, such as London, San Antonio, Los Angeles and Toronto. It is based on the KVM hypervisor, and provides a REST API to manage resources. Its billing model charges by CPU, RAM, Disk and Network rather than whole instances. They also offer separately their cloud sofware stack, which they use to provide their IaaS service.

ATT Synaptic Synaptic is an entire portfolio of cloud services, including utility computing, storage, PaaS capabilities and even medical imaging. For the service management they provide a web portal, but users can also use VMWare GUI and API interfaces because they use the VMWare hypervisor. Their features are VM cloning, the option of implementing public and private clouds, and network load balancing.

Google Cloud Storage It is an Infrastructure as a Service similar to Amazon S3 online storage service. It provides a RESTful web service API for storing and accessing data data on Google’s infrastructure. The management console is part of Google Labs and it is free until a limited quota. The functionality is comparable to Amazon’s S3 buckets and objects. Its features are the interoperability with other cloud storage systems such as Amazon S3 and Eucalyptus systems, consistency provided by atomic upload operations, access control based on access control lists (ACL) associated to buckets and objects, and resumable upload feature that allows users to resume upload operations after a communication failure has interrupted the ﬂow of data.

IaaS Provider’s Features

Table 2.2 summarizes some of the features commented throughout this section for all the vendors here commented and another taken from [Casalicchio 2011]. The table shows the billing model applied to every IaaS providers, the interfaces that are provided in each of these services, the 2.1. CLOUD COMPUTING SYSTEMS 25

Table 2.2 : List of Cloud Infrastructure Providers

Provider Billing model Interface type Load Balancing SLA Amazon EC2 1 hour SSH/GUI/API 99.95% AT&T Synaptic 1 hour SSH/GUI/API 99.9% CloudSigma 5 minutes SSH/GUI/API 100% ElasticHosts 1 hour SSH/GUI/API 100% FlexiScale 1 hour SSH/GUI/API 100% GoGrid 1 hour SSH/GUI/API 100% JoyentCloud 1 month SSH/GUI/API 100% Layeredtech 1 month SSH/GUI/API 100% Locaweb 1 month SSH 99.9% Opsource 1 hour SSH/GUI/API 100% Rackspace 1 hour SSH/GUI/API 100% ReliaCloud 1 hour SSH/GUI/API 100% RSAWEB 1 month SSH/GUI ND Storm 1 hour SSH/GUI/API 100% Terremark 1 hour SSH/GUI/API 100% VPSNET 1 minute SSH/GUI/API 100%

availability of load balancing mechanisms, which can be SSH, GUI (Web or through applications) and API interfaces, and ﬁnally the availability of the service in terms of their SLA agreements.

2.1.3 Cloud Computing Platforms

During this section we will analyse different Cloud platforms that enable the management of private and public IaaS infrastructures. Some of these solutions are based on standards or APIs from public cloud providers, so we will describe them as we comment their products. In [Voras 2011] Voras et al. evaluates different IaaS open source technologies, that we passed to comment here, with some other that is commercial.

OpenStack OpenStack is an Cloud infrastructure technology originally created by Rackspace and NASA, that is currently support by companies like Citrix Systems, Dell, AMD, Intel, Cisco, etc. It is open source and is released under the Apache License. It integrates part of the NASA’s Nebula compute platform and Rackspace’s Cloud Files service. Currently it consists of three main components: Compute (named Nova), Object Storage (Swift) and Image Service (Glance). But there are additional components such as Keystone for identity 26 CHAPTER 2. STATE OF THE ART management, or Dashboard, which provides a Web portal to manage Nova’s instances. Nova is the utility computing controller, which can be used by individuals or organizations to host and manage their own cloud computing systems. Its design guidelines are: component base architecture, highly available, fault-tolerant, recoverable, open to standards, and API compatibility. It also supports several virtualization standards including KVM, UML, XEN, Hyper-V and QEMU. Its upper APIs are bsaed on the Open Cloud Computing Interface (OCCI) standard that is deliverd through the Open Grid Foundation (OGF).

OpenNebula It is an open source software toolkit for cloud computing, which can be used to build and manage private, public and hybrid clouds. Its primary use [Sotomayor 2009] is as an orchestration tool for virtual infrastructure management in data-centers or clusters in private clouds and as merger of local and public cloud infrastructure supporting hybrid scalable cloud environments. It provides a complete management of virtualized datacentres to enable on-premise IaaS clouds based on VMware, Xen and KVM. It offers two different APIs to cloud consumers, the ﬁrst one is the OCCI standard, and the second one is equal to the one from Amazon EC2. Together with these APIs they also offer different system interfaces such as Ruby, XML-RPC and Java libraries to access different parts of their system. Different companies, hosting providers, public governments and research centers are currently using OpenNebula technologies in their datacentres. OpenNebula is also released under the Apache 2.0 open source license. Detailed functionalities can be found in several research papers such as [Sotomayor 2008, Milojic andic and 2011, Moreno-Vozmediano 2009].

Abiquo It is autility computing solution for virtualized environments. It is provided in open source and commercial versions, mainly differing in resource limits, management and support options. The open source version (Abiquo Community Edition) is released under the LGPL license, Version 3. Main features include multi-tenancy, hierarchical user management and role based permissions with delegated control, resource limits, network, storage and workload management, multiple public, shared and private image libraries. It supports many Linux distributions, Oracle OpenSolaris, Microsoft Windows, and Mac OS X servers. 2.1. CLOUD COMPUTING SYSTEMS 27

Red Hat Cloud Foundations, Edition One RHCF offers a suite of open source software which provides infrastructure for public and private cloud solutions. The suite consists of several products for virtualization and application management and scheduling.

Eucalyptus Open source cloud computing architecture Eucalyptus provides a scalable IaaS framework for implementation of private and hybrid clouds. It was initially developed to support high performance computing (HPC) research at the University of California, Santa Barbara, and engineered to ensure compatibility with existing Linux-based datacentres. It is component-based, ﬂexible and highly modular with well deﬁned interfaces. Eucalyptus implements the Amazon Web Service (AWS) API allowing interoperability with existing services, enabling the possibility to combine resources from internal private clouds and from external public clouds to create hybrid clouds Eucalyptus can be deployed on all major Linux OS distributions, including Ubuntu, Red Hat Enterprise Linux, CentOS, openSUSE, and Debian. Eucalyptus software core is included in Ubuntu distributions as a key component of the Ubuntu Enterprise Cloud. There are several research papers explaining different features of Eucalyptus, such as [Nurmi 2009]. Work in [Araujo 2011] investigates the memory leak and memory fragmentation aging effects on the Eucalyptus cloud-computing framework, which considers workloads composed of intensive requests addressing different virtual machines.

OpenQRM OpenQRM advertises itself as a data-center management platform. The core of openQRM follows the modern modular design and has no functionality itself, but instead focuses on abstracting storage and resources (computing resources, running virtual machines, VM images and other objects). OpenQRM provides a wide range of services, from integrated storage management, migration from physical to virtual machines in three combinations, abstraction of virtualization, high-availability, and VM image templates or appliances.

Nimbus It is another cloud computing infrastructure manager which targets the needs of the scientiﬁc community, but also supporting other business use-cases. The main component is the Workspace service which represents a standalone site VM manager with different remote protocol front-ends. 28 CHAPTER 2. STATE OF THE ART

Nimbus supports the Xen or KVM hypervisors, and virtual machine schedulers Portable Batch System and Oracle Grid Engine The main advantage of Nimbus compared to OpenNebula is that it exposes EC2 and WSRF remote interfaces with attention to security issues, and can be combined with OpenNebula VM manager. In [Marshall 2010] Marchall et al. implemented a resource manager on the Nimbus toolkit to dynamically and securely extend existing physical clusters into the cloud. And in [Hoffa 2008] Hoffa et al. used Nimbus to evaluate from the point of view of a scientiﬁc workﬂow the tradeoffs between running in a local environment and running in a virtual environment via remote, wide-area network resource access.

Claudia The Morfeo Claudia Platform is a service management toolkit that allows cloud providers to dynamically control the service provisioning and scalability in an IaaS Cloud. It provides an OCCI compliant API interface along with a Java library which uses this API to manage the platform. Claudia allows the conﬁguration of multi-vm components, virtual networks and storage support by optimizing the usage of them by dynamically scaling up/down services applying elasticity rules, SLA and business rules. Claudia evolution is supported by the research of Telefónica I+D on several research funded projects, such as Reservoir FP7 European project, NUBA Spanish Plan Avanza project, and is being used in other projects like FI-Ware FP7 European project.

Other technologies There are thousands of different technologies providing similar characteristics, such as CloudStack, mSOAIC, IBM SmartCloud, Nimbula, CloudFoundry, Scalr, Cloud.com, Abicloud, Cumulus, etc.

2.1.4 Related Cloud Research

Cloud Computing is being used in several projects, business, entertainment, industry and so on. In science it is being a wide area of for researching new use cases of traditional business models, or a new enabler for traditional technology areas such as high-performance computing, medical, videoconferencing, etc. In this section we will see related research work, starting with international projects that 2.1. CLOUD COMPUTING SYSTEMS 29 study new Cloud scenarios, architectures and its use in other topics. Then, we will see research evaluations of different cloud networks. This study will allow us to better understand part of the work of this thesis. Finally we will see results of new cost-optimal cloud scheduling mechanisms, with similar characteristics to the one proposed in this thesis.

Cloud-related Projects

There are many on-going cloud projects that we could mention. For example, StratusLab is focused on applying cloud technologies to grid infrastructures such as the European Grid Infrastructure (EGI) to enhance their use. The project is developing a complete, open-source cloud distribution that allows grid and non-grid resource centres to offer and to exploit an Infrastructure as a Service cloud. VENUS-C aims to explore how cloud computing can be used in European scientific settings . It brings together industrial partners and scientific user communities to develop, test and deploy an industry-quality cloud computing service for Europe. Some results has been already published as part of this work in [Livenson 2011]. The RESERVOIR project worked to enable massive scale deployment and management of complex IT services [Rochwerger 2009]. This project is now being used as a reference for cloud computing by several new European projects including StratusLab, BonFIRE and 4Caast. BonFIRE Project will design, build and operate a multi-site cloud facility to support applications, services and systems research targeting the Internet of Services community within the Future Internet. While the 4CaaSt project aims to create an advanced PaaS Cloud platform to support optimised and elastic hosting of Internet-scale multi-tier applications, mOSAIC project aims to develop an open-source platform that enables applications to negotiate Cloud services as requested by their users. And REMICS project [Mohagheghi 2010] will develop a tool-supported model-driven methodology for migrating applications to interoperable service cloud platforms. VISION Cloud project aims to build a scalable and flexible infrastructure for data-intensive storage services and enablers [Gogouvitis 2011]. This infrastructure will facilitate a new data model to raise the abstraction level of storage, data mobility, computational and content-centric access to storage as well as mechanisms for cost-efficiency with provisions for QoS and security guarantees. On the other hand, Contrail project aims at removing some constraints that are currently present in cloud systems. It will federate clouds allowing companies and research 30 CHAPTER 2. STATE OF THE ART organisations to easily switch between cloud providers. Regarding legal implications of Cloud models, the Cloud Legal Project at Queen Mary University in London is a three year project which will produce a series of papers to act as informative and practical guides to the legal issues that need to be addressed by customers, providers and regulators of cloud computing. And for security concerns TCLOUDS puts its focus on privacy protection in cross-border infrastructures and on ensuring resilience against failures and attacks. Finally, the FI-Ware project aims to provide a framework for development of smart applications in the Future Internet. The FI-WARE platform is being developed as part of the Future Internet PPP initiative launched by the European Commission in collaboration with the ICT Industry.

Clouds’ network performance

There is work related to analysis of the network I/O performance for applications in the cloud that focus on searching a way to optimize resource sharing, e.g. [Mei 2010] Mei et al. explain this considering the throughput and resource sharing effectiveness as parameters. Other research [Sivathanu 2010] conduct performance measurements of the storage management addresses, both for the application and the service providers to achieve increased efficiency in I/O performance, resource provisioning and workload scheduling. In [Garfinkel 2007] they perform an analysis of EC2’s management and security facilities in the same time considering evaluation measurements of Amazon S3 and SQS, finding EC2 good enough when considering cost-time trade-off. Deelman et al. [Deelman 2008] study the cost-performance analysis of various execution plans used by the same application example. They show that good choice of both storage and compute resources reduces cost which does not affect the application performance. As a work to basically examine the use of cloud computing in science, ”Nimbus Science Cloud” has been pointed out as an example cloud provider for scientific means. In [Chan 2009] authors offer a semantic analysis for modelling and testing applications in the cloud through a cloud graph model, that can be used to dynamically compose cloud computations. Research as [Pereira 2010], are of high interest for our work because their Split&Merge architecture used for encoding time of high performance video could serve us as a guide for treating the video streams in the cloud i.e., coding/decoding and evaluating the cost of 2.1. CLOUD COMPUTING SYSTEMS 31 this operation. Finally, Ang Li et al. [Li 2010a] have recently designed a tool that offers the possibility of comparing several aspects among various cloud providers by taking into consideration parameters such as, CPU velocity, I/O of the disk and latency, bandwidth and response time. The main objective is relating their performance and compare the cost each of them imports.

Cost-optimal cloud scheduling

Several research groups have based on cloud business model to propose new ideas and challenges in the area of cloud computing. For example In [Balazinska 2011] the authors mention the opportunities the cloud market has by enabling fine-grained data pricing basing on products like CloudSigma. [Lucas Simarro 2011] proposes a scheduling model for optimizing virtual cluster placements across available cloud offers, while using some variables such as average prices or cloud prices trends for suggesting an optimal deployment. The authors in that paper say that some cloud vendors like CloudSigma have different business models from the fixed prices that rarely change in time. There are others, like the dynamic prices that fluctuate based on demands, day or week periods, and even spot prices that are based on user’s bids. They developed a cloud broker that allow the cloud consumer to save costs basing on these models and calculating average prices during different periods. Same authors also mention similar conclusions in [Tordsson 2012], where they propose an optimal placement of hosts among multiple cloud providers saving costs. These cost-efficient approach is achieved by choosing the best performance-price cloud rate among multiple cloud providers. They concluded their work that a cloud-scheduling algorithm should consider price and performance parameters, while trying to model the deviations in cloud provider performance over time. In [den Bossche 2011] authors propose scheduling heuristics for saving costs in the context of deadline constrained workloads on hybrid clouds. Their work was based on cloud vendors that do not have fixed instance types, and allow users to customize and fine tune the cloud servers to fulfil the exact hardware needs of their applications. Related research where mathematical programming techniques are used for multi-cloud scenarios include work by Chaisiri et al. [Chaisiri 2009] who use stochastic integer programming to both minimize the cost of renting virtual machines from public cloud providers and handle uncertainty in future prices and resource demands. Breitgand et al. [Breitgand 2011] present a model for service placement in federated clouds, in which one 32 CHAPTER 2. STATE OF THE ART cloud can subcontract workloads to partnering clouds to meet peak demands without costly over- provisioning. In [Andrzejak 2010], a decision model is presented to determine bid prices on a resource market with varying prices, such as Amazon EC2’s Spot Instances. Resource provisioning policies for multi-grid environments are also studied, e.g., by Assunçao and Buyya [de Assunção 2009]. They analyse provisioning policies that incorporate the cost of resources and demonstrate how a grid can redirect requests to other grids during periods of peak load through a cost-aware load sharing algorithm. Although the use of cost-aware multi-provider scheduling has been explored extensively for Grid environments [Abramson 2002], anomalies, e.g., problems due to the use of artificial currencies [Nakai 2001], suggest such techniques are more promising for clouds, where resource consumption is based on real financial compensation.

2.2 Technologies for Rich Internet Applications

Desktop applications are often characterised for a rich user experience and complex user interfaces (UI) such as menus, full-screen windows, drag and drop functionality, etc. These UIs does not compromise the performance of the user platform where they are deployed. Since the appearance of Internet and more recently advanced mobile phones and tablets the user community is not localised and the application has to be used across networks with different security constraints. Besides, the increasing number of clients with different hardware and operating system makes the installation, maintenance and access ﬂexibility difﬁcult. On the other hand Web applications lack for these problems because they are based on standards implemented by different web browsers. The traditional Web applications are based on client-server architecture which runs the control and logic in the server side while the client only replaces the presentation layer in the application. Thus, there is no need for installations and updates on the client side. Their main disadvantage is the static view style, the poor interaction and the lack of rich interfaces of the application. Rich Internet Applications (RIA) are Web applications that typically run in a web browser as part of a web site. But this type of applications share several characteristics with traditional desktop applications, and can be accessed using only the web browser with the use of JavaScript, via a browser plug-ins or sandboxes. Nowadays in most cases they generally force the users to install a plug-in before launching the application. Once installed, the application runs inside a sandbox that is delivered within the plug-in. 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 33

The rise of RIA entailed new advantages in web-based interactions:

1. Better responsiveness and information ﬂow: Once downloaded the user does not need to reload the whole page to move to next step. The communication between RIA client and server is then based on protocols and technologies like SOAP and REST, which send information over HTTP. The information sent with these protocols is usually formatted within XML and JSON documents. Furthermore they also allow the client to synchronously communicate with server and even other clients.

2. Enhance interactivity: Typical RIAs offer better interactivity with new features like drag and drop and other desktop-based functionalities. These functionalities are linked with the term of Web 2.0, that refers to the market shift in consumer attention from expert-generated content to user-generated content.

3. Improve the user experience: The fact of visiting a web page without the need of load the whole web page often reduce the number of required clicks and waiting time between them.

4. Provide more usability: RIAs create a greater sense of involvement and more control over their interaction due to ease of visualizing products, customizing offerings, and personalizing services.

The use of RIA technology does not provide the perfect solution for all scenarios. It is still evolving and presents the following disadvantages:

1. UI Richness: Although RIA is meant to provide better user experience than traditional web pages it cannot compete with traditional desktop applications in all fronts. An example is the market of games and other native graphical applications.

2. Sandbox: The use of a sandbox presents a restricted access to system resources.

3. Client processing speed: Several RIA frameworks use client-side scripts written in interpreted languages, which performance is still lower than compiled client languages.

The RIA plug-in installation, update, and maintenance are carried out by the plug-in developers. In most cases they advertise about the need of installing the plug-in or even about new updates that are available. In other cases they are already installed as part of the web 34 CHAPTER 2. STATE OF THE ART browser. Generally all plug-in developers recommend to install the last version of each technology because they usually made changes in the form of security ﬁxes, bug ﬁxes, and new features.

Prior to view a list of Rich Internet Application frameworks, the reader should know that a framework is a collection of software libraries providing an application programming interface (API), which provide generic functionality that separate them from other normal libraries. In a framework the control and logic reside in the framework itself and not in the caller. The framework usually has a default behaviour in case the caller does not provide speciﬁc information and it can contain extensible parts that can be overridden by the developer.

In the case of RIAs there is an extensive list of software frameworks that can be useful in different contexts, with different programming languages and operating systems. Although the vast majority are intended to run over almost all the operating systems.

Frameworks are linked to RIA technologies like Adobe Flash, Microsoft Silverlight, Oracle Java FX, AJAX or HTML5. Thus, they have to be installed on clients that are going to run these applications. Regarding to the installation there are several studies that depict the market penetration and global usage comparing different technologies. These studies show that Adobe Flash, Microsoft Silverlight and Java are installed in more than 60% of machines.

100% 90% 80% 70% 60% 50% 40% 30% Flash Player 20% Java FX 10% Silverlight 0% JUL ’08 DEC ’08 MAY ’09 OCT ’09 MAR ’10 AUG ’10 JAN ’11 JUN ’11 NOV ’11

Figure 2.3 : Percentage of clients with RIA sandboxes installed

Figure 2.3 depicts the percentage of clients that has already installed each RIA sandbox (Adobe Flash Player, Microsoft Silverlight and Oracle Java FX). The source of this ﬁgure was obtained in 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 35

Table 2.3 : List of Rich Internet Application Frameworks

Adobe Microsoft Oracle JavaScript HTML5 Flash Silverlight JavaFX Toolkits Programming .NET AS 3.0 Java JavaScript JavaScript Language Framework UI Deﬁnition HTML / HTML / MXML XAML FXML Language CSS CSS Open Source a b Accelerated Graphics Animations Ofﬂine Mode Media Streaming Videoconf. c Capabilities Wide Mobile d e f Support Without plug-in installation Cross-browser g Compatibility

aThere is an Open Source version called Adobe Flex SDK bThere is an Open Source version of Silverlight called Moonlight that can be used in Linux cAlthough there is a draft speciﬁcation, there are not any implementation dIn the case of iOS-based devices there is only support for Flash native applications eSupported only in Window Phone 7 fSupported only in BlackBerry gThere are some differences between browsers because HTML5 is currently under development

ii. This information was obtained from several web sites. They run specialized code for gathering information about sandboxes installation among many other data statistics. In the ﬁgure we can see how Flash Player is installed in the 95% of user browsers, while Java FX is installed in the 76.57% and Microsoft Silverlight is in the 67.36%. But there are also differences between them if we see the variation during time. In the case of Adobe Flash Player it has kept its value since 2008, while number of Oracle Java FX installations have been notably reduced and Microsoft Silverlight has increased.

iihttp://www.statowl.com 36 CHAPTER 2. STATE OF THE ART

The remainder of this section shows the most important RIA technologies that the reader could ﬁnd nowadays. In each subsection we will focus on their descriptions and we will discuss the main advantages and disadvantages for every technology.

2.2.1 Adobe Flash Player

Adobe Flash is a RIA platform that uses a proprietary runtime engine to add animation and interactivity to RIAs by compiling functionality into Flash code that a just-in-time plug-in interprets. It is mainly based on an object-oriented language named ActionScript. Flash generated content is usually used to display advanced dynamic Web pages. Flash technologies are used for a wide variety of areas, such as advertisements, games, and general application. Users need to install the Flash Player plug-in in order to run the generated content, but there are some web browsers that already have installed the plug-in previously. The Adobe Flash Player is available for common web browsers running on conventional desktop computers, some mobile phones (especially those with Android operating system installed), TV sets and even electronic devices. When the Flash Player starts running the application it manipulates vector graphics to provide animation to various components like text, drawings, images, and UI objects. It also provides advanced APIs such as the possibility to manipulate images directly, audio and video. It supports multimedia streaming applications such as video and audio streaming as well as bidirectional multimedia communications. When a developer creates and compiles an application using Adobe Flash tools they generate bytecode and control tags within a ﬁle with the extension .swf (Shock Wave Flash). Then, this ﬁle has to be located in a web server accessible from all client machines, and when a user loads a page which is referencing the .swf the browser loads it and gives it to the Adobe Flash Player. This plug-in contains the ActionScript Virtual Machine which translates the bytecode into machine code and displays the result in the browser.

History Flash was originally created by Jonathan Gay in January 1994, who created the company FutureWave Software to dominate the market for graphics software on pen computers. Its ﬁrst application was SmartSketch, software that helped people to draw on pen computing (writing on the screen with an electronic pen rather than using a keyboard). The failure of pen 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 37 computing made him to port its application to the Windows and Macintosh platforms. In 1996 they released a new application named FutureSplash Animator, editor that could produce animations for web pages. It added support for timeline animation and they developed a Netscape browser plug-in for playing back content.

In August 1996 Microsoft and Disney started using their application, and Macromedia bought FutureWave Software. The result was that FutureSplash Animator became Macromedia Flash 1.0. Macromedia updated Flash for several times until Adobe Systems purchased them in 2005.

The support given by Flash to create advertisements in addition to the arrival of Youtube in 2005 made Flash one of the most widely distributed piece of software on the Internet. It is over the 95% of Internet-enabled PCs as we saw in ﬁgure 2.3.

In 2004 Adobe created a software development kit (SDK) to write Adobe Flash applications. This SDK can be used through an Adobe’s proprietary IDE or through a freely available Flex compiler. Since 2004 subsequent releases of Flex has been published with additional features, such as a Java EE integration application known as Flex Data Services or another application server named BlazeDS. In 2011 Adobe open-sourced Flex and donated it to the Apache Software Foundation.

Advantages During years Flash has been used for a wide variety of web applications, especially for games, animation, shopping carts, vector graphics, video and sound effects:

• The main advantages of Adobe Flash technologies are that it is a mature technology, whose plug-ins are installed in almost every web browser and with a wide developers’ community. Due to its plug-in Flash is browser independent, it has no issues with cross browser compatibility. Thus, no developer has to worry about HTML and CSS code being interpreted differently in different browsers. As long as the Flash Player is installed on the user’s computer she will be able to view Flash content with no issues.

• Flash supports audio, animation, and advanced video handling and even interactivity. Flash is vector-based but also allows the use of bitmaps when required. Today, it is still the only technology that provides enough media support for developing RIA applications with videoconferencing capabilities. 38 CHAPTER 2. STATE OF THE ART

Disadvantages In recent years the use of Flash has been reduced due to several limitations Flash presents comparing to other solutions:

• The strongest limitation is that Flash Websites require installing the Flash player plug-in. If the player is not installed or if it is not the correct version then the user will be required to download or upgrade the Flash player.

• Most mobile devices, especially Apple based devices, such as iPhone do not display Flash content. And according to Adobe the support of Flash for Android mobile devices will be discontinued. And this is a market that cannot be ignored.

• Flash applications usually consume more CPU and RAM than other RIA technologies, especially on machines that are running Mac OS X and UNIX. This presents a strong limitation in applications with video or games that uses more CPU than others.

• Accessibility could be a problem in Flash applications unless they are properly coded. Most Flash websites lack alternative text and can be difﬁcult for screen readers. Users are not able to scale the text font size, the back and forward buttons usually do not work. Unless the developer adds the proper code only the main page of the Flash applications can be bookmarked. And there are a lot of problems with different keystrokes in Flash websites.

• On November 2011 Adobe announced that they will support no more the development of Flash plug-in for mobile devices that run newer operating systems or different versions of their web browsers. They only would update the existent versions of their plug-in with security patches. Thus the future is not clear for Flash in an Internet that is slowly becoming more mobile prominent.

2.2.2 Java FX

Java developers can use JavaFX to write RIAs that run across multiple platforms. The current release allows developers to build applications for desktop, browser and mobile phones. Furthermore TV set-top boxes, gaming consoles, Blu-ray players among other platforms are planned to support this technology. A developer would use Java to code applications in addition to FXML, which is an XML- based declarative markup language for deﬁning user interface in a JavaFX application. JavaFX 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 39 provides different APIs coded in Java for accelerating graphics with GPUs, rendering videos and playing audio ﬁles, controlling different UI components such as tables, tree views, buttons, forms, labels, and so on, embedding web contents in the JavaFX applications, and animating transitions between different views. Once the developer has coded a JavaFX application it is compiled to Java bytecode, so JavaFX applications run on any desktop and browser that runs the Java Runtime Environment (JRE) and on top of mobile phones running Java ME. Current releases on desktop have been implemented for Windows and Mac OS X, and there are beta versions for Linux and Open Solaris. On mobile JavaFX is compatible with Windows Mobile and Symbian OS.

JavaFX Public API’s and Scene Graph

Quantum Toolkit

Prism Glass Windowing Web Media Engine Toolkit Engine Java 2D Open GL D3D

Java Virtual Machine

Figure 2.4 : JavaFX 2.0 Architecture Diagram

Figure 2.4 shows the architectural components of the version 2.0 of JavaFX platform. Below the JavaFX public APIs lies the engine that runs the JavaFX code. This engine is composed of a high performance graphics engine named Prism; a windowing system called Glass; a media engine and a web engine. Below all these parts of the engine lies the Java Virtual Machine and all its APIs.

History JavaFX born when Sun Microsystems announced it at the JavaOne Worldwide Java Developer conference on May 2007. In the last quarter of 2008 Sun released Java FX 1.0, with a SDK that worked for Windows and Macintosh. In these versions the platform was focused on a new scripting language called JavaFX Script. Throughout 2009 versions 1.1 and 1.2 were released. They incorporated support for Linux and Solaris, built-in controls and layouts, skins, chart widgets, and several improvements. In 2010 40 CHAPTER 2. STATE OF THE ART

Sun released versions 1.3 and 1.3.1, with more improvements, especially for application startup, with custom progress bars and quick startup time. In 2011 Oracle (that previously had bought Sun Microsystems), release the ﬁrst beta of JavaFX 2.0. This beta is available for 32 and 64 bits versions of different Microsoft Windows versions, and for Mac OS X. There where no support for Linux then. The current release (version 2.0) was released on October 2011, and it introduced a new set of Java APIs and support for high performance lazy binding, binding expressions, etc. In this version a new declarative XML language called FXML was introduced. And they changed the core language from the JavaFX Script to pure Java.

Advantages The main advantages of JavaFX are the use of Java and the possibility of using the same applications out of the browser:

• The main beneﬁt nowadays is that developers do not need to learn any other language to create JavaFX applications if they already know Java, because JavaFX applications are completely developed in Java.

• The fact of being running on the Java runtime environment, which is installed on more that 97% of enterprise desktops worldwide, makes that these applications can be deployed on a wide set of desktops and even mobile devices around the world.

• It currently provides a rich set of graphics and media API with high-performance hardware- accelerated graphics and media engines, which simpliﬁes the development of games and advanced interfaces. JavaFX also contains a WebView component to embed any web content in our JavaFX applications. This component uses WebKit to render web content.

• Every application developed with JavaFX can be deployed on desktop or in web browser. In the case of the browser JavaFX plugin provides applications a secure way to run inside a browser, while in the case of desktop JavaFX applications can experiment better performance and operating system integration.

Disadvantages Main disadvantages of JavaFX are caused by the native support in different devices and the lack of videoconferencing APIs: 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 41

• Although JavaFX is supported by a well-known programming language such as Java, there is still a growing set of devices that does not have the Java runtime environment installed on it. This is the case of advanced mobile devices. In the case of iOS based devices they do not have installed any type of Java virtual machine and anything similar, Android devices convert Java bytecode to a more optimised bytecode and they would need another JavaVM installed, which is not installed by default in any device. In the last JavaOne developer conference Oracle demonstrated JavaFX running on iOS and Android but it has not been ofﬁcially approved by Apple yet.

• Furthermore, JavaFX does not provide a competitive native API to access device cameras and send the video stream to other peers. So it makes difﬁcult for the developers to choose this solution when deciding among others.

2.2.3 Silverlight

Silverlight is a programming framework with similar characteristics to Adobe Flash and JavaFX. Microsoft released the ﬁrst version in 2007 and focused it on streaming media, graphics and animation. Its runtime environment is available in a plugin for web browsers running in devices with Microsoft Windows or Mac OS X. It is also available on Windows Phone mobile devices.

Silverlight applications are developed with two programming languages: Extensible Application Markup Language (XAML) for the definition of user interfaces and .NET Framework for the control and logic. In this case the application can be written in any .NET programming language, so any development tool that can be used for programming applications in any of the .NET languages can be also used to program Silverlight applications. Visual Studio can be used to develop and debug these applications. Once compiled every Silverlight application is encapsulated in a XAP file, that contains a list of DLL files and an application manifest with information about the list of files.

According to ﬁgure 2.3 its penetration has been growing up to 70% in November 2011. And there are plugins available for the main web browsers in both Windows and Mac OS X. Microsoft is ofﬁcially supporting another project called Moonlight, which is an open source implementation of Silverlight for Linux and other UNIX-like operating systems. 42 CHAPTER 2. STATE OF THE ART

History First version of Silverlight was released in 2007. This version only consisted on a core presentation framework, which is focused on handling user input from devices such as keyboard and mouse; managing rendering of bitmap images, vector graphics, text and animations; streaming of audio and video ﬁles; supporting the creation of graphical user interfaces with XAML markup language. In 2008, the second version of the platform included support for programming in any language of the .NET framework; and the UI core was improved with more than 30 UI controls, the media unit integrated supported more codecs, DRM, playlists, and extensible support for other protocols and delivery methods such as adaptive streaming or peer-to-peer. Silverlight 3 was released on May 2009 with even more UI controls, support for hardware-accelerated H.264 video encoding and third-party video codecs, use of GPU for accelerating the visualisation, and support for ofﬂine execution of its applications by installing them on the desktop without the needed of web browsers. The fourth version was released 2010 with support for more web browsers, webcam and microphone access, rendering of HTML inside Silverlight applications, etc. Silverlight 5, which was released on December 2011, included new features such as support for GPU accelerated video decoding, improved data binding between elements, 3D graphics, support for 64-bit browsers, and faster application startup.

Advantages Some advantages of using Silverlight are similar to the ones shown before in the case of Adobe Flash and Oracle JavaFX:

• The use of plug-in means that developers can create Silverlight applications that are going to be automatically compatible with different browsers, operating systems and versions. Adobe Flash and JavaFX have the same advatange. The ofﬁcial support for Moonlight gives the possibility of programming without any proprietary requirement.

• Comparing to Adobe’s MXML language Silverlight plug-in interprets XAML directly, so it is included in the XAP ﬁles and it is potentially easy for search engines to index text within a Silverlight application.

• There is support for third-party extensions and add-ons in Silverlight, such as more video codecs, protocols, etc. Besides, developers has a wide range of programming languages as part of the .NET framework. 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 43

• Last versions of this platform allow users to execute the same Silverlight applications outside the browser, offering advanced APIs with a different level of restrictions.

Disadvantages In the case of Silverlight the main disadvantages come from being a proprietary RIA solution:

• It does not natively implement several open standards for videoconferencing applications like in the case of Adobe Flash. This, together with the lack of third party libraries for implementing videoconferencing applications does not help to newer videoconferencing developers, who initially choose other technologies such as Flash or even HTML5.

• Regarding the penetration of Silverlight in dekstops it is installed in less browsers and desktop operating systems than Flash or JavaFX, and regarding the mobile devices it is only supported in Windows Phone devices. In fact, although they support Moonlight the Linux implementation will always lag behind the Windows and Mac releases.

2.2.4 AJAX Frameworks

The word AJAX is the acronym for Asynchronous JavaScript and XML. With AJAX all the applications can send data to a server and receive data from it asynchronously without interfering with the rest of the web page. Its main feature is the XMLHttpRequest object, that is offered as part of the JavaScript API, and allows the asynchronous transfer of information between the web application and the server. AJAX frameworks are used to develop Rich Internet Applications with a set of web development technologies that are used on the client-side to create a new generation of web applications related with the RIA principles. These frameworks are mainly coded in JavaScript, but there are other client-side languages such as HTML and CSS that are part of them. Contrary to the previous RIA technologies JavaScript is a web standard and thus, can be used in any web browser without the need of installing any kind of plug-in. But there are also other technologies such as HTML, CSS, XML, Document Object Model (DOM), XML, JavaScript, and JavaScript Object Notation (JSON). Nowadays there are different AJAX frameworks which leverages AJAX together with other client-side and server-side components to process the client’s requests. There are examples of 44 CHAPTER 2. STATE OF THE ART these frameworks for almost every programming language, such as jQuery, Dojo Toolkit, Prototype for JavaScript programming, Google Web Toolkit, Apache Wicket or AribaWeb for Java, Wt for C++ applications, etc. The most available features in these frameworks are: XMLHttpRequest, JSON retrieval, Drag and drop, event handling, animation and visual effects, rich text editors, autocompletion, HTML generation tools, skins, templates, GUI resizeable and page layout, canvas support, mobile and tablet support, ofﬂine storage, charting, etc. And the main requirement for every developer is the cross-browser compatibility.

History Previously to the creation of AJAX, user interaction with web pages required a total reload of the complete page, making the process inefficient and a bad user experience. The only asynchronous communications could only be implemented using a plugin with Flash, or a Java Applet. Between 1996 and 2005 there were different non-standard solutions to this problem, such as the iframe element of Internet Explorer for asynchronous loading parts of a web page, the creation of the XMLHTTP by Microsoft in 2000, which was later adopted by several browser vendors as the XMLHttpRequest JavaScript object. This feature was supported by important web applications such as Outlook Web Access, GMail, Google Suggests, and Google Maps. On April 2006 the World Wide Consortium released a first draft specifying the XMLHttpRequest object in order to eventually create the official web standard. On the other hand JavaScript was originally created by Netscape in 1995, and standardized by the Ecma International as ECMAScript in 1996, and has become one of the most popular languages on the web, used not only inside of web browsers, but also on server-side platforms.

Advantages The main advantages presented by these platform are:

• There is no need of installing any plug-in in web browsers in order to execute these web applications, so it improves the user experience and potentially reduces startup times. In addition it does not rely on third party plugins to implement some security concerns, so all the security aspects remain on the browser side.

• The fact of being a web standard helps a wide group of different platforms to arise, given the developers the chance of decide which platform better meets their requirements. And it 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 45

automatically imposes all the browser vendors to implement at least a wide range of features that are part of the standard.

• Nowadays there are extensions for almost every web browsers that allow the developers to extend functionality to web pages and even access computer’s features that are restricted to normal web pages, so every developer could implement advanced JavaScript applications by using these extensions.

Disadvantages The particular implementations that every web browser makes of the JavaScript standard causes some disadvantages comparing to previous solutions:

• Taking into account the web browsers and their different JavaScript layout engines, they may render the code differently resulting in inconsistency in terms of functionality and interface layouts. This problem has been partially solved in the latest versions of JavaScript, but certain variations still exist.

• Historically several JavaScript snippets appended onto web pages and executed on client browsers immediately have been used to exploit vulnerabilities presented in the user’s system. In the recent years web browsers and web standards have restricted the access from these applications, but malicious code can still be executed.

• JavaScript performance is worse in some aspects than other solutions due to the lack of hardware-accelerated graphics, although some parts have been improved with the latest JavaScript engines, such as V8 or SunSpider.

• Comparing to other solutions, the most important feature that is not presented in these frameworks is the multimedia representation of videos and audios, and the lack of any videoconferencing capability in JavaScript.

2.2.5 HTML5

This is the ﬁfth revision of the HTML standard, intended to subsume HTML4, XHTML and a set of APIs with new features which provide multimedia capabilities to the web browsers, in addition to new semantic contents of documents, graphical elements and attributes. 46 CHAPTER 2. STATE OF THE ART

A HTML5 developer has to know a group of languages, protocols and standards. Main languages are JavaScript and HTML, which have been extended with new APIs. New protocols are WebSocket, typical VoIP protocols, etc. And there are new standards associated with HTML5 speciﬁcation like WebSocket, RTP, and so on.

There are also new APIs, such as a ofﬂine web applications, Web Storage, Web Intents, Drag- and-Drop features, Cross-document messaging, Canvas elements with 2D and 3D capabilities, WebGL, Web Sockets, document editing, P2P Connections, Audio and Video playback from ﬁles and real time streaming, Microdata, etc.

History The work of standardizing HTML5 began in 2004. Opera, Mozilla and Apple decided to jointly work in this standard. They created a new group called the Web Hypertext Application Technology Working Group (WHATWG) because initially the W3C rejected the proposal presented by Mozilla and Opera. At that time W3C was more focused on continue developing XML-based replacements for the previous HTML version (HTML4.0).

The specification at WHATWG was intended to be backwards compatible, matching both specifications and implementations even when the implementations forced to change the specifications, and that specifications need to be enough specifics to achieve complete interoperability between implementations.

In 2006 the W3C decided to participate in the development of HTML5 after all, and they created a new working group to work together with the WHATWG on the development of such speciﬁcation. At the same time W3C decided to continue the work in the XML version with the old group of HTML, but they are independent from each other.

The HTML speciﬁcations published in W3C and in WHATWG are not identical. The main differences are that the WHATWG include features that have been omitted as they are considered future revisions of HTML, not in HTML5. Besides there are other features that have been published in separate speciﬁcations.

The specification of HTML5 is an ongoing work, and is expected to remain so for many years, although parts of HTML5 are going to be finished and implemented in web browsers before the whole specification reaches final Recommendation status. Figure 2.5 depicts different APIs that are part of the overall HTML5 specification. 2.2. TECHNOLOGIES FOR RICH INTERNET APPLICATIONS 47

HTML5 SVG MathML Selectors Taxonomy & Status (December 2011) 3.0 L1 Navigation CSS3CSS3 Timing W3C Recommendation Navigation Web Timing Storage Candidate Recommendation HTML + Indexed Web SQL RDFa Database XmlHTTP Last Call Request 1

Media Web Working Draft Capture Messaging Geo Canvas Web Location Sockets Non-W3C Specoifications 2D File API HTML Contatcs Drag Deprecated W3C APIs Markup API Audio and Video Drop Touch Events Web Micro WebGL Workers data Calendar API HTTP Caching Animation Timing RDFa Device Orientation WAI-ARIA

By Sergey Mavrody 2011 | CC Attribution-ShareAlike 3.0

Figure 2.5 : HTML5 APIs and related technologies

Advantages Main advantages of HTML5 solution are:

• HTML5 is part of the HTML standard, which includes detailed speciﬁcations to encourage more interoperable implementations between different web browsers and devices. Furthermore many of its features are being built considering them for being run on low-powered devices such as advanced mobile phones and tablets.

• Every HTML5’s API and technology will be implemented on well-known web browsers, so there will be no further requirements of installing additional plug-ins or extensions. All the user will have to do in order to run the application is to load a web page using any web browser.

• APIs shown in Figure 2.5 are quite similar to the ones presented in other solutions, such as Microsoft Silverlight and Adobe Flash. There will be advanced features such as media 48 CHAPTER 2. STATE OF THE ART

streaming, videoconferencing capabilities, accelerated graphics for 2D and 3D animations, etc.

Disadvantages The main problem of HTML5 arises because it is an ongoing standardization work:

• HTML5 is a work-in-progress, so there are still different parts that are not implemented in many or any web browser. Examples of these features are the videoconferencing API, WebGL which will be a library to generate interactive 3D graphics within any compatible web browser, and those shown in Figure 2.5 as Working Draft.

• There will be some fragmentation among different devices. This could happen especially in mobile devices which could have different features in the future.

2.3 Multiparty Videoconferencing Systems

This thesis tackles the implementation of multiparty videoconferencing systems using technologies of Web 2.0 and Cloud Computing. It makes use of current mechanisms, protocols and services, which enable videoconferencing capabilities for the participation of multiple users. In this section we will study deﬁnition, history and state of the art of these systems. A multiparty videoconferencing session is the conversational exchange of multimedia content between several participants. Traditionally this multimedia content consists of audio, video data and messaging, and a participant is anyone who wants to participate in the videoconferencing session. Systems implementing this service implement different components that enable the organization of conferences a meetings. These components would be:

• Signaling: This component provides functionality to invite participants and get their conﬁrmation to attend. It also establishes and terminates the conference. Typical protocols used within this component are SIP and H.323.

• Media Control: Enables the negotiation of which media is going to be used by each participant and prepares the different media devices, such as microphone and webcam. For content negotiation SDP is the most used protocol among different applications. 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 49

Conference Application

Signaling Policy Control Floor Control

Media Control

Media Handling

Figure 2.6 : Multiparty Videoconferencing Technical Components

• Media Handling: Once the conference is established this component is responsible for any coding and transcoding different media formats and protocols. It also makes the media transmission and mixing of any media ﬂow. Possible protocols would be RTP/RTCP, SRTP, etc.

• Policy Control: This component helps in the decision of which participants could attend the conference, time, agenda and log in the conference room. Protocols like Conference Policy Control Protocol (CPCP) could be used in this context.

• Floor Control: It is intended to be used by the conference chair, who will decide who can talk at each time. It could make use of Binary Floor Control Protocol (BFCP), Talk Burst Control Protocol (TBCP) and description ﬁles such as Floor Server Control Markup Language (FSCML).

Next section brieﬂy describes the history of these systems, starting from the early ages of videoconferencing systems, the work of different standardization groups, and the current appearance of Web 2.0 and cloud computing actors.

2.3.1 History of Multiparty Videoconferencing Systems

Origin of the Videonferencing Systems

The invention of videoconferencing is related to the inventor of telephony, Alexander Graham Bell. The New York Times in [Times 1927] quoted his own words: "The day would come when 50 CHAPTER 2. STATE OF THE ART the man at the telephone would be able to see the distant person to whom he was speaking". Actually he also proposed the possibility of making video transmission in [Bell 1891]. Although experimental videophone installations and calls have been made since the late 1920’s, its evolution suffered several more years of delays due to the World War II. In early 1934 the world’s first public video telephone service was developed by Dr. Georg Schubert [Independent 1934] and the German Reichspost opened it to the public in 1938. But, it quickly closed in 1940 due to the World War II. In that service trial, video telephone lines linked Berlin to Nuremberg, Munich, and Hamburg, with terminals integrated within public telephone booths and transmitting at the same resolution as the first German TV sets, at 440 lines. The next commercial product was introduced by AT&T in 1964, with the name of Picturephone. Its initial offering cost $169 (equivalent to $1000 of today’s US dollars) for installation and $169 each month, and its price was dropped to $75, that today would be $460 because of the inflation. The greater 1 MHz bandwidth and 6 Mbit/s bit rate of Picturephone also did not cause the service to prosper. Figure 2.7 represents the video telephone station, which is composed of elements that capture audio and video, elements that reproduce audio and video from the other end, and a media control unit. The media control unit allowed the user just to mute his camera, and microphone.

PBX

Display and Video Capture Device

Media Control Unit Audio Device Telephone

Figure 2.7 : AT&T’s Picturephone component diagram

In 1976 Nippon Telegraph and Telephone implemented videoconferencing between the cities of Tokyo and Osaka. And some years later, in 1982, IBM Japan established a videoconferencing 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 51 with a bit rate of 48 kbps for internal weekly business meetings in IBM in the U.S.

The era of IP videoconferencing

In 1976,a new Network Voice Protocol (NVP) [Cohen 1977] was published. The major goal of this protocol was to demonstrate a digital high-quality, low-bandwidth, secure voice handling capability as part of the general military requirement for worldwide secure voice communication. A bit later, in 1981, a set of extensions to NVP, consisted mostly of a data protocol for transmission of video data, were developed in the Packet Video Protocol (PVP) in 1981. On those dates the Internet Protocol (IP) and Transmission Control Protocol were widely used in the ARPANET for data-oriented packet communication. These protocols, however, were inappropriate for real-time packet voice and video. The reason was that TCP uses an end-to-end acknowledgment and retransmission strategy to ensure reliability between both ends. However, for real-time communications with video and audio it is more important to minimize delay than to ensure reliable delivery [Casner 1983].Thus, NVP and PVP were developed along with the Stream Protocol (ST), which operated at the same level of IP but was connection-oriented instead of datagram-oriented. In 1989 these protocols used IP for the signalling while keep using ST for the transmission of the media [Schooler 1989]. In the early 1990’s the development of videoconferencing advanced so much because of many factors: the technical advances in Internet Protocol (IP), and more efficient video compression technologies that permitted desktop or PC-based videoconferencing, such as the H.261 hardware coding [CCITT 1993]. There were several examples, like the PictureTel, the first videoconferencing using PC, that was developed by IBM in 1991. In that year the first audio/video conference using H.261 was implemented in DARTnet. In August 1991, the Network Research Group of Lawrence Berkeley National Laboratory released an audio conference tool vat for DARTnet use. The protocol used was referred later as RTP version 0. In December 1992 Henning Schulzrinne, GMD Berlin, published RTP version 1. It went through several states of Internet Drafts and was finally approved as an Proposed Standard on November 22, 1995 by the IEFT/IESG. This version was called RTP version 2 and was published as [Group 1996b, Group 1996a]. In the next subsection we will further discuss RTP and is characteristics. The first Internet videoconferencing client that supported multipoint-calls with video was CU- 52 CHAPTER 2. STATE OF THE ART

SeeMe. It was originally written in the Information Technology department at Cornell University by Tim Dorcey [Dorcey 1995]. It was first developed in 1992 for the Macintosh, and later for the Windows platform in 1994. In 1995 World News Now was the first television program to be broadcast live on the Internet, using CU-SeeMe. A new ITU-T video coding recommendation for low bit-rate communication was published in 1995, which was called H.323 [ITU-T 1996]. It consists of a set of protocols and standards that address call signalling and control, multimedia transport and control, and bandwidth control for point-to-point and multi-point conferences. The core protocols that are part of this recommendation are H.225.0 (for user registration and call signalling), H.245 (control protocol for multimedia communication), RTP (for sending and receiving media streams), H.235 (for security aspects), etc. In 1998 the first version of the MPEG-4 standard was developed by MPEG, a working group of ISO/IEC in charge of the development of international standards for compression, decompression, processing, and coded representation of moving pictures, audio and their combination. MPEG- 4 builds on three fields: digital television; interactive graphics applications (synthetic content); and interactive multimedia (World Wide Web, distribution of and access to content). Previous standards proposed by this group were MPEG-1 and MPEG-2. These standards made interactive video on CD-ROM, DVD and Digital Television possible. In 1998 the IETF Multiparty Multimedia Session Control (MMUSIC) working group developed the Session Initiation Protocol (SIP) [Rosenberg 2002], a signalling protocol for Internet conferencing, telephony, presence, events notification and instant messaging. In 2002 JVC completes a technical work leading to a new ITU-T recommendation [ITU-T 2007] based on the new H.264 video encoding. A final recommendation was published in 2003.

Cloud-based conferencing

In the last few years a set of videoconferencing applications and protocols became popular and several companies started to offer videoconferencing as a service, basing on new web technologies, standards and video encodings. Macromedia released the first version of a proprietary real-time protocol in 2002. This protocol, called Real Time Messaging Protocol (RTMP) was first used to streaming content 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 53 across the Internet from the servers to the clients, which were applications running in a web browser plug-in called Macromedia Flash Player. The same protocol was then used to implement web conferencing, by accessing user’s camera and microphones through the same clients, and then sending them using RTMP to send and receive media flows. In 2009 Adobe, having acquired Macromedia, decided to publish a open specification of the protocol in [Incorporated 2009]. In August 2003, the first public beta of Skype was released, a proprietary voice over IP application. This application included private protocols and mechanisms to offer peer-to-peer audio and videoconferencing. In 2005 the XMPP Standards Foundation published its own signalling protocol, called Jingle [Saint-Andre 2007]. This protocol offers similar functionality to SIP one, but it was build atop XMPP messaging protocol. Google made the first release of this protocol in the Google Talk application in the same year. On2 Technologies released a new video compression format called VP8. Later, in 2008, Google acquired On2 and released a specification of the format under an open source license. Since that year, the codec started to be released as part of Google’s web browser (Google Chrome). In 2009 Microsoft released its fourth version of Silverlight plugin for the web browser. This version already supported access to the user’s camera and microphones. But it did not provided any support for video and audio encoding. Jingle Relay Nodes specification was released in 2009 to improve Jingle signalling protocol [Camargo 2011]. This extension provides NAT Traversal for Jingle users with or without STUN/TURN support, that was one of the main problems of SIP signalling system and the beginnings of Jingle. In 2011 a IETF group named WebRTC, in conjunction with another group in the W3C started to work in a new set of protocols and APIs, as part of the HTML5 W3C specification, with the aim of publish a standardized mechanism for doing web conferencing, basing on existing protocols such as RTP, SRTP, ICE, etc. On January 2012 Google launched a first beta version of Google Chrome supporting part of this APIs. At the time of writing this PhD these were the most important milestones related to conferencing systems, protocols and technologies. It gives a brief description of the evolution of such applications and it will allow us to better understand next sections, in which we will further 54 CHAPTER 2. STATE OF THE ART study the current state of the art.

2.3.2 Signalling Protocols

In this section we will see different existing approaches that offer signalling between clients in order to establish audio and videoconferences.

SIP

SIP stands for Session Initiation Protocol. It is a signalling protocol released by the IETF for controlling communication sessions such as video and voice calls over IP. This protocol can be used in different scenarios, such as multimedia communications between two peers, or multiple peers. Since its ﬁrst release, the SIP protocol has been extended to also include streaming multimedia distribution, instant messaging, presence information, gaming, ﬁle transfer, etc. SIP messages are quite similar to the HTTP request/response transaction model. In each of these transactions the client invokes a particular function in the server, and this transaction generates at least one response, that is sent back to the client. The most common messages in SIP are:

• REGISTER Used by clients to provide information about their IP addresses and network location. Then, a user is identiﬁed by an URL similar to the used in the email system (e.g. [email protected]).

• INVITE It is used to initialize the establishment of a media session between two or more clients.

• ACK Used by different ends to conﬁrm the reception of messages.

• CANCEL It is sent to terminate a pending request.

• BYE Sent by clients to terminate a current conferencing session

• OPTIONS It provides information about the capabilities of a client. It is used to know if two or more clients can establish a session. 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 55

Like in HTTP protocol these requests produce different response types, which consist of a code number and a description. Typical values are 100 for indicating the current processing of a request, 200 for successful requests, 300 for redirections, 400 for client errors, 500 for server errors, and 600 for global system failures.

User Proxy User Bob Alice

“Calls” INVITE: sip:[email protected] [email protected] INVITE: sip:[email protected]

100 - Trying

180 - Ringing Rings 180 - Ringing

200 - OK Answers 200 - OK

ACK

Talking RTP Talking

Hangs up BYE

200 - OK

Figure 2.8 : Example of Messages Sent During a SIP Session

Figure 2.8 shows an example of a session establishment and termination. In this session Bob calls Alice, so its SIP-capable client sends the corresponding INVITE through the SIP Proxy to Alice’s client. Its client starts ringing until Alice answers. Then both clients directly communicate between them. In this example Bob hangs up, so its client sends a BYE message to Alice’s, and the communication terminates. SIP was designed to be implemented in a wide range of devices with different capabilities. Thus, it provides a media negotiation protocol between peers in order to make an agreement of media codecs, containers and formats. For this purpose it makes use of the Session Description 56 CHAPTER 2. STATE OF THE ART

Protocol (SDP), that provides detailed description of media ﬂows and sessions. SIP implements a mechanism to exchange SDP documents between clients who want to communicate. Thus, clients can offer different possibilities in these SDP documents and decide which conﬁguration they will use basing on their capabilities.

XMPP Jingle

XMPP Jingle is an extension to the XMPP protocol (Extensible Messaging and Presence Protocol) that enables the establishment, management and termination of videoconferencing sessions between two or more parties. XMPP, formerly known as Jabber, is a set of technologies for instant messaging, presence, content syndication, and generalized routing of data. It was originally created in response to the closed instant messaging services at that time, and its initial purpose was to provide an open, secure, spam-free, decentralized alternative. One of the main features of XMPP is the extensibility, that is provided by the use of XML documents. With these documents anyone can create custom functionality on top of the core protocols. Open extensions are published in the XEP series, but it is not mandatory to open any extension implemented in XMPP. One of these open extensions is Jingle. It implements peer-to-peer session signalling for multimedia communications, such as voice over IP (VoIP), videoconferencing communications and file transfer. It provides compatibility with a wide range of transport protocols like TCP, UDP, RTP, or even in-band XMPP itself. Jingle was designed to be compatible with both SIP and Session Description Protocol (SDP), thus making it straightforward to provide signalling gateways and translators between XMPP and SIP systems. Jingle defines a series of messages that are exchanged between call initiator and responder. These messages are aimed to establish the session, negotiate content and transport, and change configuration during an active call. These are the messages related with session establishment:

• session-initiate It is used to request negotiation of new Jingle session.

• session-info This action is used to send session-level information, such as session ping or a ringing message.

• session-accept It is used to deﬁnitively accept a session negotiation. This indicates that the responder is ready to proceed with the session. 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 57

• session-terminate It is used to end an existing session.

In Figure 2.9 there is the complete set of messages sent between both ends of the communication. Message with the format transport-* are used to negotiate and establish transport connections that are going to be used during the session, actions with the form of content-* negotiate content deﬁnitions such as video codecs and formats. Message description-info is used to send informational hints about parameters related to the application type, such as the suggested height and width of a video display area or suggested conﬁguration for an audio stream. And message security-info action is used to send information related to establishment or maintenance of security preconditions.

session-initiate

PENDING content-accept, content-add, content-modify, content-reject, content-remove, description-info, session-info, transport-accept, transport-info, transport-reject, transport-replace

session-accept ACTIVE content-accept, content-add, content-modify, content-reject, content-remove, description-info, session-info, transport-accept, transport-info, transport-reject, transport-replace

session-terminate ENDED

Figure 2.9 : List of Messages Used in Jingle 58 CHAPTER 2. STATE OF THE ART

There are several implementations of Jingle protocol. The ﬁrst and most famous was developed by Google with their Google Talk client.

H.323

The ITU Telecommunication Standardization Sector (ITU-T) published the H.323 recommendation to define the protocols to provide audio and video communication sessions on any packet network. It defines call signalling and control, multimedia transport, and bandwidth control in single conferences and multi conferences. The call signalling is based on the ITU-T recommendation called Q.931, which can transmit calls across networks like IP. The control protocol for multimedia communication and media negotiation is defined in the H.245 recommendation. And it also defined other mechanisms, such as RAS protocol to allow endpoints to communicate with gatekeepers. Gatekeepers provide endpoint registration, address resolution, admission control, user authentication, and so forth. Finally, H.323 uses RTP protocol for media delivery between endpoints. This recommendation has been used in scenarios such as VoIP, videoconferencing services, and international conferences.

2.3.3 Technologies For Sending Media Flows

In this section we will two alternatives for sending media video and audio packets through the Internet. The ﬁrst on (RTP) is the standardized option. The second one (RTMP) belongs to Adobe despite it being published in an open speciﬁcation.

RTP

The Real-Time Transport Protocol has been used for many years in different scenarios: conferencing, streaming, gaming, and many real time communications that have been implemented in the Internet. According to the RFC in which it has been specified, RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. It has been designed to be independent of the underlying transport layer (TCP, UDP, etc.), and it does not guarantee quality of service and it does not implements any logic or algorithm. On the other hand, this standard 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 59 provides a way for sending packets in real-time applications. Thus, it defines the structure for sending multimedia information in packets. These packets transport the bytes that represents media data along with some headers that gives information which is going to be useful for real-time applications. This information consists of timestamps for synchronization between senders and receivers, sequence numbers for sorting received packets and loss detection, information related to the type of data sent in each packet (audio, video, codec that has been used) and identifiers of each stream. It is designed to work in conjunction with a level of monitoring of data delivery, with minimal control and identification functionality. This level is offered in another protocol named Real- Time Transport Control Protocol (RTCP). Every participant in the RTP session should send RTCP packets with statistical information, global stream identifiers, additional timestamps that enable the synchronization of different streams, etc. Every real-time application can use this protocol for controlling the quality of service, but this protocol only gives information. It does not guarantee anything. RTP protocol allows the specification of extensions by the addition of more headers. For example, there is an extension to RTP packet that improves the security within the communication. This extension is named SRTP (Secure Real-Time Transport Protocol), and it provides two extra headers to authenticate sender and to encrypt the data sent within each packet. This protocol has been widely used in several real-time applications. It is used as transport protocol in VoIP applications implementing SIP, H.323, or XMPP Jingle signalling protocols; in multiplayer games with real-time requirements, such as OnLive; and in IP television systems such as Movistar Imagenio; in videoconferencing systems such as Isabel, that was implemented in the Department of Telematics at the Technical University of Madrid, Microsfot NetMeeting, etc.

RTMP

Real Time Messaging Protocol works on top of TCP which maintains persistent connections and allows low-latency communication. It originally follows a client-server architecture by deﬁning requests and responses. RTMP was developed for streaming audio, video and data between a Flash player and a server. It was initially implemented by Macromedia, and now it is owned by Adobe, which released the speciﬁcation of the protocol for public use. 60 CHAPTER 2. STATE OF THE ART

This protocol splits media streams into fragments and their size is negotiated dynamically between client and server. Thus, it transmits as much information as possible with little overhead. RTMP defines several virtual channels to provide multiplexing of audio, video and data sent in the same TCP connection. It defines headers like a timestamp, size of packet, id of the channel. AT higher level RTMP encapsulates MP3, AAC and Speex audio, FLV1 and H.264 video, and can make remote procedure calls (RPCs) using a specific format for the representation of the data, named Action Messafe Format (AMF) [Incorporated 2007]. RTMP information can be encrypted using either of two methods: using standard Secure Sockets Layer (SSL) mechanisms, by establishing a RTMP session within the SSL layer; and using an extension to RTMP, that implements the encryption of its headers and fields that does not introduce as much overload as SSL. Another extension for RTMP is named RTMP Tunnelled (RTMPT). This extension offers the application to send RTMP messages inside HTTP requests and responses. RTMPT facilitate the use of RTMP in scenarios where the use of non-tunnelled RTMP would otherwise not be possible. For example, in scenarios in which there is a Firewall that blocks non-HTTP outbound traffic between client and server. RTMPT messages are larger than RTMP messages because it adds HTTP headers to all messages, so it may not be suitable for implementing real-time applications in scenarios with low bandwidth availability. The main client implementation of RTMP is Flash player, which supports all its features either installed as a web browser plug-in or as part of a desktop application (using Adobe AIR framework). Other implementations has been developed since the publication of the RTMP specification, such as XBMC media player, FLVstreamer, FFmpeg library, MPlayer, or Gnash. On the server side the main implementation is Adobe Flash Media Server, but there are others like Wowza Media Server or Amazon CloudFront service. There are open source alternatives like Red5 and Freeswitch that also allow RTMP communication. RTMP implementations of videoconferencing applications differ from RTP implementations. These differences are:

• RTMP is based on a client-server architecture. Thus, video and audio data exchanged between clients is always sent through the server. As a result clients never directly communicate and they do not have to deal with NAT devices, or other network elements like Firewalls that difﬁcult typical P2P communications. On the other hand, there is an 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 61

additional delay given by its pass through the RTMP server.

• Signalling information and control is usually sent within the same RTMP connection, so clients only implement a single protocol stack with RTMP/TCP. On the server side there could be gateways developed to interoperate with other systems based on SIP, H.323 or Jingle signalling, that use RTP as transport protocol. There is no a standardized way of sending signalling messages in RTMP communications, so each implementation has to develop its own signalling protocol.

Similar Protocols

There are other protocols that have been also speciﬁed for sending multimedia information through the Internet. The great majority is deﬁned for streaming video and audio between a publisher and one or many subscribers.

• Microsoft Media Server (MMS). It is a proprietary protocol originally developed by Microsoft to transfer unicast data in Windows Media Services. MMS can be transported via UDP or TCP, and real implementations ﬁrst try to establish UDP-based connections prior to TCP-based ones. In 2003 Microsoft deprecated MMS in favour of RTSP.

• Real-Time Streaming Protocol (RTSP). It is a network control protocol, developed by MMUSIC Working Group at the IETF, published in [Schulzrinne 1998], and used in streaming media servers. It establishes and controls media sessions between end points. It deﬁnes VCR-like commands, such as play, pause and stop, to facilitate real-time remote control of media ﬁles from the server. However, the transmission of media data is not a task of RTSP. Most RTSP implementations use RTP for media stream delivery.

Figure 2.10 shows a summary of the protocols we have seen during this section. We can see call control and signalling protocols (Jingle, H.323 and SIP) and transport protocols (RTMP, RTP/RTCP, and RTSP). It also shows the RPC-based mechanisms developers have to implement when they develop RTMP client applications. And in the case of Jingle it also shows the underlying protocol for instant messaging called XMPP. 62 CHAPTER 2. STATE OF THE ART

Call Control Media Delivery

H.323 H.225 Audio/ Jingle H.245 Q.931 RAS SIP RPC Video

XMPP RTMP RTP RTCP RTSP

TCP UDP TCP UDP

Figure 2.10 : Overview of real-time protocols and standards

2.3.4 Web VideocOnferencing Systems

This section gives details of different videoconferencing services to which users can access using their web browsers. Table 2.4 compares ten videoconferencing systems with different capabilities and features. First capability is which technology it uses for running on top of the web browser. At the time of writing this thesis all applications need for the installation of a plug-in because browsers do not support videoconferencing systems with WebRTC. This table shows that the great majority of systems use Flash technologies to provide real-time services, with RTMP protocols. Only Google Hangouts uses its own plug-in and EVO implements its application using Java Applets. Some systems limit the number of users who can be connected to the same room. Google Hangout limits its number to 6 users, Cisco has a limit of 25 users and EVO is also limited. On the contrary, Flash Meeting and Big Blue Button use a turn-based mechanism by which users only can see one participant at each time, whilst the rest of participants only can view the session or ask for the next turn. Some of these systems allow the users to connect to session using their mobile phones. They usually support Android (Google Hangouts, Cisco WebEX, GoToMeeting, and Big Blue Button) and iOS (Google Hangouts, Cisco WebEX and GoToMeeting). In the case of GoToMeeting this support is restricted to audio conferences. Regarding TokBox, they use Flash technologies so 2.3. MULTIPARTY VIDEOCONFERENCING SYSTEMS 63 theoretically they would support access from mobiles phones, but at the time of writing this thesis they are facing problems with Adobe AIR technology, so ofﬁcially they do not support them. Almost all of them provide recording capabilities, free or paid (TokBox). Only Google Hangouts and OpenMeetings does not offer this kind of service within their system. There are different ways for supporting multiple users in a videoconference. Distributed (also known as peer-to-peer) or centralized (using MCU-like elements). Google Hangouts and TokBox provide a distributed architecture, and the rest of them implement a relay to distribute the trafﬁc among participants. TokBox offer both solutions. There are additional features, such as desktop sharing, slide shows, whiteboards, access to the system through an API or programmatic library that are also shown in the table. Finally, some solutions such as Big Blue Button, GoToMeeting and OpenMeetings are implemented based on open source code. Thus, videoconferencing developers could use them to implement similar services. 64 CHAPTER 2. STATE OF THE ART Vokle Vyew OpenMeetings EVO WebEX Cisco GoToMeeting Button Blue Big Meeting Flash TokBox Hangouts Google Plug-in Fah- (Flash (Flash) (Flash) (Flash) (Flash) (Flash) (Flash) (Flash) (Java) audio only) Multiple (limited) (limited) (limited) (limited) (turns) (turns) Users al . oprsno e iecneecn Systems Videoconferencing Web of Comparison : 2.4 Table (Android) Mobile (audio only) ? Record (non- free) Centralized Centralized Centralized Centralized Centralized Centralized Centralized Centralized Centralized Distributed Distributed Arch. & Desktop Sharing show Slide White- board API source Open Chapter 3

Interface for Videoconferencing in the Cloud

This chapter proposes a new application programming interface (API) for integrating collaborative videoconferencing as part of external web services. It provides any web application with a videoconferencing service, executable from the browser. This way, users can easily communicate between them. For example, an external service (like Facebook, Google, a newspaper, etc.) could use this API to offer videoconferencing capabilities to its users.

3.1 Introduction

The proposal of this API addresses standard videoconferencing and real-time application requirements. Below we can see the main features of this interface:

• Third party’s applications manages their own users, including authentication and authorization into the videoconferencing system.

• It focuses on conference rooms, where users meet to collaborate.

• The security requirements allow integration into third party’s applications.

• The interface provides some Quality of Service (QoS) inside each room to every application (or consumer services) used.

In other words, this interface aims to transform a traditional telecommunication service, such as videoconference, into a set of resources that will be used by third parties. Furthermore, this approach enables to transform standard client-server services into a Cloud Computing service. It offers access to a collaborative environment including audio, video and shared applications. This architecture has been called Nuve. The structure of the chapter follows the next structure: section 3.2 describes the main objectives of this contribution, section 3.3 gives a summary of work that closely related to this topic; section 3.4 aims to place this work in context while the following two sections introduce 66 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD the conceptual model and deﬁne the operations of this interface; section 3.7 describes the designed security mechanism to authenticate requests to the user interface; and, ﬁnally, the last two sections present the results obtained, a summary with the main contributions and detail the conclusions drawn from the work.

3.2 Objectives

This contribution addresses the integration of a collaborative videoconferencing system as part of external web services. Speciﬁcally it tries to overcome the ﬁrst two objectives of this dissertation:

• To identify open challenges in the implementation of traditional videoconferencing interfaces in Cloud Computing platforms. In this contribution I faced different challenges for this kind of interfaces. I will describe these challenges throughout this chapter.

• To propose new interfaces for videoconferencing architectures in Cloud Computing platforms. As a result from the previous study, this contribution also explains the functionalities included in the proposed interface.

As a result I give guidelines to resolve current challenges in different aspects:

1. Identity Management: Users will belong to external services and this API will not include any additional registration/login/logout features. The idea is to provide a ﬂexible API to third-party services.

2. Security: All user connections will be secure, and the API will provide mechanisms to trust services, users and their connections.

3. Quality: The API will be agnostic to the managment of video and audio quality. But the interface provides QoS through the videoconferencing system.

4. Validation: This API has been widely used and tested in different national and European projects, as we will see in chapter 7. And we provide measurments to show the empirical validation of the entire system. 3.3. MARTE WEB VIDEOCONFERENCING ARCHITECTURE 67

3.3 Marte Web Videoconferencing Architecture

This section describes the architecture of our videoconferencing architecture based on web technologies described in section 2.2. The videoconferencing system, called Marte, that is part of another thesis, and was developed given the next overall objectives:

3.3.1 Objectives

Web 2.0 Technologies

First objective of this work was to ﬁnd a development environment which allowed to run this videoconferencing system in the vast majority of scenarios. Thus, we focused more on the client- side and the best solution was the development of a client which could be accessed through the Web server, i.e. Rich Internet Applications. The description and all information about this concept can be seen in section 2.2. To summarize, RIA applications must meet the following requirements to provide an efﬁcient execution environment that allows: to run code; to manage contents; to communicate client with external applications; to ingrate such contents, communications and interfaces; to support interactions between user and extensible object models; to help the agile development of applications through the use of reusable components; to support communications between application servers through data and web services; to allow applications to execute in on-line and off-line modes; and to be easily implemented in multiple platforms and devices. Final objective is to obtain applications that can be executed in the web browser, while maintaining similar characteristics and functionality to desktop applications. Finally, we chose Adobe Flash because it provided an open development environment, called Adobe Flex (explained at 2.2), which allows us to implement a centralized architecture in which media streams always pass through the server. This technology offers an API with multimedia options, that allows straightforward creation of audio and videoconferences, using a dedicated server made whether by Adobe or by third parties.

Shared Desktop

Next objective was the development of additional services. Traditionally a videoconferencing service consists of video and audio communications, but there are others, for instance those seen 68 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD in section 2.3, that also offer other kind of services. In this case, projects required implementing a desktop sharing solution, which could be used by users in the conferences. This solution is very useful in conferences where speakers want to make some presentations with slides, but it is not implemented in many web application because problems related with its implementation. For this purpose we implemented the Virtual Network Computing system (VNC) because it is a mature technology widely used in different kind of platforms ad scenarios. However, this technology is aimed to use point-to-point connections, without intermediary servers or proxies. Because of the fact that I was developing a centralized architecture we decided to implement a proxy for saving bandwidth in clients’ connection.

This proxy also allows us to achieve more successful connections between clients, because the use of a proxy provides a good solution for clients that are hosted behind a NAT or Firewalls. This proxy is set up with public IP addresses, so it is totally accessible from this kind of clients.

But additional problems arose in very restrictive scenarios with presence of Firewalls and HTTP Proxies. These scenarios are very frequent when clients are inside a corporate LAN, that is isolated from the public Internet with these types of devices. Typically these networks only allow sending HTTP messages from inside to Internet, and thus, many other protocols are not allowed, such as RFB. To solve this I studied the operation of RTMPT protocol, and I implemented the same theory to encapsulate RFB messages inside HTTP messages. The implementation was based on adding two new elements between VNC peers. The ﬁrst one is the HTTP Tunnel Client, which is responsible for sending client RFB data in the body of HTTP requests, and the second one is the HTTP Tunnel Server, which sends server RFB data in the body of HTTP responses. For simulating TCP connections I implemented the same mechanisms of RTMPT, that consists of four type of HTTP requests and responses.

The ﬁrst one is originated from a HTTP request that opens the connection. This pair of request/response messages is the pair 1 in table 3.1. The response contains a session identiﬁer that is useful for multiplexing different connection through the same HTTP tunnel.

Once the connection is opened HTTP Tunnel client would send periodic keep-alive messages like the one seen in pair 2. Its response could contain data that the server wants to send to the client. This message has two objectives: to send available data from the server to the client when the client have nothing to send and to maintain the connection established in all intermediate devices, such as Proxies, NATs, etc. 3.3. MARTE WEB VIDEOCONFERENCING ARCHITECTURE 69

Table 3.1 : Types of HTTP Encapsulations Client Request Server Response

HTTP/1.1 200 OK POST /open/1 HTTP/1.1 Content-Type: app/x-fcs 1) Content-Type: app/x-fcs → HTTP/1.1 200 OK POST /idle// HTTP/1.1 Content-Type: app/x-fcs 2) Content-Type: app/x-fcs → POST /send// HTTP/1.1 HTTP/1.1 200 OK Content-Type: app/x-fcs Content-Type: app/x-fcs 3) → POST /close// HTTP/1.1 HTTP/1.1 200 OK 4) Content-Type: app/x-fcs → Content-Type: app/x-fcs

The next pair of messages is exchanged when the client sends data to the server. In this case the request contains such data. The server response could also contain data that has to be sent from server to client. These messages are shown in 3. Finally, the client could terminate the connection by sending the request in 4. Connections must terminate this way because the server has to know the session id. Requests of type 2 and 3 are sent to URL following the pattern /action//, that contains the session id and a sequence number that is used avoiding message duplication and lost. This effect could happen in the presence of Proxies that could drop packets during workloads.

Centralized Server Architecture

The development of Flash-based applications requires the implementation of an centralized architecture based on a multimedia server, which redirects all the trafﬁc sent between clients. Adobe uses its own server to provide this functionality, called Adobe Flash Media Server. This server allows the development of server applications programming real-time communication services between clients and using ActionScript language. It also offers additional characteristics that are not needed for this system. On the other hand this is a proprietary media server from Adobe Systems, and it is not free. Thus, it makes the interoperability with third party services more difﬁcult, and it would complicate the implementation of desktop sharing and of a open system (this objective will be discussed later). 70 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

However, there are alternatives to the use of this solution. First one is Wowza that provides additional characteristics such as the possibility of sending video to iOS devices. This product is not free nor open source either, so we would have the same problem as in the case of Adobe’s server. Finally, there is an open source substitute, called Red5, which presents almost the same features that Adobe Flash Media Server and Wowza. Based on Java, Red5 includes support for multi-user API, while it has embedded Tomcat Servlet container for Web applications. It is widely used for developing videoconferences, multi-user gaming and enterprise application software. Red5 is supported by Apache MINA network platform (Multi-purpose Infrastructure for Network Applications), which offers tools to users for the development of high performance and high scalability network applications. It is partially based on the SEDA [Welsh 2001, Welsh 2002] architecture (Staged Event-Driven Architecture). SEDA decomposes a complex, event-driven application into a set of stages connected by queues. This model avoids the high overhead associated with thread-based concurrency models, and decouples event and thread scheduling from application logic. SEDA employs dynamic control to automatically tune runtime parameters (such as the scheduling parameters of each stage), as well as to manage load, for example, by performing adaptive load shedding. Decomposing services into a set of stages also enables modularity and code reuse, as well as the development of debugging tools for complex event-driven applications. MINA is an Apache project that use the model proposed by SEDA in order to help Java applications to separate between protocol implementations and the application logic.

Usability

The implementation of videoconferencing systems as web services allows internet medium users to access to advanced multimedia services. These users could have limited computer knowledge. Hence implementation of a intuitive, straightforward user interface was very important. Tasks like creation, deletion, and joining to conferencing rooms should be fast and direct. People without advanced multimedia knowledge should be able to use this service through their web browser.

Open System

Last objective of this architecture is inherited from previous videoconferencing applications developed in my research group. Main objectives of these applications were the ﬂexibility and 3.4. VIDEOCONFERENCING AND CLOUD COMPUTING 71 scalability. For this purpose we tend to create open source applications, which could be easily modiﬁed and extended with no restrictive licenses. As a result of these objectives the architecture of this application is an open client/server model. Server is open and provides a centralized way for sending conferencing multimedia streams. This server manages presence information about the clients, and it acts as a VNC proxy and authentication server. The client application is based on Web 2.0 technologies, which can be run in the vast majority of the web browsers and operating systems. For this purpose it is a light, usable client, which make the most of Flex framework for creating user interfaces.

3.4 Videoconferencing and Cloud Computing

There exist many videoconferencing applications but users do not use them very often and do not extract all the potential they have. This is probably because they cannot be easily integrated in existing user environments. This is why I think that by offering collaborative videoconferencing as a Cloud Computing service, users will integrate it more easily into their environments. Next, we will remember some topics from the section 2. In [Wang 2010], the authors say that Cloud Computing distinguishes itself from other computing paradigms in the following aspects:

• User-centric interfaces: using Web browsers. Nuve allows users to connect videoconferencing rooms through a Flex application executing in the web browser. This application offers a common user interface for all of them.

• On-demand service provisioning: this model provides resources and services for users on demand. Nuve provides rooms to the services so users can use it.

• QoS guaranteed offer: computing clouds guarantees bandwidth, latency and so on. Nuve guarantees a correct bandwidth to the services because it analyzes the connection state and it modiﬁes some communication variables.

• Autonomous System: the cloud is autonomous and transparent to users. My goal is for Nuve to become a videoconferencing room provider to higher level services.

• Scalability and ﬂexibility: the architecture is ﬂexible, so it can adapt and scale itself depending on the number of users. In the present version of Nuve, this property is not yet 72 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

implemented, but in the future, Nuve offers scalability and ﬂexibility because I implemented it in a cluster of machines.

In addition, Nuve has some technological properties that also play an important role in Cloud Computing. The authors in [Wang 2010] described them:

• Virtualization: in the present version there is only one virtual machine. However, in the future many virtual instances of Nuve could be started on demand, using similar services like Amazon EC2.

• Orchestration: using APIs, an application could be the result of orchestrating a set of services. One of these services could be Nuve.

• Web Service and Service Oriented Architecture: Nuve offers an interface to control their resources, in other words, the videoconferencing rooms.

• Web 2.0: the Nuve user interface follows the philosophy of the Rich Internet Applications (RIA), using Flex applications to increase the usability.

In words of the NIST [Mell 2011] "Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of conﬁgurable computing resources". Thus, the use of REST interfaces to offer our Cloud Computing services is natural. Regarding the API architecture in this context, the aims of this contribution were:

• Following the REST principles designing a generic, simple, ﬂexible, reusable and stateless interface, useful to a multi-conference service.

• Building a Cloud Computing oriented service that follows the principles I will explain later.

• Implementing a proof of concept.

The API developed will allow us to do all this things in the future.

3.5 Nuve: Conceptual Model

The main goal of Nuve architecture is to offer a videoconferencing service for third parties. As such, others will manage and control the communication while the system is the responsible of 3.5. NUVE: CONCEPTUAL MODEL 73

Table 3.2 : Resources From The Conceptual Model

Resource Deﬁnition

Users It represents the third parties’ users who will communicate with others in each room.

Tokens It is the ticket used to delegate user authorization to third parties’ applications.

Services They are the third party’s applications that manage the rooms and give users access to communicate in each of these rooms.

Rooms They are the virtual spaces where the users will collaborate among themselves with video, audio and desktop sharing.

maintaining the communication alive and guarantee a Quality of Service. To better understand this, first I need to define a model based on resources and actors that will use those resources. In this section, I will describe the resources and their functionality inside the service. The conceptual model this architecture follows is that of a videoconferencing room provider (Fig. 1). These rooms are meeting points where users will be able to set up conversations using audio, video and IM. Besides, they will be able to share applications executed in their own desktops. External services will manage and control these rooms. For this reason, they will be responsible for making these rooms accessible and giving users and other services the needed authorizations (via tokens). Thus, I defined four basic resources (table 3.2). Nuve REST interface will manage each of those types of resources with standard HTTP operations: GET, POST, PUT and DELETE.

3.5.1 Users

A Nuve user is a person who has accessed a room and is communicating with other users from Nuve in the same room. Every user can share his audio from his microphone or send the video obtained from his webcam. Also, he can chat to other users using the IM client incorporated in the room. Finally, an application that is executing in the web browser through the user’s Flash Player is responsible for 74 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD managing all these features. Additionally, if a user wants to share applications executed in his computer, he must install the Java Virtual Machine. However, as we saw in section 2.2, the Java Virtual Machine is usually installed in the great majority of computers. In the real world, every participant in a meeting plays a different role so, in Nuve, there are three roles for users:

1. Observer: The observer user is present in the room and can see and listen to everything that is happening, but he cannot take part.

2. Participant: This role represents those users that can speak with the rest sending their video, audio, IM and desktop applications.

3. Administrator: Administrator role allows changing other users control over their video and audio streams, IM and applications. Also, administrators can change the mode with which the users show themselves to everyone in the room.

3.5.2 Rooms

The rooms are the main resources of Nuve service model. As I mentioned before, a room is a virtual space where the users can communicate among themselves in meetings. Depending on the type of the meeting, a Nuve room in the real world could be comparable to a company meeting room, an auditorium, a round table, a university class or the living room of a house where friends gather to speak about daily events. The service and its users deﬁne the goals of each meeting. The Nuve aim is to guarantee bandwidth and Quality of Service in all the rooms. The available communication channels among users are voice, video, instant messaging (IM) and desktop sharing.

3.5.3 Services

This resource represents those consumer services that want to use the rooms provided by Nuve. To better understand it, we can use Facebook as an example of a service as it could arrange for its users to take part in a Nuve conference. When we add a new service in Nuve, in fact we create a shared key between them. The service uses this key to make calls to REST methods from the API. 3.6. NUVE API 75

From now on, the service can create, edit and remove rooms, giving access to its users or denying it.

3.5.4 Tokens

Although we will see them in detail in the API security section, we can deﬁne the tokens here as a resource necessary for user’s authentication between the service provider (Nuve) and the consumer. A token represents the entrance key for a user in an existing session in Nuve. The service is the one who requests the token through the REST interface. Finally, it provides the token to the user so he or she can connect to the session.

3.6 Nuve API

In this section I will explain the REST architecture done in this work (illustrated in Figure 3.1), which, as I said before, is based on 4 resources: users, rooms, services and tokens. We will see which HTTP operations the services can use for each one and the information sent and received into each operation. Consumer services will send HTTP requests to this interface, asking for the creation/deletion of rooms, giving access to users and retrieving information about conferences. End users of these services could take the role of administrators who will create, remove and update rooms, or it could be done by the service automatically. Even third parties could create a wrapper to offer several types of services that would include videoconferencing rooms, and would manage them through protocols like SOAP, XMPP, etc. In order to support the usage of rooms by the services, the information about resources could be submitted in different ways. In this case, I have chosen the next three data structures that are the widely used in the World Wide Web: JSON i (which is the JavaScript serialization of objects, very important for objects implemented with this architecture), XML (that is a markup language with data structures compatible with JSON), and at last, HTML which is mainly used for making data representation easier to other services. I design the API according to the recommendations from [Pautasso 2009], making a good use of the REST philosophy. As it is usually recommended when designing this kind of APIs, this

ihttp://www.json.org 76 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

Flex Application C o n

n Service P

e O c #

t S ( t T # o

t k / o t e

k o n

e k

n e n )

Marte API REST Security Filter User Access Controller Nuve User Access Controller Room Manager Service Manager User User Token /room /service Token consumer /user/token

RTMP Server Marte Instance

Figure 3.1 : Nuve Layer Architecture

work proposes different commands using HTTP methods (GET, POST, PUT and DELETE) on the next four resources:

3.6.1 User

It represents users, providing different services for obtaining a list of them as well as information about one in particular. We could get information about a user sending a GET HTTP request to a URL with the next structure: /room//user/, being id the room identiﬁer and username the name that the user has in this room. There are three different formats for the response: XML, JSON and HTTP. An example for this kind of communication would start with: 3.6. NUVE API 77

GET /room/321/user/Bob HTTP/1.1 Accept: application/xml [Security info] [CRLF]

The response would have the next structure:

HTTP/1.1 200 OK Content-Type: application/xml Content-Length: 60 [CRLF] Bob participant online

Furthermore, we could also ask for the entire list of connected users by sending a GET command to the URL /room//user/. We could even throw a user out from the room by sending a DELETE message to /room//user/. On this resource we cannot create users, although it could be useful if we would want to invite users to one room. However, since a user is going to connect directly to Nuve, I decided not to develop this functionality inside Nuve. A use case could be a scenario where a user would send an email to other person with the link to the room. If the other user would click the link it would take him to the room. In short, and referring to tables 1 and 2, it is possible to ask for information in XML, JSON or HTML format of the resource which represents the user who connected to the Nuve’s room.

3.6.2 Room

It represents the space in which users can collaborate and share their video, audio and data. We can make different operations such as create, update, remove, list rooms and even give access to users. As I said before, this is the main resource of Nuve and, as such, it is important for us to have perfect control and get detailed information in various formats. Consumer services and users through their services could manage this resource. Regarding the available operations, I will start with those of them that are read-only, which are the same that in the case of the resource user. 78 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

Any service could demand information about any of the rooms which belong to it. For instance, by sending a method GET to /room/ if it wants to get a list of all of its rooms, or to /room/ if it wants information about only one of them. The information returned by this way could be represented in XML, JSON or HTML format, and an example of the HTML one is below:

This example shows part of the code of a web page which would be useful to include in the Nuve client that, as I mentioned before, is a Flash application. Regarding the write requests, the ﬁrst step is to create a conferencing room. As it usually occurs in REST architectures, it is accessible through a POST method to the collection URL. In this case an example for this would be:

POST /room HTTP/1.1 Content-Type: application/json Content-Length: 26 [Security info] [CRLF] {"room":{"name":"MyRoom"}}

The information sent to the server could be either in XML format or in JSON (that is the case of this example): The response of the server would be the next:

HTTP/1.1 301 Moved Permanently Content-Type: application/json Content-Length: 26 Location: /room/MyRoom [CRLF] {"room":{"name":"MyRoom"}}

As we see in this example, the response in REST models is a message of the type 3.6. NUVE API 79

Moved Permanently, and the response includes among its headers one that shows the URL of room resource. The other writing operations are change and removal of rooms. The ﬁrst one is a PUT request sent to the URL of the room (in the example it would be /room/MyRoom) with new information about the resource. The response for this request would be a 200 OK. The last option would be to remove the room. This could be done through the DELETE operation, as we can see at example:

DELETE /room/MyRoom HTTP/1.1 [Security info] [CRLF]

The response in the case of Nuve successfully removing the room would be a 200 OK.

3.6.3 Service

Nuve’s API allows adding and removing services that have authorization to use its Rooms. Furthermore, we can ask for the entire list of services through a root service with special permissions. As in the other cases, to create a service we will use a POST operation to the URL of the resource collection (/service), and to remove an existent service we will do the same with the DELETE operation to the URL of the resource which we want to remove (/service/). It is important to keep in mind that a service can only be removed by the service that owns it or by the root service. The service uses JSON, XML or HTML formats to represent information about a resource, but we can only create a service by sending information with the ﬁrst two ones. Below is an example of a service described in XML format:

Facebook 123okopwqeop21893 u94832er893wjhr893j98

We will see more details about these properties in a later section, when I talk about the security that I implemented in this API. As we saw before, we can retrieve information through a service with special permissions. In fact, this service is the only one allowed to manage the ownerships of the rest of services, 80 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD controlling the creation and deletion of their rooms. Therefore, it is a main part of the entire architecture. Its aim is to make the work of administrators easier and that is why it is possible to offer information of each service in HTML format.

3.6.4 Token

The last resource of this API is the one that allow us to give access to end users. In the next section I will explain in detail its functionality, but now I am going to deﬁne the operation needed to create them. This operation is a little different because this is a special resource and, as I have already said thought essentially to authenticate users of other services. Besides we can use it to check that these users who are going to take part in conferences come from services that are the owners of such conferences. For instance, in a typical use case these resources take part of the token creation operation. Tokens being nothing more than unique identiﬁers randomly created that have a limited time to live. In other words, some minutes later (usually 3 minutes), these tokens cannot be used and the system removes them. The next example shows the way to create them:

POST /room/MyRoom/token HTTP/1.1 Content-Type: application/xml Content-Length: 63 [Security info] [CRLF] Bob participant

When the server receives this request, Nuve creates a new unique identiﬁer and relate it through a database to a username, a role and a room. Thanks to this, when a user wants to connect to one session, Nuve can retrieve this data from the database to know the room where the user wants to take part in, with which username, and what role the user will play in the session. The response of Nuve would be the next: 3.7. SECURITY 81

Table 3.3 : HTTP methods used for XML/JSON contents

GET POST PUT DELETE

/user

/room

/token

/service

HTTP/1.1 301 Moved Permanently Content-Type: application/xml Content-Length: 26 Location: /room/MyRoom/token/123p2j13io21 [CRLF] Bob participant 123p2j13io21

It is necessary to know that each operation has the scope of the service that requests it and Nuve is aware of it thanks to the security information that the service includes in each request. Also, as stated above, there is a special service called root that has enough permissions to use everything else. We can see a summary of all operations that each service can use on each resource. Table 3.3 explains the operations that we can do with information in XML and JSON format, and the table 3.4 is for information represented with HTML. We can deduce the service authentication importance from the description that I have made through this section. Due to this, in the next one I will comment further details about it.

3.7 Security

This section describes the architecture of the solution implemented to give the system a security layer. The adopted mechanism combines an extension to the HTTP header and tokens usage for end-user access. 82 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

Table 3.4 : HTTP methods used for HTML contents

GET POST PUT DELETE

/user

/room

/token

/service

3.7.1 Description of the problem and experiences

The next subsections explain the different approaches considered when designing the security solution for Nuve. Firstly, I discuss about the security in this type of applications. After that, I present a brief analysis of the existing implementations to give some background on the existent works.

Security requirements in collaborative software

Before focusing on the problem, it is important to define the general security concerns in collaborative software (CSCW: Computer Supported Collaborative Software from now on). A wide variety of software applications fall under the CSCW definition, ranging from relatively simple document repositories to full-blown real-time multimedia systems that allow for much more complex interactions among users. The collaborative software matrix [Johansen 1988] perfectly illustrates that fact. Due to that environment variety, security in this context is a little hard to define. There are several studies that try to unify a definition for security requirements as well as the notation used to describe them properly ([Ahmed 2003] and [Tripathi 2003]). As a result of the analysis of those publications it is possible to extract a subset of rules that try to cover the most critical security problems:

• Participants follow the previously established workﬂow.

• The existent roles are consistent as well as the constraints imposed to them. 3.7. SECURITY 83

• Only authorized users have access the system.

• Users enter the system with the corresponding roles.

• Any temporal or conditional constraints could be applied to the resources.

• Each user’s private data cannot be accessed by anyone else.

When it comes to videoconferencing (same place, different time in the matrix) the number of roles usually is very limited, simplifying interaction compared to other schemes with more complex workﬂows. According to this, I reach the basic conclusion that in a context of videoconferencing where the usual workﬂow is quite simple, the main security concerns come from user authentication and authorization so they have access to the right resources depending on their roles.

REST Authentication

Having analysed the security needs in a general context, it is time to study the different mechanisms that have already been implemented and published but focusing on REST which is the API used in this system. The most important alternatives researched and, as such, shown in this chapter are: Amazon S3 ii and OAuth iii. I chose both because they are proven to work. First of all, it is important to note that both are based, above all, on changes of the standard HTTP authorization header defined in [Fielding 1999]. To sum the process up, it consists on the server responding to non authorized requests with a 401 code including a WWW-Authenticate field which specifies a challenge for the client. The next call coming from the client should include an Authorization field and the data implied by the challenge. Finally, the server should check the reply and process the request if it meets the requirements. There is no specific type of authentication enforced but [Franks 1999] proposes two options: Basic and Digest. The first one is really simple because it only includes two fields (name and

iihttp://aws.amazon.com/s3/ iiihttp://oauth.net/ 84 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD password) in plain text. Digest authentication is a little more complex as it proposes MD5 [Rivest 1992] for cryptographic hashing and nonce values to avoid replay attacks.

After this brief digression I switch my focus back to the studied systems. Amazon S3 is an online storage service offered by Amazon Web Service designed to make life easier for web applications developers with important needs in terms of data space but lacking the required infrastructure. It offers its users both SOAP and REST interfaces allowing them to make various actions like adding or removing data. It is a paid service and, as such, user authentication is extremely important.

Amazon called AWS to its change of the HTTP header. In this type of authentication, the reply to the ﬁrst 401 code is to introduce in the said header the following line: Authorization: AWS AWSAccessKeyId:Signature where AWSAccessKeyId is given by Amazon to the client after registering as well as another key which Amazon uses (together with a string containing several values) to calculate the signature by means of the HMAC_SHA1 algorithm. The server could easily reproduce the signature because the client’s id and key are already known.

The other studied case I will explain here is the OAuth protocol which, among other security mechanisms, includes one similar to ones explained above. OAuth allows a user to grant access to their information on one site (the Service Provider), to another site (called Consumer), without sharing all of their identity. The communication between the provider and the consumer is not very different in concept to the one we see in Nuve.

The use of the HTTP header is quite similar to Amazon’s but the information provided in it is not always the same and changes depending on the action requested. As a result, the data included in the header is not only used for authentication but also for application level purposes. Furthermore, and without getting into too much detail, OAuth authentication uses a token which is given to the consumer to get access to the provider’s resources. In the process, the client gives his or her credentials to the provider but never to the consumer.

Finally, both alternatives aim to authenticate and authorize the agent that is requesting the operations. I conclude that, in the case of Nuve, this type of mechanism satisfies the security requirements obtained from the first part of this section. However, it is necessary to develop a more specific solution for my system. 3.7. SECURITY 85

3.7.2 Security in Nuve: MAuth

HTTP Authorization

Regarding HTTP Authorization, the path chosen is similar to the ones described above, that is, an extension to the HTTP standard header. However, like OAuth, the header is also used to carry parameters used by the application. The full header containing all possible parameters used is as follows:

Authorization: MAuth realm="http://marte3.dit.upm.es", mauth_signature_method="HMAC_SHA1", mauth_serviceid="ServiceName", mauth_signature="jlsa731232=", mauth_timestamp="1231321321", mauth_cnonce="123123aadf", mauth_version="3.1", mauth_username="user", mauth_role="participant"

Below I describe individually each one of them:

• mauth_signature_method: It indicates the signature method used to sign the request. HMAC_SHA1 is the only one supported. The key used in the process is symmetric and services exchange it off channel.

• mauth_serviceid: A unique identiﬁer for the service. Nuve uses it to get the key and for several other purposes at application level.

• mauth_signature: The signature generated by the method explained above.

• mauth_timestamp: Unless otherwise speciﬁed, the number of seconds since January 1, 1970 00:00:00 GMT. The value must be a positive integer and must be equal or greater than the timestamp used in previous requests.

• mauth_cnonce: A positive integer that must be different for each request with the same timestamp. Used to prevent replay attacks.

• mauth_version: Current version number.

All the parameters mentioned above are obligatory. The next two are only used for requesting access for a user to a room. 86 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

• mauth_username: Name of the user trying to get access to the conference.

• mauth_role: Role of the user in the conference. The possible roles a user can take in a room are: "participant", "administrator", and "observer". Each role deﬁnes limits to what a user can do while the conference is taking place.

The string used to calculate the signature varies depending on the parameters included in the header. The format of the string is:

(mauth_serviceid, mauth_timestamp, mauth_cnonce, [mauth_username, mauth_role])

The parameters between square brackets are only present when needed. To better understand the ﬂow of the authentication, let’s study a particular case. A service wants to get the list of the existent conference rooms. Initially, the service issues a request to Nuve:

GET /rooms HTTP/1.1 Host: marte3.dit.upm.es

The request did not include authorization information so the Nuve server replies with a 401 code indicating that the request was not authorized and providing information about the authentication type that should be used.

HTTP/1.1 401 Unauthorized WWW-Authenticate: MAuth, realm="marte3.dit.upm.es"

Now, the service knows that Nuve uses MAuth to authenticate requests and must ﬁll in every parameter to have its request approved and processed:

GET /rooms HTTP/1.1 WWW-Authenticate: MAuth realm="marte3.dit.upm.es", mauth_signature_method="HMAC_SHA1", mauth_serviceid="global", mauth_signature="dasawaraj212312", mauth_timestamp="32132131", mauth_cnonce="654sa5d6asdads", mauth_version="3.1" 3.7. SECURITY 87

In this particular case, we are not using mauth_username and mauth_role as they are not needed for this request. Once the authentication reaches this point, the server has all the needed information to verify authenticity of the request, if everything is right it replies the service with a message including the list.

User authentication: tokens

This subsection gives a detailed explanation of the process of authenticating users in Nuve without the need of directly exchanging information between the end users’ pc and the Nuve server. This is achieved via the token mentioned before. Only users that own a valid token have access to a Nuve conference. As explained above, the system generates tokens dynamically every time a service asks for one, besides, the server stores information about the user (the service it belongs to and the role he or she will play). Furthermore, tokens have an expiration date rendering them useless after a given period of time. Figure 3.2 illustrates the usual workﬂow followed after conference creation.

Marte Client Web Browser Third Party Service Nuve Auth Service Nuve Conference Service

Access Request Token Request for #user in #room 1 2 Auth Check Init with #token #token #token 5 4 3 Marte Initialization Connect with #token 6 Check #token 7 Auth Check Ok for #user in #room 8 Room Connected update 9

Figure 3.2 : Authentication Sequence Messages

1. The user requests access to a videoconferencing room. In order to do that, he or she probably has previously identiﬁed himself in the context of the service. 88 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

2. The service issues a request to Nuve asking for access to the conference for that speciﬁc user. That request includes all the authorization data mentioned before.

3. If the authentication is successful, Nuve sends a valid token back to the service. The server relates this token to information about the conference room and the user’s role.

4. The server redirects the client to a dynamically generated web page which has the Marte client needed to join in the conference.

5. The service provides the token to the client during the loading process.

6. The user does not have to introduce any information and can only access the conference requested by the service. The client automatically sends a connection request with the token to the Nuve Conference Service.

7. Nuve Conference Service sends a token validation request to the Nuve Auth Service.

8. If the token is valid the Nuve Validation Service responses with the corresponding information about the user.

9. Nuve Conference Service grants access to the user.

3.8 Results

This section describes a proof of concept implementation that I used to test the new architecture and draw conclusions about the results. Firstly, I will give a brief explanation about the test environment for this implementation detailing each component used and ﬁnally I will present all the tests performed and the results obtained from them.

3.8.1 Implementation

The API implementation has its roots in the Marte 3.0 application that I described in section 3.3. This application uses an Apache Tomcat server with a Red5. Red5 manages the voice/video communications established among Adobe Flex/Flash clients. As Tomcat was an already set piece of the architecture I decided to use a Java library and I chose Jersey [Potociar 2007], developed by Sun and quite useful for creating RestFul APIs easily. 3.8. RESULTS 89

The working API had to embody the theories exposed throughout this article, so I started by defining the four mentioned resources (rooms, services, users and tokens). The logic behind the creation, modification, removal and reading of each of the resources was in its core a simple call to already implemented Marte classes so I did not have to recode all the parts concerning the management of the application. The most important parts reused from Marte are the following: The RoomRegistry component takes care of all the functionality related to the creation and removal of rooms. Besides, it does so safely avoiding all the possible problems that might come up when performing those actions. For instance, when a service removes a room, RoomRegistry disconnects all the users present in those rooms providing the needed explanation to the clients. Furthermore, it checks authorization of any service that tries to remove a room. The ServiceRegistry module is quite similar but it deals with services. When a service is created, it performs several actions like analysing existence of any conflicts with other subscribed services and when a service is deleted it deletes all its owned rooms by using the RoomRegistry component. The last component used from Marte 3.0 is the UserRegistry which allows us to add or remove users from a room. For instance, we will use this component when a room is deleted via RoomRegistry to remove all users from it. Finally, to take care of all the persistence needs of the application, a HSQLDB database is used through Hibernate. It only stores data about subscribed services and rooms so two related tables were created on for each. In Figure 3.3 the logic behind the removal of a service is shown as an example.

3.8.2 Test environment

The objective of these tests was to measure the capacity of the Nuve server in terms of the number of users that was able to support, the bandwidth of a common session, monitoring the CPU usage of the machine in which the server is hosted. The test system was a VMWare virtual machine running on top of an Intel Core 2 Duo with 2 GB of RAM. The virtual machine is limited to one CPU and 512 MB of RAM. The operating system used is an Ubuntu Linux 8.10. In order to get this data I deployed the previous implementation in a machine to which different users from the same subnet were connected, all of this through an Ethernet connection and a Switch that supports a bandwidth of 1 Gbps. All the users and the server had network interfaces of 1 Gbps. Regarding 90 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

Delete Service

Is a user Delete User No Yes connected? from Room

Has any Yes Delete Room room?

Figure 3.3 : Service Deletion Programming Logic

the bandwidth consumption I show different ﬁgures that I explain below. At Figure 3.4a I show the measured bandwidth during a conference in which users only communicated using their voice and they did not use webcam or screen sharing. During these tests all users sent audio through their microphones simultaneously. We can also see an empirical approximation to these results that represents the next equation:

2 BWtotal = Nusers · BWaudio (3.1)

Being BWtotal the bandwidth consumed by the centralized server (which has the Marte application), Nusers is the number of users connected to the videoconference and BWaudio is the bandwidth consumed by the audio of each user (in the testing all users consume the same bandwidth). Based on the bandwidth measured during the tests and applying the equation we get an approximated value for the bandwidth used by each user, that is 5 KBps. Figure 3.4b shows the bandwidth consumed by a session like the previous one, but in this case users are also sharing the video streams produced by their webcams. This test helps us to calculate the average bandwidth consumed by each user. We can assume that the worst case is that in which all users are continuously in movement (that is the instant in which the system consumes more 3.8. RESULTS 91

1000 Real Data 900 Theoretical Data 1000 800 900 Real Data Theoretical Data 700 800 600 700

500 600

400 500

Kilobytes per second 400 300 300 200 Kilobytes per second 200 100 100 0 0 1 2 3 4 5 6 7 8 0 Number of Users 0 1 2 3 4 5 6 Number of Users (a) Bandwidth consumed by audio (b) Bandwidth consumed by audio and video

40 40

30 30

20 20 Percentage of CPU

Percentage of CPU 10 10

0 0 0 1 2 3 4 5 6 0 2 4 6 8 Number of Users Number of Users (c) Percentage of CPU consumed by audio (d) Percentage of CPU consumed by audio and video

Figure 3.4 : Bandwidth and CPU consumption in different scenarios

bandwidth). In this case the following equation represents the measured values:

2 BWtotal = Nusers · (BWaudio + BWvideo) (3.2)

We can get from this equation that the bandwidth consumed by each user that is sharing its video is 16KBps. In ﬁgure 3.4c we see how the percentage of CPU consumed varies in an audio conference, while in ﬁgure 3.4d we see the same data but in a conference that includes video and audio. As a result, we can infer that there are not many differences between videoconferences and audio conferences in terms of CPU usage in the server. It is important to notice that these tests represent in scenarios where all users get access to the same conference room. In a test with many rooms, the largest bandwidth capacity of the server could be calculated by the next equation: 92 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD

2 BWtotal = ∑BWRoomi = ∑Nusers f romi · (BWaudio + BWvideo) (3.3) i i

3.9 Contribution

In this chapter I explain the design and implementation of a Resource Oriented Interface for videoconferencing architectures in Cloud Computing platforms. Throughout this chapter I have introduced the main features of the proposed interface in the context of other Cloud Computing systems. I have detailed the resources oriented interface of Nuve and I described the service interface. I also detailed a prototype of a Nuve system, and I validated and showed performance measures, showing that this architecture could be easily implemented in a cost-effective way. And extension of this implementation to scale as Cloud Computing service could offer tons of virtual rooms to users. It could be straight forward by allocating virtual rooms among the Cloud of virtual room servers. Several projects have reused the same core system. As part of these projects I have successfully installed the core in Linux, Windows, Mac OS X and Solaris. That is, I only have to support one group of physical CPUs which, in turn, have virtual machines running on top. Different services represent different projects and they can all share the same, unmodiﬁed, core. As a showcase I integrated Nuve into iGoogle, NetVibes and Google Waves.

3.10 Conclusions

The most critical part of this work has focused on developing a security mechanism that integrates the service into third parties’ applications and mash-ups. The Flex/Flash Rich Internet Applications (RIA) development framework from Adobe is proven to work effectively for implementing the prototype. I transformed the old Marte 3.0 client-server system into the Nuve architecture in three months by two persons working 60% of their time on it, which is a very reasonable resource expenditure for such a development. Using the Flex/Flash RIA based videoconferencing has more beneﬁts because it does not need the user to install any application in most cases because most browsers today have the Flash Player plug-in installed. Finally, even though the tests focus on measuring the limits of the system and do not represent a real scenario where usually one user sends more information than the others, they serve us 3.10. CONCLUSIONS 93 to estimate the largest video and audio bandwidth consumption by a normal user in this ﬁrst implementation. Regarding server CPU usage, the results shows that I have to design a low-level architecture that can scale through several server machines without overloading any of them. In order to meet this need and guarantee some QoS, I will need to instantiate virtual machines and turn then on and off. This motivates me to follow the Cloud Computing principles. 94 CHAPTER 3. INTERFACE FOR VIDEOCONFERENCING IN THE CLOUD Chapter 4

Videoconferencing System Architecture

In this chapter I will explain a novel videoconferencing architecture, that could be used on top of Cloud Computing platforms. This architecture offers advanced videoconferencing rooms to the users. The term advanced in this context refers to additional features, such as whiteboard sharing, push-to-talk-based turns, questions, application sharing. It also provides technology to record video sessions and make post-edition of them. Furthermore, this work follows the same principles of the thesis by offering access to the sessions through the web browser with minimal installation requirements.

4.1 Introduction

Since a few years ago developers have been increasing the number of applications and services that offer to their users the possibility of establishing videoconferencing sessions of multiple users through a Web portal. Some of these systems allow the recording of their sessions. We can ﬁnd examples of these portals such as WebEx i, FlashMeeting ii or the one explained in chapter 3. On the other hand, during this period some Internet portals have arisen to allow the users to upload their own recorded videos of lessons, conferences, etc. In these other portals the videos can also be accompanied with slides or presentations that have been used in the session. Examples of these services are Youtube iii, RTVDoc iv or iTunesU v. The great majority of these systems use Cloud Computing infrastructures to offer their services, either in the recording or in the storage of the generated videos. However, none of them offer a wide solution for creating, storing and distributing videos using Cloud technologies. In this work I designed a novel architecture that follows these ideas. It is part of the Global

ihttp://www.webex.com iihttp://ﬂashmeeting.open.ac.uk/home.html iiihttp://www.youtube.com ivhttp://www.ucm.es/info/tvdoc/ vhttp://www.apple.com/education/itunes-u/ 96 CHAPTER 4. VIDEOCONFERENCING SYSTEM ARCHITECTURE

European Project vi and it is based on a service which offers to the users a possibility to schedule videoconferencing sessions through a web portal (named GlobalPlaza vii). The users could attend to each of these sessions through the web and even take part of the meetings that would be created with this application. With this tool several users could get access to a single videoconferencing session and control it. This control is based onthe interaction modes that are setup at different moments (presentations, conferences, questions, etc.). The system presented takes into account the different resources needed to set up a videoconference and reacts accordingly . In this project I developed a new service that offers videoconference which could be accessed through different technologies. These technologies could be summarized as SIP [Handley 1999], web browser and Isabel application access, the latest being an application developed in our research group. Section 4.2 shows the main objectives of this contribution. Section 4.3 gives details of the architecture, with description of every component and showing different functionalities. Section 4.4 shows an implementation of this architecture in a real environment used by different partners in the Global Project. Section 4.5 reminds the main contribution in this chapter. Finally, section 4.6 presents some conclusions of this work.

4.2 Objectives

This contribution addresses the design, development and implementation of a new advanced videoconferencing system that follows the interface described in chapter 3. The contribution deals with the next objective, which as deﬁned in the introduction of this dissertation:

• To identify which elements are needed for videoconferencing in cloud environments. Here we describe those lements that are used in an advanced videoconferencing system for scaling and handling resources in the Cloud.

• To implement a videoconferencing system architecture fully implemented in Cloud datacentres. As a result of this contribution we explain all the architecture and how it has been used in the Cloud in the context of different projects.

This chapter basically aims to give guidelines to resolve current problems in different aspects of this contribution:

vihttp://www.global-project.eu/ viihttp://globalplaza.org 4.3. DESIGN 97

1. Cloud based resources: This architecture follows a centralized topology for videoconferences, but it will scale according to the user demands by taking advantage of Cloud Computing platforms.

2. Interoperability with current VoIP technologies: The system provides different ways to connect to conferences: SIP, Flash, etc.

3. Scheduling future events: This architecture also allows users to schedule, stream, record and play its videoconferencing events. To that extent it has been designed to schedule future conference sessions and it automatically records and streams their video and audio.

4. Validation: The whole system has been implemented and tested as part of European and National projects.

4.3 Design

The work I will explain throughout this section is based ona system that allows to schedule several videoconferencing sessions. Users create these sessions, making usage of the available resources in each moment.

The main goal of this work is to develop a videoconferencing system which can schedule, record and stream videoconferencing events. This system has an API that could be used by external applications to offer the services to their users. The access to the service could be done through different ways: SIP [Rosenberg 2002], Web browser (with Flash Player) and Isabel [Quemada 2004] and [Quemada 2005].

4.3.1 Conference Manager

Figure 4.1 shows a general architecture of the Conference Manager, which is the name of the videoconferencing system. Where only those components that are important to better understand functionality of the hybrid cloud scheduler are present.

This section describes all the components of the Conference Manager, that we can divide into three parts: 98 CHAPTER 4. VIDEOCONFERENCING SYSTEM ARCHITECTURE

REST API

Scheduler

- Cloud type - Machine type Start Stop Start Stop Event Event Session Session Machine tags Amazon EC2 Jobs

VMWare Executor VNC OCCI

Cloud Handlers Master OpenNebula GW Eucalyptus Flash Amazon EC2 GW VMWare SIP

App Handlers

Figure 4.1 : Conference Manager Architecture

Application Program Interface

This is the connection between the scheduler and third-party services. This API is based ona REST methodology [Fielding 2000], so it represents conference events and sessions as resources that are accessible through HTTP requests. Services should authenticate all these requests via the mechanism explained in chapter 3. There are many requests that the system forwards to the scheduler to create, update or remove some videoconferencing events or sessions. Each event consists of one or more sessions that will be recorded or not depending on what the service is requesting. Services will create events with several sessions by ﬁrst requesting creation of such event and then creation of all of its sessions, one by one. In ﬁgure 4.2 we can see the different resources that could be managed through this API. And table 4.1 shows the actions we need to made if we want to create, read, update and remove 4.3. DESIGN 99

events

sessions

player

streaming

web

Figure 4.2 : Conference Manager REST API

Table 4.1 : HTTP methods used for XML resources

GET POST PUT DELETE

/events

/events/{eid}

/events/{eid}/sessions

/events/{eid}/sessions/{sid}

resources and their collections. In this case, services will list events by sending a GET to /events; create new events by sending POST to /events; retrieve, update or remove an event by sending a GET, PUT or DELETE to /events/eid, being ’eid’ the identifier of the event; list the sessions by sending a GET to /events/eid/sessions, being ’eid’ the identifier of the event which will host the sessions; create a new session inside an event by sending a POST to /events/eid/sessions; and read, update or remove GET, PUT or DELETE to /events/eid/sessions/sid, being ’sid’ the identifier of the session. The first resource is Event, that represents a videoconferencing meeting, conference or class that will take place through different sessions. Below we can see an event representation in XML: 100 CHAPTER 4. VIDEOCONFERENCING SYSTEM ARCHITECTURE

eventID eventName [conference, meeting, class] [true, false] [true, false] [true, false] http://web sip://sip isabel://isabel

An event representation gives information about its identiﬁer, a name that external services will display, the type of conference that the system will run, and whether it will enable web, SIP and Isabel participation. For each of these communication methods it will offer the corresponding URL.

Regarding the sessions, we can also see its representation in a XML document below:

sessionID [true, false] [true, false] sessionName 2010-02-01 18:00:00 2010-02-01 19:05:00

In this case the representation will offer information about the session identiﬁer and name, whether the session will be recorded and streamed, and the initialization and ending date (including time of day).

Player, Streaming, Web and Editor resources will returned partial HTML code with corresponding embed tags that will reference the Flash Player applications by which users will get access to each of these resources. 4.3. DESIGN 101

Scheduler

This component is the responsible for scheduling all the videoconferencing events in order that the next component will execute them. Each event consists of several jobs that will be run in a given order to correctly start or stop the event and its sessions. The scheduler (which is based onthe Quartz scheduling framework [Cavaness 2006]) has to guarantee the proper running of the system in the way that it can not use more than a maximum number of resources, even if they are on the cloud. When there is a request for creating a new event or session it checks if there are enough available resources throughout its duration. It is also responsible for deciding at which cloud provider the machines are going to be executed. This decision is based on three parameters that depict the starting of each of these resources: The current price of the resources that are required in each cloud provider in order to execute the machine, the geographical region where the session is going to take place and the type of machine that is going to be started by the executor. All the information about the cloud provider that is going to host the machine is stored at the machine tags. There are many differences between start and stop jobs and between event and session jobs. For each event there are two jobs associated with it, the ﬁrst is the job that prepares all the necessary resources for such event. The latter does the opposite, it stops all the machines and releases all the resources that are used. It is the same with the session jobs, but the difference between events and sessions is the type of resources they are going to hold and release.

Executor

This component executes the jobs scheduled by the previous component. This is done at the time scheduled with the dispatch of the required event and the information stored within it. For example, a new start event job could be scheduled to run the required resources for that given event. Once the system dispatches an event start this component starts the machines and then the videoconferencing application with a speciﬁc conﬁguration. This application is usually Isabel since this is the core videoconferencing service of this system. As we have already mentioned above there are two types of event jobs, the start and the stop of the event. First, the start event job follows next steps: 102 CHAPTER 4. VIDEOCONFERENCING SYSTEM ARCHITECTURE

Algorithm 1 Start Event Job Algorithm Require: eventId 1: event = DB.getEvent(eventId) 2: machines = new MachineSet() 3: for all machine in VMs needed do 4: cloudHandler.instantiateVM(machine) 5: machines.add(machine) 6: end for 7: ... wait until machines are ready ... 8: Initialize machines.getMaster() 9: Initialize machines.getRecorder() 10: Conﬁgure machines.getVNC()

1. Retrieval of the event conﬁguration from the database. It is useful to choose and get the machine tags which will be started (line 1).

2. Initialization of the machines on the given clouds. In order to do this the executor uses the corresponding cloud handlers, which are tools that can communicate with the API of its cloud provider. In this step all machines will be started and it does not end until all machines are running (lines 3 to 6).

3. Execution of Isabel (or any other application such as VNC server). Once all the machines are running it starts Isabel on each machine with different parameters. Depending on this conﬁguration Isabel can work as Master, Flash gateway or SIP gateway depending on the required functions. The next section explains in detail each of these functions (lines 8 to 10).

Second, the stop event job terminates all machines:

1. Retrieval of the event conﬁguration from the database. It is useful choose and get the machine which will be terminated (line 1).

2. Reconﬁguration of default parameters in VNC, databases, etc (line 4).

3. Termination of machines by remotely shutting down via shell scripts commands (line 6).

Start and stop session jobs are only required for recording purposes. So it will only check whether the session needs to be recorded and start the mechanisms to save the video and audio streams: 4.4. IMPLEMENTATION 103

Algorithm 2 Stop Event Job Algorithm Require: eventId 1: event = DB.getEvent(eventId) 2: machines = new MachineSet() 3: for all machine in event do 4: if machine is VNC then 5: Set default VNC conﬁguration for machine 6: end if 7: cloudHandler.terminateVM(machine) 8: end for

Algorithm 3 Start Session Job Algorithm Require: sessionId Ensure: sessionId belongs to an Event 1: session = DB.getSession(sessionId) 2: if session is Recording then 3: Start Recording session 4: end if

Start session job will retrieve session information from the database (line 1) and start the recording (line 3). Stop session job will stop the recording, so it will retrieve the session information also (line 1) and then it will stop the recording as needed (line 3).

4.4 Implementation

The implementation could be seen in ﬁgure 4.3. Now we will see details of every component in this architecture. The Conference Managerorchestrates a set of different services with the goal of offering advanced videoconferencing to end users. We can split this set into the next subsets of

Algorithm 4 Stop Session Job Algorithm Require: sessionId Ensure: sessionId belongs to an Event 1: session = DB.getSession(sessionId) 2: if session is Recording then 3: Stop Recording session 4: end if 104 CHAPTER 4. VIDEOCONFERENCING SYSTEM ARCHITECTURE

VCC / Global Plaza

Conference Manager

DST

Disks

Venus REST Gateway IST IST Master Red5 GW Web VNC Recording Venus IST Recorder SER GW SIP Player Editor

Audio and Video Stream Isabel Metadata Stream Machine File access Control Operations

Figure 4.3 : Conference Manager Components

functionalities:

4.4.1 Isabel-based videoconferencing

The core of the videoconferencing system is based on the Isabel application. The Conference Manageralways launches at least one Isabel site, that acts as an MCU (or Master in figure 4.3) for other external Isabel sites that users will connect. There are other types of Isabel that are also used for special cases: the first one is used when users are going to connect through a web 4.4. IMPLEMENTATION 105 interface (using Adobe Flash technology); the other one is used when users want connect through SIP capable phones. In both cases the system will launch special Isabel sites, that are called Isabel-Flash Gateway and Isabel-SIP Gateway, respectively. The main work of the Isabel Master is to forward all traffic between those Isabel sites that are connected to it. This is not an expensive task in terms of processing and memory, so Isabel Master could also be used as a Isabel-Flash Gateway if the user wants to record the session. I will explain how recording works in other functionality set. The Conference Managerwill provide a more user-friendly hostname to the users in order to connect to the Isabel Master site. The entries for this hostname will be dynamically created in a DNS server using a scripting toolkit called DST (DNS Scripting Toolkit). All Isabel sites are installed on Ubuntu Lucid virtual machines, in both VMWare and Amazon EC2 images. So the Conference Managercan use them on any of these platforms. The Conference Manageraccess these machines once they have started by running a set of Shell scripts via SSH. This set of scripts is called IST (Isabel Scripting Toolkit).

4.4.2 Flash-based videoconferencing

In case of starting a session with Flash compatibility the system will also use some other services. The main component is a Red5 based application that controls all web users. All these users will directly connect to this component, and it will communicate with the corresponding Isabel-Flash Gateway. The Isabel-Flash Gateway is responsible for translating between Isabel protocol and Flash protocols. For example, Isabel uses RTP to send media streams between Isabel sites, while Flash uses RTMP for the same purpose in the case of Flash nodes. This gateway is also responsible for generating a video composed of the videos from all users. Every Isabel-Flash Gateway connects to the Isabel Master of the corresponding session, and it will provide access to the VNC when the users are sharing a desktop with applications.

4.4.3 SIP-based videoconferencing

When the session also supports connection from SIP phones, it will make usage of a SIP router. This router acts also as a SIP registrar, and all Isabel-SIP gateways will register in it once they are started. 106 CHAPTER 4. VIDEOCONFERENCING SYSTEM ARCHITECTURE

The Isabel-SIP Gateway will translate between Isabel and SIP protocols, codecs, and mechanisms. For example, it can use H.264 for the videos in the Isabel session while it uses H.263 for coding the video that will be sent to the SIP clients. It will also generate a video in the same way than the Isabel-Flash Gateway.

4.4.4 VNC and desktop sharing

All videoconferencing sessions will give tools to share desktop applications. These tools consist of a set of Windows machines (all of them are virtual machines that will dynamically start and stop with the sessions), and a remote file system that will be mounted by every Windows machine to get access to the documents offered by the external services. The Conference Managerwill provide a file system to all the Windows instances. These instances will remotely mount the file system via Samba protocol. The documents in this file system could be open and edited in the Windows instance by using a set of applications that are previously installed: Microsoft Office, Adobe Reader, Google Chrome, and so on. And users are able to use it if they connect to an Isabel site or a web client.

4.4.5 Recording

All sessions are prone to be recorded if the users want to. For record these sessions the system uses an Isabel-Flash Gateway to create a Flash-based video and audio stream. And it will also use a recorder, called Venus, that will be managed through a REST API called Venus REST Gateway. Venus is a Flash Media Server application that receives the video generated from the Isabel- Flash Gateway and stores it in the shared ﬁle system, mounted via NFS. It also provides a player to show the recorded videos and an editor to modify the metadata that is attached to the video. This metadata mainly has information about the start and stop times.

4.5 Contribution

This chapter shows the implementation of a videoconferencing system architecture. I have explained the different parts of an advanced videoconferencing system and how I divided it into several resources. This system is based on the Isabel application and I implemented a scheduler to set up future or ongoing Isabel sessions. The system also provides a novel interface that is a 4.6. CONCLUSIONS 107 extension of Nuve, with additional features to schedule conference sessions. This system has been called Conference Manager. It is part of a service which offers to the users a possibility to schedule videoconferencing sessions through a web portal used within an European project. The users could attend to each of these sessions through the web and even take part of the meetings that would be created with this application. With this tool several users could get access to a single videoconferencing session and control it. This control is based on the interaction modes that are setup at different moments (presentations, conferences, questions, etc.). The system presented takes into account the different resources needed to set up a videoconference and reacts accordingly . In this project I developed a new service that offers videoconference which could be accessed through different technologies. These technologies could be summarized as SIP, web browser and Isabel application access, the latest being an application developed in our research group.

4.6 Conclusions

This and other systems could benefit from this Cloud infrastructures by using a virtual infrastructure manager and a scheduler that starts the resources required for a service in the most appropriate Cloud provider based on its location, price and resource type. The architecture could be further developed in order to being as general as possible and abstract details of the system being managed by the scheduler and the executor. At the moment of writing this chapter we have used this architecture in several real case scenarios, such as videoconferencing events with users participating from different countries. There were two main types of participation: the first one was joining the session to talk and make presentations, the second one was just watching the conference through web video streaming. Finally, figures 4.4a and 4.4b show several connections made around the world to take part in the Conferencia Rails 2010 and an Isabel Workshop. These were real life scenarios that used the described architecture. 108 CHAPTER 4. VIDEOCONFERENCING SYSTEM ARCHITECTURE

(a) Conferencia Rails 2010

(b) Isabel Workshop

Figure 4.4 : Videoconferencing real scenarios Chapter 5

Methodologies for Testing Cloud Computing Infrastructures

In previous chapters I commented that the improvements in Internet access technologies e.g., the availability of high bandwidth and the spread of portable media player devices have opened new opportunities to receive, send and process high quality, on-demand, and interactive multimedia applications. In the recent years, videoconferencing developers have improved their applications in terms of quality and to meet the new heterogeneity of terminals, such as TV, Laptops, mobile phones or tablets, that also goes hand in hand with the variety of network connections including ADSL, Cable Modem, UMTS, WiFi, etc.

5.1 Introduction

Cloud computing has emerged as a ﬂexible paradigm for facilitating resource management for elastic application deployments at unprecedented scale. Cloud providers offer a shared set of machines to cloud tenants, often following an Infrastructure-as-a-Service (IaaS) model with different resources that are commonly shared among different machines, such as hard disks, CPUs, network devices, RAM, and so on. Tenants create their own virtual infrastructures on top of physical resources through virtualization. Virtual machines (VMs) then act as execution environments for applications. Today, there are a wide variety of deployments in the Cloud. We can ﬁnd multiple examples of multimedia and streaming applications in the Cloud, such as the distributed stream processing systems (DSPS) that execute continuous queries in real-time [Cranor 2003, Abadi 2005]. While deployments of DSPSs in the cloud promise to exploit its inherent elasticity, an open problem is how to provision resources (i.e. CPU, memory and network bandwidth) in response to sudden, time-varying changes in stream workloads. The same happens to other multimedia stream applications, such as videoconferencing applications. The real-time nature of stream processing poses unique challenges due to the need to achieve low latency and guaranteed throughput. One of the goals of this contribution is to explore the 110 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES performance implications of deploying DSPSs on a public cloud infrastructure and to propose an approach for allocating VMs based on workload demands in order to maintain a given target throughput with low latency. Given that it has similar requirements to traditional multimedia streaming applications in this contribution I also research how the network from those infrastructures can also transmit real-time data between virtual machines in the cloud. This chapter reports experimental validations of multimedia streaming architectures in terms of quality of service (QoS). For doing this, I carried out three different test cases:

• First of all I measured generic network QoS parameters, and I checked whether and up to which level it is reasonable enough to use a Cloud provider network for forwarding live streaming data. Despite research like [Ferretti 2010] on QoS such as timeliness, scalability, availability, trust and security required in cloud SLA agreements, or performance and load balancing issues, I found a gap of measurements in multimedia and stream processing applications for QoS such as latency, bandwidth, packet loss and jitter in real scenarios combining clients and provider inside and out of the cloud.

This test case is aimed to be generic by measuring all QoS parameters that affect both type of systems. The results show that the main factor dominating performance is the latency introduced by the cloud deployment. On the other hand, there is no signiﬁcant throughput reduction when VMs are not overloaded for both systems.

For the following two cases I divided the study into multimedia applications and distributed stream processing systems.

• Next, I designed four different multimedia scenarios that comprise most of the service real use cases. These scenarios represent a streaming distribution network, where the network nodes could be located in the Internet or inside the cloud infrastructure. The main goal of this study was to qualify the hybrid network’s ability to transmit multimedia streams and also to analyse the trade off between nodes placed in the cloud and peers placed inside a commercial network. Therefore the idea is not to make any comparison among public, private or community cloud, rather to rely on PlanetLab [Chun 2003] nodes as particular peers that would interoperate with nodes placed in a cloud infrastructure. The obtained results conclude that some scenarios allow to enhance the overall QoS of the streaming service when Cloud network is used to forward streaming sessions among distant peers. For 5.2. OBJECTIVES 111

the scope of the measurements I chose the most signiﬁcant Cloud provider at this moment - Amazon i, leaving out the rest of the providers for future comparisons of the results. I chose PlanetLab nodes as an example of experimental peers, since I could obtain variety of machines in different locations around the world that could serve me to represent the P2P part of the architecture.

As it was commented in chapter 2 the reader can ﬁnd other studies for available Cloud infrastructures, like [Wang 2010], but they do not deal with detailed network QoS, at least not for those that are important for real time streaming services. Due to this I extended this research to know exactly the response of those networks.

Instead of simulating the different scenarios with software applications I implemented all of them in existing infrastructure available at a Cloud provider and in PlanetLab nodes around the world. Thus, the results can be taken as real proof that validates one segment of the previous architecture proposal.

• Finally, I propose an adaptive algorithm that resizes the number of VMs in a DSPS deployment in response to workload demands by taking throughput measurements of each involved VM. I evaluate the provisioning approach experimentally by deploying it as part of a DSPS on the Amazon Elastic Compute Cloud (EC2). I show that it works well regardless of the computing power of the underlying VMs.

Section 5.2 shows the objectives of this contribution. Section 5.3 contains the ﬁrst measurements of the cloud provider network, that is the ﬁrst step to know how a Cloud infrastructure can enhance the multimedia system responsiveness. Section 5.4 explains the different test scenarios in which I was introducing different Cloud hosted nodes for improving the QoS and it reports the obtained results. Section 5.6 describes the main contribution in this chapter. Finally in section 5.7 I comment some conclusions based on these results.

5.2 Objectives

Summarizing the introduction, this contribution aims to test current Cloud infrastructures, giving results in addition to guidelines and methodologies used within this process.

ihttp://aws.amazon.com/ec2/ 112 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

• To test the suitability of Cloud Computing networks in the context of real-time multimedia data. In this chapter we evaluate the main network QoS parameters to check whether they could support data sent through the Cloud network: latency, bandwidth and packet losses. For doing this we simulate different scenarios and implement them on real infrastructures.

• To test if Cloud Computing virtual machines are suitable for processing real-time multimedia data. This contribution evaluates if best-effort VMs are appropriate and have the sufﬁcient level of predictability to support the strong requirements of real-time multimedia systems. In this case we also provide an adaptive algorithm that resizes the number of VMs in these systems.

5.3 Amazon Network Measurements

Amazon Iperf Server US-East-1

Iperf Client ping

Amazon Amazon EU-West-1 AP-Southeast-1

Figure 5.1 : Architecture of the measuring environment

As mentioned in chapter 2, there exist related research about Amazon network performance (in terms of bandwidth) and computer processing capacity in different kinds of virtual machines. 5.3. AMAZON NETWORK MEASUREMENTS 113

In this section I want to extend this research in order to evaluate the network QoS of the different datacentres around the world owned by Amazon. Regarding stream processing mechanism in the cloud I wanted to answer the following questions: Is it feasible to stream data from sources on the Internet to various public cloud data centre (DC) sites, as provided by Amazon or Google? In other words, can wide-area Internet paths support streaming data into cloud DCs? I also investigate if IaaS clouds are suitable for hosting stream processing systems. Do best effort VMs have a sufﬁcient level of predictability to support low-latency, low-jitter and high-throughput stream processing? Is the computational power of Amazon EC2 VMs appropriate when used for standard stream processes tasks? I will start by explaining some network features to be measured in the experiments and I will discuss their importance in video and audio streaming. Afterwards I will present the environment’s architecture, giving some details about each component and the datacentres to be examined. Later I will show the results of the measurements and I will ﬁnish by interpreting the collected data, concluding about the observed QoS of the Amazon cloud and whether the network is able to transport video and audio streams at real time.

5.3.1 Important network features

In [Wang 2010] we can see how Wang measures the network performance over different kinds of virtual machines and shows that using Amazon Small Instances is harmful to the network responsiveness. The metrics they use are always inside a local datacentre, excluding measurements between distant ones. I extended this work and based on their arguments to measure the network performance between different Amazon datacentres. The work in [Li 2010a] shows how different Cloud providers can offer varying performance in the execution of applications depending on various aspects, like the variation of the requests sent by the clients and the infrastructures owned by Cloud providers. A conclusion of this work is the importance of the network performance offered by the Cloud provider and the responsiveness in trafﬁc between different datacentres of the same provider. The limit of this study is that it does not take into account various datacentres, so this part of the study needs to be improved in order to test the hypothesis for my architecture. For doing this, I considered four important network parameters for multimedia streaming and 114 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES for many other real-time services: bandwidth, delay, jitter and packet losses. These are the traditional QoS parameters taken into account in real-time communication applications.

Bandwidth

Traditional streaming users and clients are supposed to be behind a wide range of access networks such as xDSL, Wiﬁ, etc. Thus, any streaming service must allow conﬁguration for different bandwidth capabilities. Another thing to keep in mind is that there is no communication bottleneck in the core network in any of the cases examined. Therefore, in these tests I also had to measure the limits of available Amazon network’s bandwidth. In stream processing system the bandwidth can vary depending on the amount of data received in the DSPS system. This data could vary in time with changes in the workload.

Delay

I previously mentioned that clients can join the service from different access points. I therefore have to take into account additional network delays in their connections. They also could access from different places in the world, including regions, countries and even continents. Thus the core network that will be used only as a transport network may introduce inherent propagation delays. For stream processing systems the delay is a key factor when designing the DSPS architecture, because it is usually the strongest requirement for clients. When the system is hosted in the cloud the system could be placed in different parts of the world, introducing additional delay, so we have to be cautious when implementing these systems. In this study I checked wether cloud network and virtual machines introduces high delay values.

Jitter

It is the variation in the time between packet arrivals caused by network congestion, timing drift, or route changes. Jitter could manifest in different ways depending on the application that is used. Web browsing is fairly resistant to jitter, but any kind of streaming media (voice, video, music) is quite sensitive to it. As for these reasons jitter is an undesired parameter in any network connection, and according to ETSI [McLellan 2010] it is very important that the amount of jitter is lower than 20 ms in VoIP applications. In DSPS scenarios Jitter is eventually added to the delay 5.3. AMAZON NETWORK MEASUREMENTS 115 because applications usually implement buffers for incoming data that transforms the variable jitter into ﬁxed delay, so it is equally important for these systems as well.

Packet loss

Packet loss can occur for a variety of reasons including link failure, high levels of congestion that lead to buffer overﬂow in routers, Random Early Detection (RED, a technique used in routers to apply congestion control), Ethernet problems or an occasional misrouted packet. Packet loss causes degradation in voice and video quality. If packet loss concealment (PLC, a technique used to mask the effects of lost or discarded packets) is used then isolated losses may be less noticeable. But for example when packet loss occurs in bursts of 20-30% loss lasting 1-3 seconds, this can mean that the average packet loss rate for a call appears low, although the user reports call quality problems. In this study I want a core transport network with a very low packet loss rate.

Furthermore stream processing systems are very sensitive to packet losses in scenarios with high QoS levels, so it is very important to know what the limits are in the case of host these applications in the cloud.

5.3.2 Architecture of the measuring environment

Figure 5.1 represents the architecture of the Amazon measurement phase. In this ﬁgure we can see three Amazon datacentres in which I executed several virtual machines. Some of them were used as servers and others were used as clients. In the clients I run the tool iperf and ping applications that took measures about the connections established to the servers. Every virtual machine is a Large Amazon instance that ran Ubuntu Server operating system (Ubuntu Karmic 9.10 AMD64 Server).

The three amazon datacentres used here were from different sessions: US-East-1 in Northern Virginia, EU-West-1 in Ireland and AP-Southeast-1 in Singapur. There is one more region in California that I considered no relevant because of its proximity to the US-East-1. Among the applications I run the iperf in server mode for bandwidth, jitter and packet loss measurements with the set up commands as explained below. 116 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

Server Bandwidth

Sends and receives packets using only one TCP connection with read and write buffers size set to 8 KB, maximum segment size equals to 1460 bytes and window size set to 85.3 KByte. iperf -i 10 -s -p 6031 -f k -y C

Server Jitter and packet loss iperf -i 240 -s -u -p 6032 -f k -y C

I also run iperf in client mode for bandwidth, jitter and packets loss measuring:

Client Bandwidth

The conﬁguration is same as in the server. iperf -t 3000 -i 10 -c serverHostname -p 6031 -r -L 6030 -f k -y C

Client Jitter and packet loss

The read and write buffers size are set to 8 KB. iperf -t 3000 -i 240 -u -c serverHostname -p 6032 -L 6030 -f k -y C

Finally I made measurements of network delay using the ping test tool.

5.3.3 Measurement results

In the ﬁgures 5.2, 5.3, 5.4 we can see the same four graphs respectively: the bandwidth graph represents the cumulative distribution function (CDF) of the tests that measured the amount of the available data bitrate in each connection between two regions, measured in bits per second. Jitter graph represents the CDF of the jitter in these connections, packet loss graph represents the probability density function (PDF) of the packets loss detected between them and ﬁnally Round Trip Time (RTT) graph indicates CDF of the round trip time delays between two nodes in different regions. 5.3. AMAZON NETWORK MEASUREMENTS 117

Bandwidth 1 0.8 Incoming

0.6 Outgoing

CDF 0.4

0.2

0 106 107 108 bits/second

Jitter 1

0.5 CDF

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 ms Loss 1

0.5 PDF

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 % x 10−4 RTT 1

0.8

0.6

CDF 0.4

0.2

0 90 92 94 96 98 100 102 104 106 108 110 ms

Figure 5.2 : Measurement results between datacentres EU-US

Measurements between regions

Figure 5.2 represents the measurements between Europe and USA regions, ﬁgure 5.3 represents the measurements between Europe and Asia regions, and ﬁgure 5.4 represents the measurements between USA and Asia regions.

Based on the bandwidth graphs the average is over 45 MBits per second for a single sender thread. Meanwhile jitter results show a jitter bounds between 0.1ms and 1ms, which is enough even for VoIP communications. Regarding the loss rate, the tool proved that it is low enough and appropriate for streaming purposes. Finally RTT follows typical values for connections between 118 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

Bandwidth 1

0.8 Incoming

0.6 Outgoing

CDF 0.4

0.2

0 106 107 108 bits/second Jitter 1

0.5 CDF

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 ms Loss 1

0.5 PDF

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 % x 10−4 RTT 1

0.8

0.6

CDF 0.4

0.2

0 260 265 270 275 280 285 ms

Figure 5.3 : Measurement results between datacentres EU-AP 5.3. AMAZON NETWORK MEASUREMENTS 119

Bandwidth 1

0.8 Incoming

0.6 Outgoing

CDF 0.4

0.2

0 106 107 108 bits/second Jitter 1

0.5 CDF

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 ms Loss 1

0.5 PDF

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 % x 10−4 RTT 1

0.8

0.6

CDF 0.4

0.2

0 240 245 250 255 260 265 ms

Figure 5.4 : Measurement results between datacentres US-AP 120 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

Cloud Europe Asia PlanetLab USA node instance

SOURCE PROCESSING ENGINE

Figure 5.5 : Experimental set-up for network measurements

distant peers. As a result of the measurements explained above, we can infer that using a cloud provider such as Amazon to stream multimedia content is highly efﬁcient and meets the QoS requirements of a streaming distribution service.

5.3.4 Network Measurements for Stream Processing Systems

I implement a scenario, in which a node (i.e. the stream source) sends stream data to another node (i.e. the stream processing engine) for processing. I place the engines in different Amazon DCs distributed around the world: I select a DC in the US, one in Europe and a third in Asia (cf. Fig. 5.5), repeating a set of measurements in each. The engines use a large Amazon EC2 instance, which has 7.5 GB of memory and 4 EC2 compute unitsii. The sources are hosted on nine PlanetLab nodes to emulate a global set of data sources (three in Asia, three in Europe and three in the US). Each set of nodes is associated with the nearest Amazon EC2 DC. For each DC location, I conduct several experiments divided into three basic runs, involving a different PlanetLab stream source node with the same Amazon node. I repeat each experiment with three source rates: 10 kbps (low), 100 kbps (medium) and 1 Mbps (high). The experiments are conducted over a 24-hour period, computing averages to avoid undesired effects due to variations in Internet trafﬁc. Results. Fig. 5.6 shows the average jitter experienced by packets sent from each PlanetLab source to the engine. I observe that the average jitter is less than 2.5 µs, although some outliers exhibit a

iiTypically, one EC2 compute unit provides the equivalent CPU capacity of a 1.0–1.2 GHz 2007 AMD Opteron or a 2007 Intel Xeon CPU. 5.3. AMAZON NETWORK MEASUREMENTS 121

high rate medium rate low rate 4000

2000

0 Jitter (ms)

1 2 3 4 5 6 7 8 9 PlanetLab nodes

Figure 5.6 : Jitter experienced when sending streams to Amazon EC2

300

200 ideal america 100 asia

Network−Level europe 0 Round−Trip Time (ms) 0 50 100 150 200 250 Application−Level Round−Trip Time (ms)

Figure 5.7 : Comparison of network- and application-level delay on Amazon EC2

value of almost 4 seconds. To compensate for this, a DSPS would need to use a buffer size of at least this size, increasing overall system latency, or to discard these items. The observed level of jitter appears independent of the stream rate, and I believe that it is dominated by network effects.

In terms of application-level delay, I show the relationship between measured network-level and application-level round-trip delay in Fig. 5.7. Application-level round-trip times are obtained by comparing the timestamps when a tuple is sent by the source and when the result tuple is received by the same source after processing by the engine. Network-level round-trip times are reported based on ICMP ping messages between the two machines. We see that the cloud DC does not cause application-level delay to increase. It is instead dominated by the network latency of the wide-area Internet paths. 122 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

Day 1 Day 2 50 (ms) Latency

0 4 x 10

2 (tuples/s) Throughput 0 7 8 9 10111213141516171819 7 8 9 10111213141516171819 Time of day, 24−hour format Time of day, 24−hour format

Figure 5.8 : Performance of Esper as a function of time on Amazon EC2

5.3.5 Processing measurements for Stream Processing Systems

Next I benchmark processing performance. I deploy the Esper stream processing engine iii with several types of VMs available on Amazon EC2, and I explore if there is performance variation correlated with the time-of-day, affecting processing latency and throughput. Esper processing engine. Esper processes continuous streams of time-based data. I use the native Esper benchmark tool that is composed of a data generator and a submitter. It generates a stream of shares and stock values for a given symbol at a fixed rate, set as a configuration parameter. In my case, I set the rate to be 30,000 stock values sent per second, generating a stream with 1000 different symbols. A query, which is defined in the Esper language, calculates the maximum stock value of a symbol in each second. Since my goal is to explore if time-of-day variation affects processing latency when VMs are overloaded, I separate processing from network latency by placing all nodes in the same Amazon EC2 DC located in Virginia, US. I carry out 10 runs, executing processing engines in small VM instances with 1.7 GB of memory and 1 EC2 compute unit. The submitter machines are extra large instances with 15 GB of memory and 8 EC2 compute units. Each submitter sends 30,000 tuples/second to the engine to potentially overload it.

Results. The results in Fig. 5.8 show the variation of processing latency and throughput during different times over two week days. The observed throughput remains relatively stable over the

iiihttp://esper.codehaus.org/ 5.3. AMAZON NETWORK MEASUREMENTS 123

5 Small VM instances Large VM instances x 10 2 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4

Throughput − tuples/s 0.2 0 1 3 5 7 9 11 13 15 17 1 3 5 7 9 11 13 15 17 Input Data Rate − x10000 tuples/s Input Data Rate − x10000 tuples/s

Figure 5.9 : Increase in throughput with different instance sizes on Amazon EC2 (Different shades/colours correspond to different VMs.)

measurement period, although latency suffers more from unpredictable outliers. I did not find an obvious pattern that correlated cloud performance with time-of-day for best-effort VMs, i.e. there is no significant variation consistent across multiple week days. Next I examine how cloud VMs support increasing input data rates. I manually increase the number of VMs running Esper engines, while also gradually changing the stream rate from 100,000–200,000 tuples/second. The Esper submitter is deployed on an extra-large EC2 instance. When a VM is close to saturation, i.e. the engine cannot process all incoming data, I manually add another VM of the same type. Fig. 5.9 on the left plots the throughput when using small VM instances and large instances are presented on the right. Different patterns represent different VMs of both instance types. I can see that the cloud VMs can be used to scale efficiently with an increasing input rate, achieving higher throughput. The number of VMs required to obtain a given throughput value depends on their type: as expected, fewer large than small instances are needed to achieve the same throughput. While running these scenarios I did not experience any significant degradation in the CPU performance and throughput that could be explained by VM co-location.

5.3.6 Discussion For Stream Processing Systems in the Cloud

I considered metrics related to cloud-deployed stream processing systems. First, end-to-end latency is composed of network and processing latency. The results show that network latency is 124 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES dominated by the geographic distance between the cloud DC and the sources, and the virtualised cloud infrastructure itself does not increase end-to-end latency signiﬁcantly. Therefore, it is preferable to deploy stream processing engines at cloud sites within close network proximity to sources. Second, it is important to consider that jitter suffers from high outliers that can be orders of magnitude above the average. Typically systems compensate for jitter through buffering or discarding of late-arriving data. In my experiments, discarding delayed data items would have resulted in a small percentage of lost data (approx. 3%). In summary, when deploying a DSPS in a public cloud, it is necessary to understand the tradeoffs when scaling to different numbers of VMs. A challenging issue is to decide on the right number of VMs and their instance types to support a given stream processing workload. After deployment, it is necessary to monitor the performance of processing VMs, and if they show decreasing throughput, to scale out to more VMs.

5.4 Multimedia Streaming Experiments

In this section I present several scenarios deployed in a tree based streaming distribution network. The nodes of the distribution network are located in different geographical points around the world. Initially, all the nodes are located in the Internet but outside the cloud infrastructure, and, some of them are moved into the cloud infrastructure. The idea of this experiment is to measure the improvements in terms of quality of service when I gradually move network nodes from Internet to a cloud infrastructure. I use PlanetLab[Chun 2003] to be able to spread geographically the distribution network nodes in Internet, and Amazon as cloud provider. To further approximate a real scenario, I used in the tests real video trafﬁc, in order to compare the results to the actual requirements of a multimedia transmission in terms of QoS. In the ﬁrst subsection I describe the tools used in the measurements as well as the parameters to be measured. After that, I describe the general architecture of the experiment scenarios and the experimental setup. Finally the results are presented.

5.4.1 Tools and statistics

Before presenting the architecture itself I will describe the tools used and the way the statistics are obtained. I need a set of components that allow me to generate media and redistribute it. 5.4. MULTIMEDIA STREAMING EXPERIMENTS 125

Furthermore, these parts need to be flexible and easily automatable to make the measuring process as smooth as possible. I have based the tools on a previously developed project toolkit, changing them in accordance to my need and making the necessary adjustments in the environment in order to be able to gather statistics. The tools I use come from the system Isabel [Quemada 2005], a multipoint group collaboration tool which includes video and audio conferencing. The low level components of Isabel are daemons coded in C/C++ that can be operated via a control port using a set of primitives. The video component is able to encode, decode, transmit, receive and present video in a wide variety of codecs. Furthermore, it can be configured to broadcast video from a file or from a synthetic source of video in different sizes, bit-rates and codecs. Real-time Transport Protocol (RTP) is used to transmit media. The second component and the most important in terms of characterizing the network is called irouter and its main objective is to receive and forward packets from and to other components including other irouters. In my scenarios the irouter will receive data from the video daemon, present it and then forward it to other irouters. This component was modified to gather data from all incoming packets and to generate the statistics that I will process and present in the results subsection. For practical reasons, the irouter component dumps the raw data in text files that will later be collected and processed statistically in order to separate the actual measurement process from the calculations. The data accumulated is roughly equivalent to that explained in the Intra-Cloud measurements described in this document. I will now explain the data collected by the irouter defining each parameter:

• Packets received The total packets received in an interval.

• Bytes received The number of bytes received in an interval.

• Packets lost The amount of packets lost in an interval. A discontinuity in the sequence number of RTP packets is perceived as a loss.

• Packets disordered A packet is considered disordered if it arrives in time to ﬁll a gap in sequence numbers. It is considered to be âAIJin˘ timeâA˘ I˙ if it arrives in the same interval. 126 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

• Packets duplicated A packet is considered duplicated if two packets with the same sequence number arrive anytime.

• Packets recovered When forward error correction (FEC) is active, packets recovered via this mechanism are recorded here.

• Inter-Packet Gaps (IPGs) The difference in time in the arrival of two consecutive packets. IPGs are used in order to calculate an average of the jitter introduced by the network. As explained in [Imran 2007] you can theoretically obtain an accurate approximation to an upper bound of jitter using:

1 N 2 = i (IPG (i) − E[IPG(i)])2 σ ∑ j=2 j Ni − 1

J(i) = 3σ

For a normal distribution of random jitter this value means that the 99.7% packets will arrive with a jitter lower than J(i). But in in practice it does not follow a Normal distribution because there are several external causes other than only random noise. So I preferred to calculate directly the 99.7 percentile of values in:

|IPG j(i) − E[IPG(i)]|

5.4.2 Scenario architecture description

To test multimedia streaming in the Cloud I designed 4 scenarios in 4 levels, to gradually introduce the distribution network nodes from Internet to the cloud infrastructure. The cloud provider I used was Amazon with instances equivalent to those explained in section 5.3. To locate the nodes outside the cloud provider I used PlanetLab that offers several nodes in different countries. I also divided geographically the location of the peers to further expose the challenges found when distributing multimedia content among different continents, and to see the advantages of having geography in mind when designing the topology of the distribution. As shown in ﬁgure 5.10 I divided the scenarios into three different zones: Europe, America and Asia and I located 4 peers forming a tree topology. The distribution of the nodes was designed according to the location of Amazon available EC2 locations at the time of planning the tests, that is, roughly 5.4. MULTIMEDIA STREAMING EXPERIMENTS 127

1 Norway

2 USA-1 France Taiwan

Puerto USA-2 Italy Germany Japan China 3 Rico

4 Brazil Spain Korea

Figure 5.10 : Node distribution

West USA, East USA, Europe and Asia. By locating the PlanetLab nodes in those areas I can effectively compare the effect on the performance when distributing content with the Amazon network infrastructure. The typical PlanetLab hardware is 4x Intel cores @ 2.4Ghz with 4GB RAM, well beyond the needs for this measures. With those assets, I defined four scenarios by progressively locating the levels of the hierarchy in the closest possible location given by the cloud provider. Thus, in the Scenario 1, all the nodes are PlanetLab machines located in the country specified in the figure. In the Scenario 2, the level 1 node (the source node at Norway) is replaced by one node located in the European datacentre of Amazon. In the Scenario 3, the second level nodes USA-1, France and Taiwan are replaced by the corresponding Amazon nodes located in the USA, Europe and Asia datacentres respectively. Finally, Scenario 4 substitutes the level 3 nodes (Puerto-Rico, USA-2, Italy, Germany, Japan and China) by the the corresponding Amazon nodes located in USA, Europe and Asia datacentres. The type of traffic used for the test aims to reproduce a real video streaming as seen in many internet services. As was mentioned above, RTP was used for transmission, and the transmitted video streaming was a test pattern of 640x480 pixels encoded in MPEG-4 with a bitrate of 500 128 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

Kbps. In order to discard outliers, three executions of each experiment scenario were run and average values were calculated. It should be noted that only Scenario 1 generated a high variability in the obtained results. Executions were run from Monday to Friday during business hours when Planetlab nodes were available.

5.4.3 Results

Figures 5.11, 5.12 and 5.13 show the values of jitter, bytes received and packet loss, observed by each node in the streaming distribution tree. The formerly described four scenarios are shown consecutively in X axis, and the nodes in each scenario are also grouped in X axis by geographical criterion. The figure 5.11 shows the 99.7th percentile of jitter values obtained by running the experiment in the four scenarios. This figure indicates clearly that the jitter values decrease when some levels of the distribution tree are moved into the cloud network. In Scenario 1, as expected, with all the communication links outside of the Cloud provider network, significant jitter problems appeared, mainly when the streaming session packets crossed intercontinental links from Europe (Norway) to America (USA-1), and so, the whole subtree (USA-1, Brazil, PuertoRico and USA-2 nodes) suffered from big jitter values. Even when the source node was moved inside the cloud provider (Scenario 2), the jitter values were still bad when the packets jumped outside the Cloud network from Europe to America. However, when the root nodes of each continental sub-tree (USA-1, France, and Taiwan) were moved into the cloud network (Scenarios 3 and 4) and the intercontinental jumps were fully deployed inside the Cloud network, the measured jitter values decreased significantly. Observing the obtained jitter values in Scenario 3 and 4, it is not expected to have severe jitter problems[Karlsson 1996] even if a multi-conference service was deployed. Also, it must be observed that jitter values did not improve significantly when the third level nodes of the distribution network were moved into the cloud. This is because the jitter problems appeared mainly when crossing intercontinental links from the source node to the second level nodes and so, enhancing the connectivity between second and third level nodes did not generate significant improvements in the obtained jitter values. The figure 5.12 shows in box plot format the distribution of the streaming session throughput for each scenario and for each network node. The number of bytes received in each node is 5.5. ADAPTIVE CLOUD STREAM PROCESSING ALGORITHM 129 accumulated during periods of 400 seconds, and a summary of five values is shown in each box plot: minimum value, lower quartile, median, upper quartile and largest value. Again, Scenario 1 shows a high variability in the number of bytes received (mainly in American nodes). The rest of scenarios exhibit a nearly uniform throughput distribution, and so, we can hold that the throughput problems are mainly found in intercontinental jumps when only Internet links are used. These problems can be nearly eliminated, moving the source node into the Cloud network (scenarios 2, 3 and 4). In these scenarios, some links of the intercontinental path that the session packets traverse, are internal transmission links of the Cloud network. These links exhibit a better throughput than the corresponding Internet external links that the PlanetLab nodes will use to jump between continents, and so, the overall throughput response of the intercontinental path, where the source is inside the cloud, will improve. Finally, the figure 5.13 shows the number of packet losses that appeared during the transmission of the streaming session. I represent for each scenario the observed packet losses in each network node. Again, due to the better quality of the cloud provider network infrastructure, its transmission links generated less packet losses than the corresponding Internet links of PlanetLab nodes. In this way, the packet losses were accumulated for each link of the path of the streaming session. As this value was lower in cloud links, the more nodes are within the cloud, the less packet losses will occur. This situation can be observed clearly in Scenario 4, where only the nodes outside of the cloud (Brazil, Spain and Korea) accumulate a bigger number of packet losses that the other nodes that are inside the cloud in this scenario. The conclusions of this section are:(a) the jitter problems are nearly eliminated if the source and destination node of each intercontinental jump are located both in the cloud, (b) the throughput problems are alleviated moving into the cloud the source node of each intercontinental jump, and (c) the number of losses decreased as I was adding nodes to the cloud.

5.5 Adaptive Cloud Stream Processing Algorithm

I now present an adaptive algorithm to scale the number of VMs required to deploy a DSPS in the cloud. My goal is to build an elastic stream processing system that resizes the number of VMs in response to input streams rates. The goal is to maintain low latency with a given throughput, while keeping VMs operating to their maximum processing capacity. I assume that a workload can be partitioned among multiple VMs, balancing streams equally across them. I also assume that there 130 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES are always sufﬁciently many VMs available to scale up to workload demands. As shown in Fig. 5.14, I assume that the DSPS executes a query, which can be decomposed across multiple VMs by splitting the query into sub-queries, each processing a sub-stream on a given engine. The input stream can be equally partitioned into sub-streams. For example, queries that compute aggregate and topK functions are naturally decomposable in this fashion. The results from sub-queries are then sent to a collector that merges them by executing another sub-query, emitting the overall query result. I further assume that load shedding is employed by the DSPS in overloaded conditions to sustain low-latency processing. My proposed provisioning algorithm uses a black-box approach, i.e. it is independent of the speciﬁcs of queries running in the DSPS. It scales the number of VMs used solely based on measurements of input stream rates. It detects an overload condition when a decrease in the processing rate of input data occurs because of discarded data tuples due to load-shedding. The algorithm is invoked periodically and calculates the new number of VMs that are needed to support the current workload demand. This number can be larger than (when the system is overloaded and requires more resources), smaller than (when the system has spare capacity) or equal to the current number of engines. The aim is to maintain the required number of VMs, operating almost at their maximum capacity.

5.5.1 Algorithm

I present the provisioning algorithm more formally in Alg. 5. The algorithm takes as input the aggregate rate of the input stream, totalInRate, and the number of VMs currently used by the DSPS, N. It also takes maxRatePerVM, which is the maximum rate that a single VM can process, from previous invocations based on measurements in overload conditions. The algorithm takes a conservative approach, in which it gradually increases the number of VMs to reach the required set for sustainable processing. The output of the algorithm is the number of VMs, N0, that is needed to sustain totalInRate. In this case, totalInRate is divided equally among VMs and each handles projRatePerVM. The algorithm initially estimates the stream rate each VM is expected to process, expRatePerVM, given the number of running VMs and the total input rate (line 1). expRatePerVM is used to decide if the current partitioning of the input stream across VMs is adequate to support totalInRate. To this end, the algorithm calculates the difference between 5.5. ADAPTIVE CLOUD STREAM PROCESSING ALGORITHM 131

Algorithm 5 Adaptive provisioning of a cloud-based DSPS Require: totalInRate, N, maxRatePerVM Ensure: N0 s.t. projRatePerVM ∗ N0 = totalInRate 1: expRatePerVM = btotalInRate/Nc 2: totalExtraRateForVMs = 0; totalProcRate = 0 3: for all deployed VMs do 4: totalExtraRateForVMs+=expRatePerVM-getRate(VM) 5: totalProcRate+=getRate(VM) 6: end for 7: avgRatePerVM = b(totalProcRate/N)c 8: if totalExtraRateForVMs > 0 then 9: N0 = N + d(totalExtraRateForVMs/avgRatePerVM)e 10: maxRatePerVM = avgRatePerVM 11: else if totalExtraRateForVMs < 0 then 12: N0 = dtotalInRate/maxRatePerVMe 13: end if 14: projRatePerVM = totalInRate/N0 15: return N0

expected and processed data rates across VMs, totalExtraRateForVMs (lines 3–5). Note that the function getRate(VM) returns the current processing rate for a given VM. In line 6, the algorithm calculates the average processing capacity per VM, avgRatePerVM, in terms of processing input rate (line 6).

A positive value of totalExtraRateForVMs (line 7) indicates that the current number of VMs N is inadequate to support the incoming totalInRate. Therefore, we need to increase the number of VMs to N0, which is calculated by dividing the additional stream rate needed, totalExtraRateForVMs by the average processing capacity per VM, avgRatePerVM (line 8). At this point, the maximum processing capacity of each VM, maxRatePerVM, is updated (line 9). It is updated each time an overload condition is detected and maintained between invocations of the algorithm. If there is excess of processing capacity, i.e. totalExtraRateForVMs is negative, we scale down VMs (lines 10-11). This is done by estimating the number of VMs required to support totalInRate, given that the maximum processing capacity per VM is maxRatePerVM (line 11). Note that this approach assumes that the input stream is equally partitioned across VMs. The stream rate sent to each VM is given by projRatePerVM (line 12). 132 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

5.5.2 Implementation

I implemented a prototype version of the adaptive algorithm as a shell script. It is integrated with the Esper processing system engine and uses a framework to control VMs and to collect required performance metrics. Performance metrics, i.e. throughput, processing latency and network latency, are generated by Esper engines and stored locally in a log ﬁle. The algorithm gathers them by remotely accessing the logs from each engine. Esper engines are started and stopped through standard calls to a management interface. I deployed this enhanced version of Esper on Amazon EC2. Based on my experience, this approach can be easily integrated with other cloud environments or DSPSs.

5.5.3 Experimental Evaluation

The goal of the evaluation is to illustrate the effectiveness of the adaptive provisioning algorithm for scaling the number of required VMs against variable input rates. Experimental set-up. I use the same experimental setup as in §5.3.5 with Esper and data streams obtained from its benchmark tool. I implement the Esper tuple submitter and vary the input tuple rate in a step-wise way as shown by the solid line in Fig. 5.15. Such variations in the input rate emulate demanding and sharp changes in the workload, similar to workloads adopted by others in dynamic resource provisioning [Padala 2009]. I use two submitter VMs to send data, which are deployed on extra-large Amazon EC2 instances. I perform two sets of experiments with the Esper system deployed on small and large VM instances. In all cases, the VMs are created in advance to isolate the algorithm response time from VM set-up times, which can take several minutes. The used query computes the maximum value of a stock with a given symbol per time window. To control the number of engines, I divide the query into two stages, as shown in Fig. 5.14. This allows us to use multiple engines to process the data in the first stage that takes the maximum value of each stock symbols per second. In the second stage, the first-stage results are collected and merged to obtain the final result. A key parameter of my algorithm is the time interval between successive invocations. A system with a short interval would react quickly to varying input rates. However, it might obtain incorrect throughput estimates caused by transient behaviour. A large interval would mean that the system 5.6. CONTRIBUTION 133 can only react slowly to changes in the input rate, staying in an over- or under-loaded condition. Based on our workloads, I determined empirically the time interval as follows. The Esper engine calculates the number of dropped tuples every second. Using Fig. 5.15a, which shows a large variation in the number of dropped tuples when the input rates vary and the system is overloaded, I determined that an invocation period of 30 seconds gives a good trade-off between these two extremes.

Results. As the input rate varies, Figs. 5.15a and 5.15b show the number of VMs allocated using small and large EC2 instances, respectively. The solid lines depict the input data rates and the dashed lines represent the number of VMs allocated by the adaptive algorithm. Dropped tuples due to overload are shown as stars. The processing latency maintained remains low (i.e. 7–28 µs) throughout the entire experiment because the Esper engine drops data tuples when overloaded. When using small VM instances, the system scales up and down the number of VMs as required by the input rate. During a rate increase, I observe that the rate of dropped tuples increases until the algorithm detects the change and allocates more VMs. In the case of large instances, the algorithm sustains processing with a single VM because it is enough to handle the rate changes, with few tuples dropped throughout. While our adaptive algorithm is able to scale the number of VMs against the input rate changes, there is room for improvement. There is a signiﬁcant reaction delay before VMs are scaled up and down. To reduce this delay, other performance parameters, such as the percentage of idle CPU time or the variance in dropped tuples, could also be considered. Another challenge is that, in practice, it may take several minutes to allocate extra VMs. A workaround may be to reduce this time by exploiting Amazon EC2’s facility for creating point-in-time snapshots of volumes using Elastic Block Storage. If used as a starting point for new VMs, it can reduce boot-up time.

5.6 Contribution

This chapter proposes new methodologies for testing Cloud Computing infrastructures in the context of videoconferencing services and offers an nlgorithm for scaling stream processing systems in Cloud Computing platforms. I have validated the beneﬁts of a known Cloud provider infrastructure when used as a core of a multimedia streaming service. An important conclusion is that the QoS of a streaming service can be efﬁciently improved by deploying part of the architecture inside Cloud networks. This 134 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES hybrid architecture is obtained placing strategically some distribution network nodes into the Cloud provider infrastructure, taking advantage of the reduced packet loss and low latency that exists among its datacentres. To answer the question of how to provision a DSPS in a public cloud given a workload, I propose an adaptive algorithm that scales a DSPS deployment in response to runtime variations of input stream rates. This algorithm periodically estimates the number of VMs required to support the input stream data rate such that none of the VMs is overloaded. I evaluate this algorithm experimentally by deploying it as part of the Esper stream processing system on the Amazon EC2 cloud.

5.7 Conclusions

As a result of this work our videoconferencing system have reduced the jitter in the end points, and it has improved the available bandwidth. I have also minimized the packet loss in each of the peers involved in the streaming scenarios.The differences that appear between Scenario 2 and 3 demonstrate that using connections between distant Cloud datacentres can help to improve the QoS response of streaming even in videoconferencing P2P systems. Therefore, using a Cloud network infrastructure to cross continents has improved the majority of the QoS problems. Regarding stream processing systems, based on the experimental evidence, public clouds are suitable deployment environments for stream processing. These results show that latency is the dominating factor governing the performance of a cloud-based DSPS. The results from the algorithm evaluation show that my approach can scale up and down the number of DSPS engines on VMs as input rates change and maintain low processing latency with low data loss. 5.7. CONCLUSIONS 135 Figure 5.13 : Packet losses in each scenario Figure 5.12 : Bytes received in each scenario Figure 5.11 : The 99.7th percentile of jitter in each scenario 0

0 5000 5 0

80 60 40 20

50000 45000 40000 35000 30000 25000 20000 15000 10000 30 25 20 15 10

packets of Number

120 100 seconds 400 every received MBytes Milliseconds 136 CHAPTER 5. METHODOLOGIES FOR TESTING CLOUD INFRASTRUCTURES

Figure 5.14 : Elastic DSPS with query partitioning across processing VMs

5 x 10

Input Rate Tuples dropped Number of nodes 1.5 4 1 3 2 Tuples/sec 0.5 1 Number of VMs 0 100 200 300 400 500 600 700 Time (sec)

(a) Small EC2 instances

5 x 10 2 2 Input Rate Tuples dropped Number of nodes

1 1 Tuples/sec Number of VMs 0 0 100 200 300 400 500 600 700 Time (sec)

(b) Large EC2 instances

Figure 5.15 : Dynamic adaptation of VM numbers based on changes in input rates Chapter 6

Cost-Effective Videoconferencing for Hybrid Clouds

Over time hybrid cloud has proven to be a valid solution for the business sector as many companies that were initially avoiding public cloud solutions, later showed higher confidence in the hybrid model as a feasible use case solution of the cloud computing model itself. Cloud users and the companies in particular, accepted leaving private IT assets inside and migrated less sensitive data and operations to the public cloud. Overcoming the heterogeneity of IaaS billing policies and working out the best combination of public-private and cross-cloud infrastructures is a tempting challenge. In this research, I started from here in order to give another reason to deploy services in a hybrid cloud: to efficiently enhance the use of resources. There are many systems that can benefit from deploying on hybrid clouds instead of only using a single cloud. I provide guidelines for developers to design their applications and services according to their requirements. I want to validate this concept by means of a system that offers videoconference to users on both private and public clouds. I have designed, developed and tested a new architecture for a session-based videoconferencing system where several users can join and control (schedule, delete and modify videoconference) sessions through a web application. The system focuses on optimal use of the available resources. To that extent, I studied the existing hybrid infrastructures that were used for purposes other than videoconference and I based my work on similar videoconferencing systems on various Cloud infrastructures. This chapter is organized as follows: section 6.1 describes the main objectives of this dissertation, in section 6.2 introduces the main motivation of this research, explaining how hybrid architectures can show better performance in some scenarios. Section 6.3 goes through the validation of a videoconferencing system in terms of cost and resource use. Section 6.3.3 presents a real case scenario as a practical validation of the hybrid system and cost formulae, numbering the projects and researches using the Conference Manager. Section 6.5 shows the main contribution in this chapter. Finally in 6.6, I conclude the validation by encouraging other researches to try my outcomes for further research. 138 CHAPTER 6. COST-EFFECTIVE VIDEOCONFERENCING FOR HYBRID CLOUDS

6.1 Objectives

This contribution provides a new methodology to implement applications on multiple Cloud providers to save cost.

• To provide cost-effective mechanisms for deploying videoconferencing systems in multiple Cloud providers. Here I provide a new methodology to reduce costs in scenarios with multiple Cloud providers. First I provide open challenges to implement applications in a single Cloud provider approach and, next, I give guidelines to change our system architectures to ﬁt into the new methodology.

This objective can be divided into several tasks:

1. Design of a general methodology for dividing our application into different type of resources: Here I will explain a new way to represent all our components depending of the nature of these components and the costs associated to them.

2. Theoretical evaluation of the methodology: We will provide a ﬁrst validation of the methodology given the prices of different Cloud providers.

3. Empirical evaluation of the methodology: We also want to apply this methodology in the architecture explained in chapter 4, validating it within different projects.

6.2 Motivation and Context

A videoconferencing system that allows a great number of users per conference, multiple simultaneous conferences, different client software (requiring transcoding of audio and video flows) and provides an automatic recording service, as the one I present in this work requires a lot of computing resources. Typical videoconferencing scenario (like the one explained in [Cerviño 2011b]) includes several videoconferencing clients. Some are connected through a Multipoint Control Unit (MCU) and others participate via Flash or SIP. In both cases transcoding the data flows is necessary. The scenario also includes a Real Time Messaging Protocol (RTMP) server for the flash clients and a SIP server for the SIP clients. In order to allow a cost-effective scaling of my videoconferencing system, the use of cloud computing resources appears as a natural approach, since they provide an illusion of infinite 6.2. MOTIVATION AND CONTEXT 139 computing resources available on demand and the ability to pay for use of computing resources on a short-term basis as needed [Armbrust 2009]. However the use of cloud computing resources from a single provider comes with several disadvantages as shown in [Armbrust 2009, Leavitt 2009]. Critical problems that can benefit from hybrid cloud architectures are listed below in no particular order.

• Geographical location and legal issues. It may be useful to start some services in a speciﬁc location for performance or legal reasons. The use of different providers will give us access to more locations or will allow us to start some services in our private cloud that may be more suitable for sensible data.

• Cost and lock-in. Different providers may offer different services at a different price. Furthermore this price may change over time. By using several providers we can use this to our advantage. In addition, the use of a single provider may result in a lock-in problem.

• Availability. Cloud computing serviced by a single company is a single point of failure. By using different providers we can achieve better availability.

• Wasting of existing resources. In some environments a lot of resources are already available to use. By moving all services to the cloud we are wasting these resources. The use of hybrid private/public clouds can avoid this problem.

• Security. This issue has appeared as initial motivation for companies and institutions to accept hybrid cloud by leaving private assets on-premise and deploying risk-free services over the public cloud.

In light of the problems listed above, the use of resources from different providers as well as private resources can help us to provide a service with better performance, lower cost and to avoid or at least mitigate most of the problems of cloud computing. This will applied to my videoconferencing service in section 6.3 of this chapter. To be able to effectively exploit the hybrid clouds two things are required. First I need to make use of a virtual infrastructure manager [Sotomayor 2009] to provide a uniform and homogeneous view of virtualized resources, regardless of the underlying virtualization platform. Second, I need to split the service into three parts: 140 CHAPTER 6. COST-EFFECTIVE VIDEOCONFERENCING FOR HYBRID CLOUDS

• CPU intensive modules. Parts of the application that consume most of the CPU cycles needed to provide a service. In this case I identiﬁed the transcoding and recording modules of my videoconferencing system as the CPU intensive modules.

• Bandwidth intensive modules. These are modules that consume most of the bandwidth. In my videoconferencing system, the MCUs and RTMP servers are bandwidth intensive components.

• Storage intensive modules. Disk servers and databases fall into this category. In this case the recorded conferences are stored in a NFS server.

This division gives us the opportunity to place the modules that need a speciﬁc kind of resource where it better serves our needs and objectives. This partition was named Cloud computing Resource Oriented Partition or CROP.

6.3 Validation of Hybrid Cloud for a Videoconferencing System

This section introduces a general methodology to calculate traditional Cloud-node costs, based on the principles explained in section 6.2. An example of a videoconferencing system (subsection 6.3.1) in order to put into practice the previous methodology (subsection 6.3.2) is presented afterwards.

6.3.1 General methodology

Figure 6.1 represents the typical costs of a node hosted in a particular Cloud infrastructure: computation time, trafﬁc data and storage cost. The next cost-calculating formulae are completely based on the way Amazon is charging its clients. Although almost all of its competitors (like RackSpace, GoGrid, Azureus, ...) offer their own payment methods, they basically follow Amazon’s model. Others for instance offer AWS- compatible cost calculators.

We will start explaining the cost formulae by denoting Xi as the representation of a Cloud provider. Let’s assume we want to contract the services of a provider, which is offering low-prices in the use of CPU (named Xcpu), other provider that offers better prices in bandwidth consumption

(named Xbw) and a third provider, which has special deals in storage services (named Xstor). 6.3. VALIDATION OF HYBRID CLOUD FOR A VIDEOCONFERENCING SYSTEM 141

Ctr-in(1,Xi) Ctr-out(2,Xi)

BWin(j,1) BWout(j,2)

Ccpu(j,Xi)

BWout(j,1) BWin(j,2)

BWst(j) Ctr-out(1,Xi) Ctr-in(2,Xi)

Cst(Xi)

Figure 6.1 : Typical Cloud Node Costs

Then, given the architecture explained before and basing on the Cloud Price Calculator I mentioned at the beginning of this section I can work out the cost of this architecture in a hybrid cloud environment.

Ctotal = ∑ Ccpu(Xi) +Cbw(Xi) +Cstor(Xi) (6.1) i∈{bw,cpu,stor}

This formula shows the sum of the three aforementioned services: Ccpu,Cbw and Cstor for each

Cloud provider (Xi). Each of these components is further detailed as follows:

Ccpu(Xi) = ∑Ccpu( j,Xi)t (6.2) j

This formula along with the following ones complies with ﬁgure 6.1, in which we can see all the components that are part of each node cost. Formula 6.2 gives us the total computation cost for each cloud. We have to sum up the computation costs of each j node that is running on this Xi provider and the computation capacity it uses. For example, in the case of a Web server we will need a medium level CPU while in the case of a video transcoder we will need more computation capacity. Given that there are some providers that charge on memory capacity for each virtual machine, the reader could include this cost as part of the Ccpu( j,Xi) value. Finally, t is the number 142 CHAPTER 6. COST-EFFECTIVE VIDEOCONFERENCING FOR HYBRID CLOUDS of hours that are going to be considered.

Cbw(Xi) = 3600t ∑∑Cint ( j,k,Xi) (6.3) j k

Formula 6.3 is the result of adding together all costs generated from different trafﬁc sources in each j node of Xi Cloud provider. In this case I assume the constant 3600 because trafﬁc is measured in bytes per second, and here the costs are per hour.

I have simplified the figure by representing only two network interfaces, one on the left-hand side (numbered 1) and other on the right-hand side (numbered 2). However the formula takes into account the total number of interfaces that are attached to the node, and each of them are denoted by k. The resulting traffic cost is the sum of all cost interfaces. I want to clarify that here I am referring to the node interfaces and not to the Cloud interfaces, so the reader could consider traffic that is going to be sent out of the Cloud datacentre, and traffic that is going to be sent to other machines in the same datacentre. Both communications could have different costs because the former is considered as external transfer of the Cloud network, and the latter is part of the internal network transfers.

Cint ( j,k,Xi) =Ctr−in(k,Xi) BWin( j,k)+

Ctr−out (k,Xi) BWout ( j,k) (6.4)

In formula 6.4 each interface has incoming traffic (BWin) and outgoing traffic (BWout ) with their corresponding cloud costs: Ctr−in for incoming traffic and Ctr−out for outgoing traffic. Both traffic components need to be measured in bytes per second. The sum is the cost of each interface.

Cstor(Xi) = ∑3600t Cst (Xi) BWst ( j) (6.5) j

Finally, formula 6.5 is related to the storage costs of each j node of Xi Cloud provider. Here I have deﬁned the storage as a constant data ﬂow saved on virtual disks. Next, I have introduced

BWst as the rate (per second) at which the data is stored in the disk. 6.3. VALIDATION OF HYBRID CLOUD FOR A VIDEOCONFERENCING SYSTEM 143

Xweb Xtr Xrec

a c e b Web Server d Transcoder Recorder (medium CPU) (high CPU) (medium CPU)

f a) BWweb-in c) BWweb-in e) BWweb-video b) BWweb-out d) BWweb-video f) BWweb-video

Figure 6.2 : Cloud Architecture

Simple videoconferencing system

In [Cerviño 2011b] I decided to compare two topologies: a system in which all resources were allocated in the same public cloud, and another system in which this allocation was made by using a public Cloud and our own datacentre. However this study does not exactly coincide with the current idea of cost calculation because this service is supposed to take advantage of using several public clouds where I have to pay for almost everything. For this reason in the current work the problem will be tackled through a different approach. In order to better validate this methodology I used the videoconferencing system focused on offering the service to multiple participants who want to join in a meeting session. This system is a simplified service of the one explained in [Cerviño 2011b]. From now onwards, we will consider the total storage cost is zero because we used the datacentre from the University to store the recorded videos. Here we have only taken into account three essential components that present features such as video and audio communication among users, real-time streaming and recording of the session. First component: the Web Flow Server, is responsible for forwarding all the traffic between the transcoder and each of the users. Second component: the Transcoder, composes a video of the entire session. This video usually consists of 1-5 videos (each of them from different users) and is coded in H.264 format. Note that the transcoder generates a video with a resolution of 1024x768 pixels. Regarding the audio streams, the transcoder is responsible for joining all streams into one to be used for recording by the recorder component. Last component: the Recorder, stores the video and audio streams. The configuration of this system stores video files in MP4 format, with 144 CHAPTER 6. COST-EFFECTIVE VIDEOCONFERENCING FOR HYBRID CLOUDS the video and audio generated in the transcoder. In figure 6.2 we can see the architecture with the three elements interconnected between themselves, sending session media streams.

BWweb−in = BWweb−user min{Nweb−users;Nmax} (6.6)

BWweb−out = BWweb−video Nweb−users (6.7)

Formula 6.6 calculates the total incoming bandwidth consumption in the external system interface by multiplying the video and audio stream bandwidth from the user (BWweb−user) by the number of users that appear in the generated video. This number is considered to have a limit of

Nmax users, so we have to take the minimum value between this limit and the number of connected web users (Nweb−users). Formula 6.7 refers to the outgoing bandwidth, that is the amount of bandwidth consumed by the video and audio streams generated in the transcoder.

These streams are sent to each web user (BWweb−video).

6.3.2 Cost analysis

In this research I decided to analyze four scenarios with real Cloud providers: Amazon AWS, CloudSigma and Rackspace. Given their published prices we can consider them as low-priced Cloud providers for CPU, bandwidth and storage, respectively. In the ﬁrst scenario (named hybrid scenario) the Web server is hosted in CloudSigma datacentres, while the Transcoder is instantiated in Amazon AWS Cloud and the Recorder is in Rackspace public Cloud. The different Clouds were connected through their public interfaces, using public IP address in all components. In the rest of the scenarios all the components are in only one of these Cloud providers. For the results I have taken into account that in single Cloud scenarios the trafﬁc must be considered internal, which in general presents lower prices.

For calculation we can replace the values of bandwidth streams (BWin, BWout , etc.), ﬁgure 6.1, with the corresponding ones in scenarios represented on ﬁgure 6.2. Figure 6.3 depicts the cost comparison for each scenario. I have considered the difference in cost between each scenario and the hybrid scenario when we increase the number of videoconferencing participants. Therefore, each curve above 0 means that the referenced 6.3. VALIDATION OF HYBRID CLOUD FOR A VIDEOCONFERENCING SYSTEM 145

Cost Differences with Hybrid Clouds 100 Hybrid Cloud CloudSigma 80 AmazonEC2 RackSpace 60

40 % 20

−20

−40 0 10 20 30 40 50 60 70 80 90 100 Number of users Figure 6.3 : Cost differences between Cloud architectures

scenario is more expensive than the hybrid one. In this example we can see that for more than 10 people we need to use this hybrid architecture in order to obtain a cost-effective service. On the other hand, for less people we can ﬁnd other traditional Cloud solutions. Another interesting situation occurs when the number of users connected to the videoconference increases to above 60 people. In this situation we can see that the cost of the CloudSigma scenario approaches the hybrid scenario. This happens because the bandwidth consumption turns into the most expensive factor in the formula, and in this case both the hybrid and the CloudSigma scenarios have the same bandwidth values.

6.3.3 Results Validation and Performance Evaluation

This subsection presents the test scenarios I used in order to validate the formulae established in the previous section and show the outcomes of the validation. Afterwards I number the projects 146 CHAPTER 6. COST-EFFECTIVE VIDEOCONFERENCING FOR HYBRID CLOUDS in which this system was used and ﬁnally I trace the way for future research directions that can be motivated from this work.

6.4 Test scenarios

I have established ﬁve test scenarios based on the architecture explained in [Cerviño 2011b], all of them including six participants in a videoconferencing sessions. This architecture is based on Isabel, a videoconferencing tool which supports sessions with multiple participants, and on Conference Manager, that schedules Isabel videoconferencing sessions and provides additional services, such as video recording. Five of these tests are connected through the Isabel application and one via web client portal. The scenarios are differentiated by the videoconferencing mode. The tests were set up to one hour in duration. We hosted a Transcoder and an Isabel Flow Server in two medium Amazon EC2 instances, while a Web Flow Server was hosted in our private datacentre.

In the ﬁrst scenario we set-up an Isabel chat mode, meaning various videos are displayed simultaneously on a single screen. In the second and third scenarios all the clients were set up in VNC mode for displaying a video and some slides, respectively, using the VNC technology. Scenarios 4 and 5 replaced the VNC mode with a VGA mode to show video and slide presentations similarly as the scenarios 2 and 3. In this mode there is a video display shared among all the users and they can view video, applications, etc.

The video displayed is obtained frame by frame from a screen, encoded and sent. The use of VGA video has significantly decreased the cost for the outgoing traffic as compared to VNC mode with video. The key is the fixed transmission rate of the VGA video that does not necessarily use the entire bandwidth for transmission.

The results from Figure 6.4 indicate an appealing cost-performance trade-off for the hybrid videoconferencing system. We can see that even the use of VNC in the conference session has not influenced much on increasing the total cost of the incoming and outgoing traffic, which remained within reasonable limits. This has confirmed previous expectations that a hybrid model could be a good solution for hosting videoconferencing systems that require an optimized cost policy and good quality of service. 6.4. TEST SCENARIOS 147

1,00 !

OUT 0,90 ! IN

0,80 ! CPU

0,70 !

0,60 !

0,50 !

0,40 !

0,30 !

0,20 !

0,10 !

- ! Multiple videos VNC with video VNC with slides VGA with video VGA with slides

Figure 6.4 : Cost of an Isabel Hybrid Session

6.4.1 Project resource usage

The Conference Manager has been successfully integrated into several projects allowing me to obtain further proof that the solution is valid. The most important of these projects are Global Project, in which it was used in meetings of TERENA, EGEE, W3C among others; GATE for the organization of classes (from ﬁve to ten two-hour classes are scheduled every week); and CyberAula 2.0 to record, store and stream courses from different Universities. At the time of writing this chapter, the system had been used to organize 592 sessions with 941 videos stored.

6.4.2 Research using Conference Manager

As I mentioned in section 6.2, using hybrid clouds can be useful because of the geographical diversity of the offer. In previous experiences, intercontinental videoconferencing has proven to be a challenge, especially when relying on TCP as the transport protocol as it is the case of traditional web clients. As seen in chapter 5, the network infrastructure used by typical commercial clouds 148 CHAPTER 6. COST-EFFECTIVE VIDEOCONFERENCING FOR HYBRID CLOUDS usually performs really well, even between different continents giving users a good service in terms of packet loss, delay and throughput among the nodes within the cloud. In a hybrid case as the one presented in this section, we can take into account the variety of locations provided by the different providers and the geographical location of the service’s users and choose the provider that suits us best.

6.5 Contribution

This chapter shows the implementation of a cost-effective mechanism for deploying videoconferencing systems in multiple Cloud providers. I have presented a cost-effective methodology for developing and deploying applications over multi-provider hybrid cloud. The core idea of this methodology is to divide the application into three parts: CPU, bandwidth and storage intensive modules. Whenever this is possible, this methodology aims to optimize costs by deploying each of these modules in the most suitable cloud provider. I have validated this methodology in the videoconferencing architecture explained in previous chapters. Firstly, I introduce guidelines to calculate traditional Cloud node costs and apply it to the videoconferencing scenario concluding that the proposed deployment strategy does reduce costs on chapter. To conﬁrm this theoretical validation, I have successfully tested the methodology in a real videoconferencing environment.

6.6 Conclusions

I have concluded that there are real cases in which many kinds of applications could beneﬁt from this resulting mainly in a cost optimization. So I would encourage those researchers who are testing both services or cloud middlewares to take this work into account. On the other hand, this research can be extended by analyzing the results of dynamically allocated resources on multiprovider hybrid clouds in order to increase the cost savings. Chapter 7

Validation And Results

The importance and criticality of evaluation of results is well recognized in the scientiﬁc community. This chapter will therefore provide some additional and complementing aspects to the validation of this work. This validation has been carried out within several national and European research projects. In section 7.1 the author shows several European projects where this architecture was used for different purposes: from e-learning services to business models. Section 7.2 shows different national projects that

7.1 Validation in European Projects

The work explained in this dissertation has been implemented as part of several national and European projects, which provided an opportunity to validate all these ideas and contributions within each project context. These projects where: ECOSPACE, C@R and Global.

7.1.1 ECOSPACE

ECOSPACE resulted in new working paradigms and metaphors for eProfessionals, a user-centric platform enabling the interoperability of innovative collaboration tools and services. It empowered users to easily build-up and deploy on-demand virtualised and knowledge rich collaborative environments. During this project the author transformed a traditional videoconferencing desktop application, called Marte 2.0, into the paradigm of web, including a new interface to handle ECOSPACE requests. This work gathered many beneﬁts, including ease of use, lower requirements and integration with other tools, while keeping the existing interfaces to comply with our reference architecture. The most imperative factor for this transformation was integration, at user interface level, with the rest of tools from the ECOSPACE portfolio: while most of them were web-based, and mash- ups are nearly trivial among applications of this kind, integrating a desktop application, which 150 CHAPTER 7. VALIDATION AND RESULTS

CreateConference InviteParticipant CreateConference

CreateConferenceWithPIDs DisconnectParticipant GetParticipantInfo

ChangeConferenceMode GetConferenceInfo GetMarteUsersPID

GetMarteUsersPIDAndStatus GetUserPresenceStatus EndConference

Figure 7.1 : ECOSPACE’s Primitives for Managing Nuve Functionalities

must be deployed in each machine and executed separately, was a big challenge against project philosophy. The solution came from the current web 2.0 paradigm: Marte was to be reengineered, to cope with all the mentioned problems, while taking advantage of the new possibilities brought by the web, and maintaining compatibility with all the ECOSPACE middleware developments. The role of Marte/Nuve in the project is providing the consortium with a tool that supports the Basic Collaborative Service of Multimedia Conferencing, offering a standardized interface to the necessary functions to control the application. As such, and following OSA/Parlay X recommendation for Multimedia conferences, a set of 9 primitives (Figure 7.1) was deﬁned by other authors to manage the functionalities of the server regarding presence, session conference control, and status of participants. This API made requests to Nuve API, which is also based on the same recommendation but implemented following REST principles. When a user starts using Marte/Nuve, he ﬁrst have two login options: using the typical user/password combination, or using OpenID (Figure 7.2). In both cases, the user must be previously registered in the application to access it; this is currently being solved inside ECOSPACE. The user needs only have the Flash plug-in installed in his browser (which is an usual thing nowadays), and the Java plug-in is also needed to support the shared desktop feature. There might appear some warning messages when the application starts, to ask for permission to use local desktop capture (VNC server applet) and the webcam, which are some of the already mentioned shortcomings of running inside a security sandbox. Finally, the user is presented with the Marte âAIJHallâ˘ A˘ I,˙ and he can start conferencing with anyone who is online at that moment (Figure 7.3). 7.1. VALIDATION IN EUROPEAN PROJECTS 151

Figure 7.2 : Videoconferencing Login Page in ECOSPACE

7.1.2 Collaboration At Rural

This European project aimed to enable people in remote and rural places to enjoy the knowledge society as citizens and as professionals.

During this project Nuve was developed in the context of Distributed Workspaces (DWS), which were identiﬁed as collaborative environments that offer facilities for distributed storage and transparent access to information and other resources over a common and standardized communication IP infrastructure. A real time collaboration application was designed within these workspaces as a tool that enables user to perform videoconferencing activities integrating document repository and presence in order to allow distributed working sessions. This task aimed to integrate Marte videoconferencing application combined with instant messaging and presence (IMP) services. To do that, the basic resources of Nuve interface were divided and adapted into the Collaborative environment that provide videoconferencing functionalities and enable the recovery of presence information from the operator or from other systems.

All this served Cudillero Living Lab users to start videoconferencing sessions with other users available in the project. Applications in this living lab were developed for the fishermen to enhance current business processes in order to make fishing production more profitable. 152 CHAPTER 7. VALIDATION AND RESULTS

Figure 7.3 : Example of Marte Room

7.1.3 GLOBAL

GLOBAL strived to enable researchers in Europe and around the globe to set up and expand their own virtual community for exchanging present project results, sharing documents and media files, or simply to socialise and connect with each other by means of virtual conferencing. The author implemented the Conference Manager, which was the core videoconferencing tool within the system developed in this project. The Virtual Conference Centre, also known as Global Plaza, used it to operate and to offer videoconferencing services to scientific researchers and academia for free. The Global Plaza site used the Conference Manager API explained in chapter 4. The overall architecture is detailed in figure 4.3. This architecture was hosted in a datacentre of the University along with several instances in Amazon EC2. Following that figure, the installation of Conference Manager system had the next installation requirements for GLOBAL: For dedicated infrastructure that does not depend on fluctuating demand the author used the next configuration: The Conference Manager Controller, which hosts the API server, logic and 7.1. VALIDATION IN EUROPEAN PROJECTS 153

Table 7.1 : Hosting Requirements for Conference Manager in GLOBAL project

Services CPU RAM Disk Software Installed

Dedicated Services

Conference Manager 1GHz 512MB 20GB Linux, Oracle Java, Samba

Red5 and SER 1GHz 512MB 2GB Linux, Oracle Java

Venus 2GHz 1GB 2GB a Linux, Oracle Java

On-Demand Services

Isabel Master Recording 1GHz 512MB 2GB Linux, Oracle Java, Xuggler

Isabel GW Web 1GHz 512MB 2GB Linux, Oracle Java, Xuggler

Isabel GW SIP 1GHz 512MB 2GB Linux, Oracle Java

VNC 1GHz 512MB 2GB Windows, Ofﬁce, Acrobat Reader

aMounts external disks to store all the data. Total: 1TB

monitoring manager needed 1GHz of CPU and 512MB of RAM because it only answers API requests from the Virtual Conference Centre, which does not mean a huge work load. It does require more available disk space because it will store logs of every request and task that is performed. Red5 and SER services where hosted in the same virtual machine. SER is a Proxy SIP server that only answers and handles SIP registrations from Isabel GW SIP machines, so it does not require a lot of work from the physical resources. On the other hand, Red5 forwards all the trafﬁc between Isabel GW Web and Web users, so it typically uses more RAM, so they only require 1GHz and 512MB of RAM. Regarding disk space they do not store any data in the disk so they do not have strong requirements. Venus is the recording service, that will store the video from all the GLOBAL events and it will also serve them. This is the reason why it needs more RAM and it needs to remotely mount external disks to store all the data from the sessions. 154 CHAPTER 7. VALIDATION AND RESULTS

Figure 7.4 : Screenshot of a recorded event in GlobalPlaza

On-demand services are those services that are only needed when there are events and sessions running. These are related to Isabel because it is the videoconferencing tool. There are three types of Isabel nodes, that were explained in chapter 4, section 4.4. There are also VNC machines that host Microsoft-based applications in order to show remote slides, documents, etc. In ﬁgure 7.4 we can see an example of an event that has been recorded using Global Plaza. The User Interface makes calls to the Conference Manager through Global Plaza in order to play recorded sessions. In ﬁgure 7.5 there is the form to create a new session in the Conference Manager. Figures 7.6 and 7.7 show the cumulative events and videos that were created in Global Plaza between January 2009 and November 2010 using the Conference Manager, according to GLOBAL project public statistics. At the moment of writing this dissertation, and according to Global Plaza home page i, there has been a total of 713 up to date, with 1088 videos stored, and 7549 visitors in Global Plaza vieweing videos and collaborating with other participants.

ihttp://globalplaza.org/ 7.2. VALIDATION IN NATIONAL PROJECTS 155

Figure 7.5 : Form to create an event in GlobalPlaza

7.2 Validation in National Projects

This section will explain how the different contributions in this dissertation were implemented and used by national projects in different contexts: e-learning and business models.

7.2.1 ITECBAN

The author could work in ITECBAN project, working together with other participants to implement a collaborative tool for synchronous and asynchronous services, in which the author implemented the API explained in chapter 3. ITECBAN aimed to create a methodological support infrastructure for a core banking. There the author took part of a group, called iTecSoft, addressed to implement a interoperable platform to provide collaborative technologies, such as videoconferencing, instant messaging, document sharing, forums, etc. In this project the author helped in the implementation of Marte and designed and developed the Nuve interface. The core collaborative service used it to provide this capability. This core was 156 CHAPTER 7. VALIDATION AND RESULTS

450

400 350 300 250 200 150 100 Cumulative Events Cumulative 50 0 100 80

Events 40 20

jul-09 jul-10

oct-09 dic-09 oct-10

feb-09 abr-09 feb-10 abr-10

jun-09 jun-10

sep-09 sep-10

ene-09 ene-10

ago-09 ago-10

nov-09 nov-10

mar-09 mar-10

may-09 may-10

Figure 7.6 : Global Plaza Events

entirely developed using Flash/Flex technologies and so, the service using Nuve was implemented using this platform. Figure 7.8 shows the architecture of iTecSoft, including the following components:

• Authentication Service: It provides SSO authentication among other components in the system. It internally looks up the user information in a LDAP directory. The technology here used is based on the Central Authentication Service (CAS) ii. The following components authenticate their users using this service.

• Synchronous Collaboration Manager: This component, developed with Ruby on Rails, is implemented on Apache server. This manager allows the users to participate on forums, create tasks in a schedule, and see information about other users within the same workspace. The utility of such spaces depends on the context in which we want to use the tool and the

iihttp://www.jasig.org/cas/ 7.2. VALIDATION IN NATIONAL PROJECTS 157

800

700

600 500 400 300

200 Cumulative Videos Cumulative 100 0 250

200

150

Videos 100

jul-09 jul-10

oct-09 dic-09 oct-10

feb-09 abr-09 feb-10 abr-10

jun-09 jun-10

sep-09 sep-10

ene-10 ene-09

ago-09 ago-10

nov-09 nov-10

mar-09 mar-10

may-09 may-10

Figure 7.7 : Global Plaza Videos

activity the group of people is assigned to. The interface between this component and the client is formatted using Atom Syndication Format [Nottingham 2005].

• Marte/Nuve Server: Synchronous collaborative component corresponds to Marte. This application uses the interface explained in chapter 3, and it allows every space to share video, audio and instant messaging by the users.

Figure 7.9 shows the login page used in iTecSoft. This login page made sends credentials to the Authentication Service and then, it uses an authentication token to authenticate on both services (collaboration and videoconference). Next, ﬁgure 7.10 shows a videoconferencing session between two participants who are logged in. The videoconference is established making requests to Nuve API from the Flex client. 158 CHAPTER 7. VALIDATION AND RESULTS

User Interface (Flex) C L I

Authentication Marte/Nuve Client Collaboration Handler E N

Module Module Module T S E R V E R

Authentication Server Marte/Nuve Server Collaboration Handler Server CAS

Figure 7.8 : iTecSoft Architecture

7.2.2 IBA and CyberAula 2.0

CyberAula 2.0 project presented a solution to stream and record courses at the University which need to be promoted or discontinued within the framework of the European converge process [Aguirre 2011].

Its main objective was to make courses accessible through Web browsers to live streaming during lessons and to recorded videos after the lessons. It was built upon the Conference Manager and Global Plaza system, using a Moodle instance installed in UPM according to ﬁgure 7.11. The lecturers used Global Plaza to schedule, perform, stream, record and publish videoconferences automatically.

The author participated in CyberAula from its early stages by implementing the Conference Manager, and the results of this validation provided valuable information to improve the videoconferencing architecture proposed in this dissertation. 7.3. DISSEMINATION OF RESULTS 159

Figure 7.9 : iTecSoft Login Page

7.3 Dissemination of Results

7.3.1 Publications

As a result of this dissertation a total of fourteen publications have been produced.

International Indexed Journals

• Javier Cerviño, Pedro Rodríguez, Irena Trajkovska, Fernando Escribano and Joaquín Salvachúa. A Cost-Effective Methodology Applied to Videoconference Services over Hybrid Clouds. Mobile Networks and Applications, pages 1–7, May 2012

International Conferences

• Irena Trajkovska, Pedro Rodríguez, Javier Cerviño and Joaquín Salvachúa. Opportunities and Challenges of Implementing P2P Streaming Applications in the Web. In 2012 IADIS Collaborative Technologies, Lisbon, Portugal, 2012. IADIS

• Pedro Rodríguez, Javier Cerviño, Irena Trajkovska and Joaquín Salvachúa. Advanced topics in videoconferencing based on WebRTC. In 2012 IADIS Collaborative 160 CHAPTER 7. VALIDATION AND RESULTS

Figure 7.10 : iTecSoft Videoconferencing Client

Technologies, Lisbon, Portugal, 2012. IADIS

• Javier Cervino, Evangelia Kalyvianaki, Joaquin Salvachua and Peter Pietzuch. Adaptive Provisioning of Stream Processing Systems in the Cloud. 7th International Workshop on Self Managing Database Systems (SMDB’12), april 2012

• Javier Cerviño, Fernando Escribano, Pedro Rodríguez, Irena Trajkovska and Joaquín Salvachúa. Videoconference Capacity Leasing on Hybrid Clouds. In Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing, CLOUD ’11, pages 340–347, Washington, DC, USA, 2011. IEEE Computer Society

• Javier Cerviño, Pedro Rodriguez, Irena Trajkovska, Alberto Mozo and Joaquín Salvachúa. Testing a Cloud Provider Network for Hybrid P2P and Cloud Streaming Architectures. In Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing, CLOUD ’11, pages 356–363, Washington, DC, USA, 2011. IEEE Computer Society

• Pedro Rodríguez, Daniel Gallego, Javier Cerviño, Fernando Escribano, Juan Quemada and Joaquín Salvachúa. VaaS: Videoconference as a service. In CollaborateCom, pages 1–11, 2009 7.3. DISSEMINATION OF RESULTS 161

Faculties at UPM

ETS ETS Agronomics ETS Civil Telecommunications Engineering Engineering Engineering

UPM

Global Plaza Hardware Kit

Conference Manager

Isabel

Figure 7.11 : CyberAula Architecture

• Javier Cerviño, Pedro Rodríguez, Fernando Escribano and Joaquín Salvachúa. Arquitectura Distribuida Para Una Aplicación de Videoconferencia Web. In CITA 2009: V Congreso Iberoamericano de Telemática, Libro de Ponencias, pages 173–176, Gijón, Asturias, Spain, May 2009

National Conferences

• Fernando Escribano, Javier Cerviño, Pedro Rodríguez and Joaquín Salvachúa. Videoconferencia con Isabel en la Web 2.0. In Actas de las IX Jornadas de Ingeniería Telemática, JITEL 2010, Valladolid, España, 2010. Universidad de Valladolid

• Javier Cerviño, Joaquín Salvachúa, Pedro Rodríguez, Gabriel Huecas and Juan Quemada. Demostrador de una arquitectura de videoconferencia en la Web 2.0. In XVIII Jornadas Telecom I+D, Bilbao, País Vasco, EspaÃsa,´ October 2008 162 CHAPTER 7. VALIDATION AND RESULTS

• Javier Cerviño, Pedro Rodríguez, Joaquín Salvachúa, Gabriel Huecas and Fernando Escribano. Marte 3.0: Una videoconferencia 2.0. In Libro de Ponencias de la VII Jornadas de Ingeniería Telemática, pages 209– 216, 2008

• Antonio Tapiador, Antonio Fumero, Joaquín Salvachúa and Javier Cerviño. Identidad Extendida en Redes Sociales. In Libro de Ponencias de la VII Jornadas de Ingeniería Telemática, pages 293– 296, Alcalá de Henares, España, 2008. Universidad de Alcalá de Henares

• Joaquín Salvachúa, Juan Quemada, Sandra Aguirre, Alberto Mozo, Antonio Tapiador, Antonio Fumero, Isidro Padilla, Juan Carlos, Fernando, Javier Cervi no and Diego Moreno. La plataforma iTecSoft: Un caso de colaboración inter-organizativa 2.0. In Libro de Actas de las XVIII Jornadas Telecom I+D, pages 1– 4, 2008

Book Chapters

• Javier Cerviño, Fernando Escribano, Pedro Rodriguez, Irena Trajkovska and Joaquín Salvachúa. Leasing Videoconference Resources on Hybrid Clouds. In Lizhe Wang, Ranjan Rajiv , Jinjun Chen and Boualem Benatallah, editeurs, Cloud Computing: Methodology, Systems, and Applications, pages 291–296. CRC Press, October 2011

7.3.2 Research Visit

The author visited the Imperial College London, as part of this dissertation, where he worked in a research of real-time stream processing systems and their application to Cloud Computing platforms. The work started with the study of state-of-art and analysis of related work that had been done in the Department of Computer Science. With this study the author concluded that previous validation divided into processing capacity analysis and network infrastructure analysis was needed. This analysis was performed over the Amazon EC2 infrastructure. With the results of this analysis, the author designed a distributed processing system that allows the use of Cloud resources as system’s processing nodes. He also designed a decision algorithm to choose whether it is necessary to use more Cloud resources or not. 7.3. DISSEMINATION OF RESULTS 163

The last step of this work was the implementation of some experiments and measurements of such system by means of a prototype based on that design. Some intensive measurements were taken to test its performance and the author compares the performance of the this system using a cluster installed at the Imperial College to the performance of the system using a hybrid system consisting in a set of nodes running in the Cloud and a set of nodes running in the cluster. This research concluded that the total latency signiﬁcantly increases when nodes are hosted in Cloud datacentres, mainly caused by the network delay between nodes that are geographically dispersed. So in those scenarios in which the maximum allowed latency is about some milliseconds or less we need to use only those Cloud nodes that are closed to the streaming sources. In other cases where we do not have strong latency requirements we can use the Cloud independently of the location of its nodes. And in these situations we will be able to save more money because of the use of Cloud.

7.3.3 Teaching and Seminars

• IMS Training. 2012. IP Multimedia Subsystem. Telefónica. Escuela de Excelencia Técnica.

• Introduction to Cloud Computing. 2010-2012. Part of "Master en Sistemas de ComunicaciÃ¸sne InformaciÃ¸snpara la seguridad y la defensa".

• New Standards for the Creation of Graphical Interfaces - Rich Internet Applications. 2011. Telefónica. Escuela de Excelencia Técnica.

• Innovative trends. 2011. Cloud Computing, Green Computing and Rich Internet Applications. Orange. Programa Superior de Sistemas.

• Communications Software. 2009. Adobe Flex and Rich Internet Applications. 164 CHAPTER 7. VALIDATION AND RESULTS Chapter 8

Conclusions

Implementation of real-time multimedia systems, and speciﬁcally videoconferencing applications, in Cloud Computing systems provides a new and unique way of taking advantage of media engine scalability and geographical distribution, cost savings for on-demand services and long-life and low maintenance infrastructure. This dissertation provides a complete environment for studying these entire assets prior to deploying any type of service in the Cloud. Here the author has tried to address technical issues related to Cloud hosting, proposing new interfaces and architectures for traditional videoconferencing solutions that ﬁt better in Cloud models, contributing with results of experiments and measurements of these systems being used in Cloud, proposing new methodologies to scale multimedia systems in Cloud platforms and novel methodologies and algorithms to save costs using advanced Cloud architectures. Furthermore the are many differences between videoconferencing applications that support communication only between two participants and videoconferencing applications that involve conference rooms with multiple participants. Many of these differences are related to the contexts in which these communications take place. For example, traditional communications between two participants are conversations, meetings, calls, etc. while multiple participants usually collaborate in classrooms, conferences, meetings, talks, etc. The former involves the interaction between both participants usually for almost all the conversation, while the latter is more structured and the participants usually change their participation roles and times. In this dissertation we have assumed a structured conversation between multiple participants, in order to focus on technical details: observing bandwidth, latency and processing during the communication, tools for managing conferences, scalability to adapt to variable user demands, etc. In summary, this dissertation addresses the following open questions and challenges in videoconferencing applications in the cloud:

1. What kind of interfaces are suitable for providing videoconferencing services in Cloud 166 CHAPTER 8. CONCLUSIONS

Computing platforms?

At the beginning of this dissertation we discussed and identiﬁed components and operations related to multimedia conferences and we have transformed traditional communication interfaces to our needs.

2. What factors need to be considered in the implementation of real-time multimedia systems in the Cloud?

We carried out in-depth research into available infrastructures, including network parameters such as bandwidth, latency, jitter, packet losses, in addition to processing and memory consumption in every virtual resource.

3. How can we adapt videoconferencing systems to advanced Cloud Computing platforms with multiple providers and heterogeneous infrastructures?

One of the main objectives of this work was to design a methodology that takes advantage of Hybrid Cloud scenarios by distributing components throughout different Clouds. In this study we implement the distribution according to the different pricing mechanisms and purchasing options of each provider.

In this chapter we will recap the main conclusions of this dissertation following the same structure we have previously used. Section 8.1 sets out the conclusions of designing interfaces for videoconferencing systems in the context of Cloud Computing. On the other hand section 8.2 which discusses the ﬁndings taken from the experiments carried out using the Amazon EC2 infrastructure and the new ideas that arose with the methodology implemented for hybrid-cloud- based architectures are presented in section 8.3. Section 8.4 summarizes the main contributions proposed in this dissertation. And ﬁnally 8.5 gives new ideas and on-going work that will continue from the results of this research.

8.1 What kinds of interfaces are suitable for providing videoconferencing services in Cloud Computing platforms?

We have analysed the available standard interfaces for videoconferencing, studying their suitability for Cloud-oriented architectures. We have discussed how REST interfaces fit well into these 8.1. VIDEOCONFERENCES INTERFACES IN CLOUD? 167 scenarios because of their orientation to resources. Cloud Computing is often related to resource scalability so they are usually offered as Resource Oriented Architectures. During this analysis we identified a set of resources that are often needed in these services. I decided to implement these resources by following a REST methodology in the architecture proposed in chapter 3 and then, I improved the same interface to a more advanced case in chapter 4. Thus, the proposed REST interface for videoconferencing is composed of rooms, users, and services. The additional capabilities proposed focus on the possibility of scheduling, recording and streaming videoconferencing sessions, so in this case I introduced the concept of sessions and events instead of rooms in order to make a more comprehensive system. A critical part of this work focuses on developing a security mechanism that integrates the service into third-party applications and mash-ups. During these tasks I studied different available alternatives, and I implemented a new one based on OAuth to ensure authenticity and trust between the system and other services. This authentication mechanism addresses the legacy of user authentication, and it relies on the external services to authenticate its own users. As I mentioned before, in chapter 4 I designed an advanced videoconferencing solution that could be partially implemented in the Cloud. This videoconferencing solution was supposed to schedule sessions at future dates. Almost all available studies into cloud scheduling only deal with hosting resources at the moment. Only a few of them schedule those resources in the future. Here we have divided the resources in order to instantiate resources in the cloud on-demand, based on the dates the users want to use these resources. As we have seen, this scheduling is based on the best-effort methodology. But this resource partition has allowed us to improve the performance and reduce costs as detailed in chapter 6. During this implementation we decided to separate the scheduler from the rest of the components and we were able to introduce some abstraction. Furthermore, other systems could benefit from this idea by using a virtual infrastructure manager and a scheduler that starts the resources required for a service in the most appropriate Cloud provider based on its location, price and resource type. In spite of this, the architecture could be further developed in order to make it as general as possible and abstract details of the system being managed by the scheduler and the executor. At the moment of writing this chapter we have used this architecture in several real case scenarios, such as videoconferencing events with users from different countries participating. 168 CHAPTER 8. CONCLUSIONS

There were two main types of participation: the ﬁrst one was joining the session to talk and make presentations; the second one was just watching the conference through web video streaming.

8.2 What factors need to be considered in the implementation of real-time multimedia systems in the Cloud?

To answer this question I carried out experiments to measure the infrastructure of Amazon EC2 as an example of a complete Cloud Computing platform. I also validated its beneﬁts when used as a core of a multimedia streaming service.

The ﬁrst conclusion of this work was that the QoS of a streaming service can be efﬁciently improved by deploying part of the architecture within Cloud networks. This hybrid architecture is obtained by strategically placing some distribution network nodes into the Cloud provider infrastructure, taking advantage of the reduced packet loss and low latency that exists between its datacentres.

As a result, the system has reduced the jitter at the endpoints, and it has improved the available bandwidth. I have also minimized the packet loss for each of the peers involved in the streaming scenarios. Therefore, using a Cloud network infrastructure to cross-continents has improved the majority of the QoS problems.

During my research visit in London I extended this work to stream processing systems. In this part of the study I concluded that public clouds are suitable deployment environments for stream processing. These results show that latency is the dominating factor governing the performance of a cloud-based DSPS. But on the other hand there is a need to make custom-adaptive algorithms to scale current DSPS deployments in response to runtime variations in the input stream rates.

For the last conclusion I designed an algorithm that periodically estimates the number of VMs required to support the input stream data rate so that none of the VMs is overloaded. I evaluated this algorithm experimentally by deploying it as part of the Esper stream processing system on the Amazon EC2 cloud. Results show that my approach can scale up and down the number of DSPS engines on VMs as input rates change as well as maintaining low processing latency with low data loss. 8.3. HOW TO ADAPT VIDEOCONFERENCING TO HYBRID CLOUDS? 169

8.3 How can we adapt videoconferencing systems to advanced Cloud Computing platforms?

The use of cloud computing resources from a single provider comes with several disadvantages that can beneﬁt from hybrid cloud architectures. These are: Geographical location and legal issues, cost and lock-in, service availability, waste of existing resources in private clouds, and security. In light of these problems, the use of resources from different providers as well as private resources can help us to provide a service with better performance, lower cost and avoiding or at least mitigating most of the problems of cloud computing. In this dissertation I also proposed a cost-effective methodology for developing and deploying applications on top of a multi-provider hybrid cloud. The core idea of this methodology is to divide the application into three parts:

• Bandwidth intensive modules. These are modules that consume most of the bandwidth. In my videoconferencing system, the MCUs and RTMP servers are bandwidth intensive components.

• Storage intensive modules. Disk servers and databases fall into this category. In this case the recorded conferences are stored in an NFS server.

This methodology can optimize costs by deploying each of these modules in the most suitable cloud provider. I provide guidelines to calculate traditional Cloud node costs, which can also be used in architectures other than videoconference. This methodology has been validated through theoretical and empirical tests, using models and real architectures, such as the one explain in chapter 4. The conclusion is that the proposed deployment strategy does reduce costs.

8.4 Contributions

In this section we will review the list of objectives that were set for this dissertation. The main contribution is the design, development and distribution of a complete room-based 170 CHAPTER 8. CONCLUSIONS videoconferencing architecture, which provides video, audio, and other capabilities to multiple participants in each room, and its implementation in advanced Cloud platforms to adapt to ﬂuctuating user demands, improve performance in terms of network latency, bandwidth and jitter, and reduce costs. We will comment on each of the individual contributions made in this dissertation below:

• Resource Oriented Interface for videoconferencing architectures in Cloud Computing platforms

I have shown the main features of the videoconferencing interface in the context of other Cloud Computing systems. I have detailed the resource-oriented interface (called Nuve). I also detailed a prototype of a Nuve system, and I validated and showed performance measurements, showing that this architecture could be easily implemented in a cost-effective way. And as an extension of this implementation, scaling the Cloud Computing service could offer tons of virtual rooms to users. It could be straightforward by allocating virtual rooms among the Cloud of virtual room servers.

Several projects reused the same core system. As part of these projects I have successfully installed the core in Linux, Windows, Mac OS X and Solaris. That is, I only have to support one group of physical CPUs that, in turn, have virtual machines running on top of them. Different services represent different projects and they can all share the same, unmodiﬁed, core. As a showcase I integrated Nuve into iGoogle, NetVibes and Google Waves.

Finally, even though the tests focused on measuring the limits of the system and do not represent a real scenario where one user usually sends more information than the others, they serve to estimate the largest video and audio bandwidth consumption by a normal user in this ﬁrst implementation. As regards server CPU use, the results show that I have to design a low-level architecture that can scale through several server machines without overloading any of them. In order to meet this need and guarantee some QoS, I will need to instantiate virtual machines and turn them on and off. This motivates me to follow the Cloud Computing principles.

• Implementation of a videoconferencing system architecture

I have explained the different parts of an advanced videoconferencing system and how I divided it into several resources. This system is based on the Isabel application and I 8.4. CONTRIBUTIONS 171

implemented a scheduler to set up future or on-going Isabel sessions. The system also provides a novel interface that is a extension of Nuve, with additional features to schedule conference sessions. This system is called Conference Manager.

It is part of a service, which offers the users the possibility of scheduling videoconferencing sessions through a web portal used within a European project. The users are able to attend to each of these sessions through the web and even take part of the meetings that would be created with this application. With this tool several users could get access to a single videoconferencing session and control it. This control is based on the interaction modes that are setup at different moments (presentations, conferences, questions, etc.). The system presented takes into account the different resources needed to set up a videoconferencing and reacts accordingly. In this project I developed a new service that offers videoconference, which could be accessed through different technologies. These technologies could be summarized as SIP, web browser and Isabel application access, the latest being an application developed in our research group.

We have already used this architecture in different contexts, such as videoconferencing events with users participating from different countries and many sessions have been recorded in different European and national projects.

• New methodologies for testing Cloud Computing infrastructures in the context of videoconferencing services

I have validated the beneﬁts of a known Cloud provider infrastructure when used as a core of a multimedia streaming service.

First of all, I measured the generic network QoS parameters, and I checked whether and up to which level it is reasonable to use a Cloud provider network for forwarding live streaming data. I found a research gap in the measurements in multimedia for QoS such as latency, bandwidth, packet loss and jitter in real scenarios by combining clients and provider inside and out of the cloud. A signiﬁcant conclusion is that the QoS of a real-time multimedia service can be efﬁciently improved by deploying part of the architecture inside Cloud networks.

I also designed four different multimedia scenarios that comprise most of the service real- use cases. These scenarios represent a streaming distribution network, where the network 172 CHAPTER 8. CONCLUSIONS

nodes could be located in the Internet or inside the cloud infrastructure. The main goal of this study was to qualify the hybrid network’s ability to transmit multimedia streams as well as analysing the trade off between nodes placed in the cloud and peers placed within a commercial network.

• Algorithm for scaling stream processing systems in Cloud Computing platforms

Stream processing systems are becoming very important as the number of data-intensive applications increase. Cloud-based DSPSs offer unique opportunities for scalable data processing against time changing stream rates.

Here I proposed an approach for on-demand provisioning of Data Stream Processing engines in a public cloud scenario. During my research visit at Imperial College London I designed an adaptive algorithm that scales a DSPS deployment in response to runtime variations of input stream rates. This algorithm periodically estimates the number of VMs required to support the input stream data rate so that none of the VMs is overloaded. I evaluated this algorithm experimentally by deploying it as part of the Esper stream processing system on the Amazon EC2 cloud.

Based on my experimental evidence, public clouds are suitable deployment environments for stream processing. My results show that latency is the dominating factor governing the performance of a cloud-based DSPS.

• Implementation of a cost-effective mechanism for deploying videoconferencing systems in multiple Cloud providers

Overcoming the heterogeneity of IaaS billing policies and working out the best combination of public-private and cross-cloud infrastructures is a tempting challenge.

In this contribution, I started from this point in order to give another reason to deploy services in a hybrid cloud: to enhance the use of resources efﬁciently. There are many systems that can beneﬁt from deployment in hybrid clouds instead of only using a single 8.5. FUTURE RESEARCH 173

cloud. I provide guidelines for developers to design their applications and services according to their requirements.

Here I presented a cost-effective methodology for developing and deploying applications on top of multi-provider hybrid cloud, that is based on the idea of dividing the application into three parts: CPU, bandwidth and storage intensive modules. Whenever this is possible, this methodology aims to optimize costs by deploying each of these modules in the most suitable cloud provider. I have validated this methodology in the videoconferencing architecture explained in previous chapters. I also introduce guidelines to calculate traditional Cloud node costs and apply them to the videoconferencing scenario.

I would encourage those researchers who are testing both services or cloud middleware to take this work into account, because I have concluded that there are real cases in which many kinds of application could beneﬁt from this, resulting mainly in a cost optimization. An extension of this research could be the analysis of dynamically allocated resources in multi-provider hybrid clouds in order to increase the cost savings.

8.5 Future Research

How advanced videoconferencing architectures can take advantage of complex Cloud Computing platforms is a complex question that needs to be overcome in the near future. Deployments of these systems in the cloud promise to exploit its inherent elasticity in scenarios with multiple participants and the real-time nature of these systems poses unique challenges due to the strict performance requirements: latency, bandwidth consumption, jitter, packet losses, video quality, etc. The work started in this dissertation will be continued with more research in our group, extending this work in different contexts. Here I show the more interesting topics:

• New multimedia technologies and protocols

An open topic is the use of new Web technologies, used around HTML5 set of standards. As regards real-time multimedia systems, and more speciﬁcally videoconferencing applications, W3C and IETF are currently working on the speciﬁcation of WebRTC. It is a set of protocols and JavaScript APIs that provides multimedia capabilities to web users. For example, at the time of writing this dissertation they have proposed the use of 174 CHAPTER 8. CONCLUSIONS

RTP/UDP to transport video, audio and data packets, a group of protocols to negotiate connection parameters (ICE, STUN and TURN) and SDP as a media negotiation protocol. In our group we are starting to work with this standard to implement it in the Cloud using a media mixer (or MCU) and provide the same videoconferencing systems as I have set out in this work.

• Novel scalability algorithms for videoconferencing systems

Another open challenge is the speciﬁcation of new scalability algorithms to create and destroy videoconferencing resources in the Cloud as user demand varies. As I have already explained, in this work I took the best effort approaches for the implementations, but it could be improved by the design of advanced mechanisms based on statistics, time-of-day variations in traditional videoconferencing workloads, etc. We are currently considering the implementation of new approaches based on the mechanisms I learned during my research visit at the Imperial College London.

• Improve current P2P streaming systems with the support of Cloud based architectures

P2P networking has favourable characteristics, such as high scalability, self-conﬁguration and organization. Many people consider them as suitable infrastructures for supporting real time streaming. However, P2P networks present dynamic characteristics that can drastically decrease the performance of these real-time applications. Among these characteristics, it is worth taking into consideration the ability of peers to enter and leave the system without any prior notiﬁcation. This can however cause service interruptions if the adaptive mechanism does not correctly manage such changes. There also exist problems of making the right decision in routing schemes and bandwidth utilization, or dealing with the heterogeneity of terminals, such as TV, Laptops, mobile phones or tablets, that also goes hand in hand with the variety of network connections including ADSL, Cable Modem, UMTS, WiFi, etc.

In our group we are working in a hybrid and distributed architecture for multimedia streaming combining P2P and cloud computing, focusing on the QoS requirements to make the architecture commercially usable, and offering some QoS APIs for the cloud. For this purpose we extended our Cloud evaluation in chapter 5 to compare different P2P scenarios including Cloud networks. 8.5. FUTURE RESEARCH 175

We are working on the idea that using a Cloud network infrastructure to cross continents could resolve the majority of the QoS problems. And we prepare an extension of the experiments with complex P2P topologies based on this work.

• Novel mechanisms to improve QoS in video and audio streams

Finally, there is also room for improvement in the QoS management of video and audio streams within videoconferencing systems. In the University we are working on novel video composition formats for decreasing bandwidth consumption in heterogeneous scenarios with multiple kinds of devices: desktops, mobile devices, TVs, etc.

The composition of videos and the return of the resulted video stream to all clients is a complex task due to the processes that are carried out on the server side, but it can drastically reduce the bandwidth and save CPU cycles in the devices. 176 CHAPTER 8. CONCLUSIONS Bibliography

[Abadi 2005] D. J. Abadi, Y. Ahmad, M. Balazinska, U. Çetintemel et al. The Design of the Borealis Stream Processing Engine. In CIDR, 2005.

[Abramson 2002] David Abramson, Rajkumar Buyya and Jonathan Giddy. A Computational Economy for Grid Computing and its Implementation in the Nimrod-G Resource Broker. In Future Generation Computer Systems (FGCS) Journal, Volume 18, Issue 8, Pages: 1061-1074, Elsevier Science, The, pages 1061–1074, 2002.

[Aguirre 2011] Sandra Aguirre, Juan Quemada, Jose Ygnacio Pastor, Estibaliz Martinez, María Ángeles Mendiola, Victoria Machuca and Raquel Portaencasa. CyberAula 2.0: Integration of Moodle with videoconferencing and lecture recording services. In Theo Bastiaens and Martin Ebner, editeurs, Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2011, pages 291–296, Lisbon, Portugal, June 2011. AACE.

[Ahmed 2003] Tanvir Ahmed and Anand R. Tripathi. Static Veriﬁcation of Security Requirements in Role Based CSCW Systems. In Symposium on Access Control Models and Technologies, pages 196–203, 2003.

[Al-Fares 2008] Mohammad Al-Fares, Alexander Loukissas and Amin Vahdat. A scalable, commodity data center network architecture. In Proceedings of the ACM SIGCOMM 2008 conference on Data communication, SIGCOMM ’08, pages 63–74, New York, NY, USA, 2008. ACM.

[Andrzejak 2010] A. Andrzejak, D. Kondo and Sangho Yi. Decision Model for Cloud Computing under SLA Constraints. In Modeling, Analysis Simulation of Computer and Telecommunication Systems (MASCOTS), 2010 IEEE International Symposium on, pages 257 –266, aug. 2010. 178 BIBLIOGRAPHY

[Araujo 2011] Jean Araujo, Rubens Matos, Paulo Maciel, Rivalino Matias and Ibrahim Beicker. Experimental evaluation of software aging effects on the eucalyptus cloud computing infrastructure. In Proceedings of the Middleware 2011 Industry Track Workshop, Middleware ’11, pages 4:1–4:7, New York, NY, USA, 2011. ACM.

[Armbrust 2009] Michael Armbrust, Armando Fox, Rean Grifﬁth, Anthony D. Joseph, Randy H. Katz, Andrew Konwinski, Gunho Lee, David A. Patterson, Ariel Rabkin, Ion Stoica and Matei Zaharia. Above the Clouds: A Berkeley View of Cloud Computing. Rapport technique UCB/EECS-2009-28, EECS Department, University of California, Berkeley, Feb 2009.

[Balazinska 2011] Magdalena Balazinska, Bill Howe and Dan Suciu. Data Markets in the Cloud: An Opportunity for the Database Community. PVLDB, vol. 4, no. 12, pages 1482–1485, 2011.

[Barra 2011] E Barra, A Mendo, A Tapiador et al. Integral solution for web conferencing event management. In IADIS Int. Conf. e-Society, 2011.

[Bell 1891] Alexander Graham Bell. On the Possibility of Seeing by Electricity. Library of Congress, United States of America, April 1891.

[Breitgand 2011] D. Breitgand, A. Maraschini and Johan Tordsson. Policy-Driven Service Placement Optimization in Federated Clouds. Rapport technique H-0299, Umea University, Department of Computing Science, 2011.

[Camargo 2011] Thiago Camargo. Jingle Relay Nodes. XEP-0278 (Experimental Standard), June 2011.

[Casalicchio 2011] E. Casalicchio and L. Silvestri. Architectures for autonomic service management in cloud-based systems. In Computers and Communications (ISCC), 2011 IEEE Symposium on, pages 161 –166, 28 2011-july 1 2011.

[Casner 1983] S.L. Casner, D. Cohen, E.R. Cole and UNIVERSITY OF SOUTHERN CALIFORNIA MARINA DEL REY INFORMATION SCIENCES INST. Issues in satellite packet video communication. Defense Technical Information Center, 1983. BIBLIOGRAPHY 179

[Cavaness 2006] Chuck Cavaness. Quartz job scheduling framework: Building open source enterprise applications. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2006.

[CCITT 1993] CCITT. H.261 : Video codec for audiovisual services at p x 64 kbit/s. Rapport technique, CCITT, 1993.

[Cerviño 2008a] Javier Cerviño, Pedro Rodríguez, Joaquín Salvachúa, Gabriel Huecas and Fernando Escribano. Marte 3.0: Una videoconferencia 2.0. In Libro de Ponencias de la VII Jornadas de Ingeniería Telemática, pages 209– 216, 2008.

[Cerviño 2008b] Javier Cerviño, Joaquín Salvachúa, Pedro Rodríguez, Gabriel Huecas and Juan Quemada. Demostrador de una arquitectura de videoconferencia en la Web 2.0. In XVIII Jornadas Telecom I+D, Bilbao, País Vasco, EspaÃsa,´ October 2008.

[Cerviño 2009] Javier Cerviño, Pedro Rodríguez, Fernando Escribano and Joaquín Salvachúa. Arquitectura Distribuida Para Una Aplicación de Videoconferencia Web. In CITA 2009: V Congreso Iberoamericano de Telemática, Libro de Ponencias, pages 173–176, Gijón, Asturias, Spain, May 2009.

[Cerviño 2011a] Javier Cerviño, Fernando Escribano, Pedro Rodriguez, Irena Trajkovska and Joaquín Salvachúa. Leasing Videoconference Resources on Hybrid Clouds. In Lizhe Wang, Ranjan Rajiv , Jinjun Chen and Boualem Benatallah, editeurs, Cloud Computing: Methodology, Systems, and Applications, pages 291–296. CRC Press, October 2011.

[Cerviño 2011b] Javier Cerviño, Fernando Escribano, Pedro Rodríguez, Irena Trajkovska and Joaquín Salvachúa. Videoconference Capacity Leasing on Hybrid Clouds. In Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing, CLOUD ’11, pages 340–347, Washington, DC, USA, 2011. IEEE Computer Society.

[Cerviño 2011c] Javier Cerviño, Pedro Rodriguez, Irena Trajkovska, Alberto Mozo and Joaquín Salvachúa. Testing a Cloud Provider Network for Hybrid P2P and Cloud Streaming Architectures. In Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing, CLOUD ’11, pages 356–363, Washington, DC, USA, 2011. IEEE Computer Society. 180 BIBLIOGRAPHY

[Cerviño 2012] Javier Cerviño, Pedro Rodríguez, Irena Trajkovska, Fernando Escribano and Joaquín Salvachúa. A Cost-Effective Methodology Applied to Videoconference Services over Hybrid Clouds. Mobile Networks and Applications, pages 1–7, May 2012.

[Cervino 2012] Javier Cervino, Evangelia Kalyvianaki, Joaquin Salvachua and Peter Pietzuch. Adaptive Provisioning of Stream Processing Systems in the Cloud. 7th International Workshop on Self Managing Database Systems (SMDB’12), april 2012.

[Chaisiri 2009] S. Chaisiri, Bu-Sung Lee and D. Niyato. Optimal virtual machine placement across multiple cloud providers. In Services Computing Conference, 2009. APSCC 2009. IEEE Asia-Paciﬁc, pages 103 –110, dec. 2009.

[Chan 2009] W.K. Chan, Lijun Mei and Zhenyu Zhang. Modeling and testing of cloud applications. In Services Computing Conference, 2009. APSCC 2009. IEEE Asia-Paciﬁc, pages 111 –118, dec. 2009.

[Chun 2003] Brent Chun, David Culler, Timothy Roscoe, Andy Bavier, Larry Peterson, Mike Wawrzoniak and Mic Bowman. PlanetLab: An Overlay Testbed for Broad-Coverage Services. ACM SIGCOMM Computer Communication Review, vol. 33, no. 3, pages 00– 00, July 2003.

[Clark 2010] R. Clark. Creating a Rackspace and NASA Nebula compatible cloud using the OpenStack project (Invited). AGU Fall Meeting Abstracts, page D1, December 2010.

[Cohen 1977] D. Cohen. Speciﬁcations for the Network Voice Protocol (NVP). RFC 741, November 1977.

[Cranor 2003] C. Cranor, T. Johnson, O. Spatscheck and V. Shkapenyuk. Gigascope: A Stream Database for Network Applications. In SIGMOD, 2003.

[de Assuncao 2009] Marcos Dias de Assuncao, Alexandre di Costanzo and Rajkumar Buyya. Evaluating the cost-beneﬁt of using cloud computing to extend the capacity of clusters. In Proceedings of the 18th ACM international symposium on High performance distributed computing, HPDC ’09, pages 141–150, New York, NY, USA, 2009. ACM. BIBLIOGRAPHY 181

[de Assunção 2009] Marcos Dias de Assunção and Rajkumar Buyya. Performance analysis of allocation policies for interGrid resource provisioning. Inf. Softw. Technol., vol. 51, pages 42–55, January 2009.

[Deelman 2008] Ewa Deelman, Gurmeet Singh, Miron Livny, Bruce Berriman and John Good. The cost of doing science on the cloud: the Montage example. In Proceedings of the 2008 ACM/IEEE conference on Supercomputing, SC ’08, pages 50:1–50:12, Piscataway, NJ, USA, 2008. IEEE Press.

[den Bossche 2011] Ruben Van den Bossche, Kurt Vanmechelen and Jan Broeckhove. Cost- Efﬁcient Scheduling Heuristics for Deadline Constrained Workloads on Hybrid Clouds. Cloud Computing Technology and Science, IEEE International Conference on, vol. 0, pages 320–327, 2011.

[Dorcey 1995] Tim Dorcey. CU-SeeMe Desktop VideoConferencing Software. Connexions, vol. 9, no. 3, march 1995.

[Escribano 2010] Fernando Escribano, Javier Cerviño, Pedro Rodríguez and Joaquín Salvachúa. Videoconferencia con Isabel en la Web 2.0. In Actas de las IX Jornadas de Ingeniería Telemática, JITEL 2010, Valladolid, España, 2010. Universidad de Valladolid.

[Ferreto 2002] T.C. Ferreto, C.A.F. de Rose and L. de Rose. RVision: An Open and High Conﬁgurable Tool for Cluster Monitoring. In Cluster Computing and the Grid, 2002. 2nd IEEE/ACM International Symposium on, page 75, may 2002.

[Ferretti 2010] S. Ferretti, V. Ghini, F. Panzieri, M. Pellegrini and E. Turrini. QoS-Aware Clouds. In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pages 321 –328, July 2010.

[Fielding 1999] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners- Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Draft Standard), June 1999. Updated by RFCs 2817, 5785.

[Fielding 2000] R. Fielding. Representational state transfer (rest). Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine, 2000. 182 BIBLIOGRAPHY

[Franks 1999] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen and L. Stewart. HTTP Authentication: Basic and Digest Access Authentication. RFC 2617 (Draft Standard), June 1999.

[Garﬁnkel 2007] Simson L. Garﬁnkel. An Evaluation of Amazon’s Grid Computing Services: EC2, S3 and SQS. Rapport technique, Center for, 2007.

[Gogouvitis 2011] Spyridon V. Gogouvitis, George Kousiouris, George Vaﬁadis, Hillel Kolodner and Dimosthenis Kyriazis. OPTIMIS and VISION Cloud: How to manage data in clouds. In Cloud Computing: Project and Initiatives. Collocated with: Euro-Par 2011 International Conference, 2011.

[Goyal 2010] Pankaj Goyal. Enterprise Usability of Cloud Computing Environments: Issues and Challenges. IEEE Enabling Technologies, pages 54–59, 2010.

[Greenberg 2009] Albert Greenberg, James R. Hamilton, Navendu Jain, Srikanth Kandula, Changhoon Kim, Parantap Lahiri, David A. Maltz, Parveen Patel and Sudipta Sengupta. VL2: a scalable and ﬂexible data center network. In Proceedings of the ACM SIGCOMM 2009 conference on Data communication, SIGCOMM ’09, pages 51–62, New York, NY, USA, 2009. ACM.

[Group 1996a] Audio-Video Transport Working Group and H. Schulzrinne. RTP Proﬁle for Audio and Video Conferences with Minimal Control. RFC 1890 (Proposed Standard), January 1996. Obsoleted by RFC 3551.

[Group 1996b] Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 1889 (Proposed Standard), January 1996. Obsoleted by RFC 3550.

[Guo 2009] Chuanxiong Guo, Guohan Lu, Dan Li, Haitao Wu, Xuan Zhang, Yunfeng Shi, Chen Tian, Yongguang Zhang and Songwu Lu. BCube: a high performance, server-centric network architecture for modular data centers. In SIGCOMM’09, pages 63–74, 2009.

[Hajjat 2010] Mohammad Hajjat, Xin Sun, Yu wei Eric Sung et al. Cloudward bound: Planning for beneﬁcial migration of enterprise applications to the cloud. In SIGCOMM, 2010. BIBLIOGRAPHY 183

[Handley 1999] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg. SIP: Session Initiation Protocol. RFC 2543 (Proposed Standard), March 1999. Obsoleted by RFCs 3261, 3262, 3263, 3264, 3265.

[Hill 2010] Zach Hill, Jie Li, Ming Mao, Arkaitz Ruiz-Alvarez and Marty Humphrey. Early observations on the performance of Windows Azure. In Proceedings of the 19th ACM International Symposium on High Performance Distributed Computing, HPDC ’10, pages 367–376, New York, NY, USA, 2010. ACM.

[Hoffa 2008] Christina Hoffa, Gaurang Mehta, Tim Freeman, Ewa Deelman, Kate Keahey, Bruce Berriman and John Good. On the Use of Cloud Computing for Scientiﬁc Workﬂows. In Proceedings of the 2008 Fourth IEEE International Conference on eScience, pages 640– 645, Washington, DC, USA, 2008. IEEE Computer Society.

[Imran 2007] K. Imran, M. Mellia and M. Meo. Measurements of Multicast Television over IP. In Local Metropolitan Area Networks, 2007. LANMAN 2007. 15th IEEE Workshop on, pages 170 –175, june 2007.

[Incorporated 2007] Adobe Systems Incorporated. Action Message Format – AMF 3, December 2007.

[Incorporated 2009] Adobe Systems Incorporated. Real-Time Messaging Protocol (RTMP) Speciﬁcation, June 2009.

[Independent 1934] The Evening Independent. German Post-Ofﬁce to Use Television-Telephone for its Communication System. The Evening Independent, September 1934.

[ITU-T 1996] ITU-T. ITU, Draft Recommendation H.323. Rapport technique, ITU-T, november 1996.

[ITU-T 2007] ITU-T. ITU-T Recommendation H.264 : Advanced video coding for generic audiovisual services, November 2007.

[Johansen 1988] R. Johansen. Groupware: Computer support for business teams, 1988.

[Kalapatapu 2012] Abhishek Kalapatapu and Mahasweta Sarkar. Cloud Computing: And Overview. In Lizhe Wang, Rajiv Ranjan, Jinjun Chen and Boualem Benatallah, editeurs, 184 BIBLIOGRAPHY

Cloud Computing. Methodology, Systems and Applications, pages 3–29. CRC Press, Taylor & Francis Group, 2012.

[Karlsson 1996] G. Karlsson. Asynchronous transfer of video. Communications Magazine, IEEE, vol. 34, no. 8, pages 118 –126, August 1996.

[Klems 2009] Markus Klems, Jens Nimis and Stefan Tai. Do Clouds Compute? A Framework for Estimating the Value of Cloud Computing. In Designing E-Business Systems. Markets, Services, and Networks, volume 22 of Lecture Notes in Business Information Processing, pages 110–123. Springer Berlin Heidelberg, 2009.

[Leavitt 2009] N. Leavitt. Is cloud computing really ready for prime time? Growth, vol. 27, page 5, 2009.

[Li 2009] Jim Li, John Chinneck, Murray Woodside et al. Performance model driven QoS guarantees and optimization in clouds. In ICSE Workshop, CLOUD 2009, pages 15–22, 2009.

[Li 2010a] Ang Li, Xiaowei Yang, Srikanth Kandula and Ming Zhang. CloudCmp: comparing public cloud providers. In Proceedings of the 10th annual conference on Internet measurement, IMC ’10, pages 1–14, New York, NY, USA, 2010. ACM.

[Li 2010b] Junchao Li, Ruifeng Guo and Xiuwu Zhang. Study on Service-Oriented Cloud Conferencing. In IEEE ICCSIT, volume 6, pages 21 –25, 2010.

[Li 2011] Haitao Li, Lili Zhong, Jiangchuan Liu, Bo Li and Ke Xu. Cost-Effective Partial Migration of VoD Services to Content Clouds. IEEE CLOUD, pages 203–210, 2011.

[Livenson 2011] Ilja Livenson and Erwin Laure. Towards transparent integration of heterogeneous cloud storage platforms. In Proceedings of the fourth international workshop on Data-intensive distributed computing, DIDC ’11, pages 27–34, New York, NY, USA, 2011. ACM.

[Lu 2010] Wei Lu, Jared Jackson and Roger Barga. AzureBlast: a case study of developing science applications on the cloud. In Proceedings of the 19th ACM International Symposium on High Performance Distributed Computing, HPDC ’10, pages 413–420, New York, NY, USA, 2010. ACM. BIBLIOGRAPHY 185

[Lucas Simarro 2011] J.L. Lucas Simarro, R. Moreno-Vozmediano, R.S. Montero and I.M. Llorente. Dynamic placement of virtual machines for cost optimization in multi- cloud environments. In High Performance Computing and Simulation (HPCS), 2011 International Conference on, pages 1 –7, july 2011.

[Marshall 2010] Paul Marshall, Kate Keahey and Tim Freeman. Elastic Site: Using Clouds to Elastically Extend Site Resources. In Proceedings of the 2010 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing, CCGRID ’10, pages 43–52, Washington, DC, USA, 2010. IEEE Computer Society.

[Massie 2004] Matthew L. Massie, Brent N. Chun and David E. Culler. The Ganglia Distributed Monitoring System: Design, Implementation And Experience, 2004.

[McLellan 2010] Alastair McLellan. White paper. Conﬂicting messages from the hint at growing resistance. The Health service journal, vol. 120, no. 6224, page 3, September 2010.

[Mei 2010] Yiduo Mei, Ling Liu, Xing Pu and Sankaran Sivathanu. Performance Measurements and Analysis of Network I/O Applications in Virtualized Cloud. In Proceedings of the 2010 IEEE 3rd International Conference on Cloud Computing, CLOUD ’10, pages 59– 66, Washington, DC, USA, 2010. IEEE Computer Society.

[Mell 2011] Peter Mell and Timothy Grance. The NIST Deﬁnition of Cloud Computing ( Draft ) Recommendations of the National Institute of Standards and Technology. NIST Special Publication, vol. 145, no. 6, page 7, 2011.

[Milojic andic and 2011] Dejan Milojic andic and, Ignacio M. Llorente and Ruben S. Montero. OpenNebula: A Cloud Management Tool. Internet Computing, IEEE, vol. 15, no. 2, pages 11 –14, march-april 2011.

[Mohagheghi 2010] Parastoo Mohagheghi, Arne Berre, Alexis Henry, Franck Barbier and Andrey Sadovykh. REMICS- REuse and Migration of Legacy Applications to Interoperable Cloud Services. In Elisabetta Di Nitto and Ramin Yahyapour, editeurs, Towards a Service-Based Internet, volume 6481 of Lecture Notes in Computer Science, pages 195–196. Springer Berlin / Heidelberg, 2010. 186 BIBLIOGRAPHY

[Moreno-Vozmediano 2009] Rafael Moreno-Vozmediano, Ruben S. Montero and Ignacio M. Llorente. Elastic management of cluster-based services in the cloud. In Proceedings of the 1st workshop on Automated control for datacenters and clouds, ACDC ’09, pages 19–24, New York, NY, USA, 2009. ACM.

[Murphy 2009] Michael A. Murphy, Brandon Kagey, Michael Fenn and Sebastien Goasguen. Dynamic Provisioning of Virtual Organization Clusters. In Proceedings of the 2009 9th IEEE/ACM International Symposium on Cluster Computing and the Grid, CCGRID ’09, pages 364–371, Washington, DC, USA, 2009. IEEE Computer Society.

[Nakai 2001] J. Nakai. Pricing Computing Resources: Reading Between the Lines and Beyond. Rapport technique, NASA, Advanced Supercomputing Division, 2001.

[Nottingham 2005] Mark Nottingham and Robert Sayre. RFC 4287 The Atom Syndication Format. Internet Engineering Task Force (IETF), December 2005.

[Nurmi 2009] Daniel Nurmi, Rich Wolski, Chris Grzegorczyk, Graziano Obertelli, Sunil Soman, Lamia Youseff and Dmitrii Zagorodnov. The Eucalyptus Open-Source Cloud-Computing System. In Proceedings of the 2009 9th IEEE/ACM International Symposium on Cluster Computing and the Grid, CCGRID ’09, pages 124–131, Washington, DC, USA, 2009. IEEE Computer Society.

[Padala 2009] Pradeep Padala, Kai-Yuan Hou, Kang G. Shin, Xiaoyun Zhu, Mustafa Uysal, Zhikui Wang, Sharad Singhal and Arif Merchant. Automated Control of Multiple Virtualized Resources. In EuroSys, 2009.

[Paquette 2010] Scott Paquette, Paul T Jaeger and Susan C Wilson. Identifying the security risks associated with governmental use of cloud computing. Government Information Quarterly, vol. 27, no. 3, pages 245–253, 2010.

[Parkhill 1966] D.F. Parkhill. The challenge of the computer utility. Numeéro p. 246 de The Challenge of the Computer Utility. Addison-Wesley Pub. Co., 1966.

[Pautasso 2009] Cesare Pautasso and Erik Wilde, 2009. BIBLIOGRAPHY 187

[Pereira 2010] R. Pereira, M. Azambuja, K. Breitman and M. Endler. An Architecture for Distributed High Performance Video Processing in the Cloud. In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pages 482 –489, july 2010.

[Potociar 2007] Marek Potociar. JSR 311: JAX-RS: The Java API for RESTful Web Services. Rapport technique, The Java Community Process, 2007.

[Quemada 2004] Juan Quemada, Gabriel Huecas, Tomás de Miguel, Joaquín Salvachúa, Blanca Fernandez, Bernd Simon, Katherine Maillet and Eﬁie Lai-Cong. Educanext: a framework for sharing live educational resources with isabel. In WWW (Alternate Track Papers & Posters), pages 11–18, 2004.

[Quemada 2005] J. Quemada, T. de Miguel, S. Pavon, G. Huecas, T. Robles, J. Salvachua, D.a.a. Ortiz, V. Sirvent, F. Escribano and J. Sedano. Isabel: An Application for real time Collaboration with a ﬂexible Floor Control. In 2005 International Conference on Collaborative Computing: Networking, Applications and Worksharing, pages 1–9. Ieee, 2005.

[Reese 2009] George Reese. Cloud application architectures. O’Reilly, 2009.

[Richardson 1998] Tristan Richardson and Kenneth R. Wood. The RFB Protocol, July 1998.

[Rivest 1992] R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321 (Informational), April 1992.

[Robles 2000] Tomás Robles, Héctor L. Velayos Munoz, Juan Quemada, Tomás de Miguel, Santiago Pavón, Joaquín Salvachúa, Gabriel Huecas, Eva M. Castro and Manuel Petit. Managing Distributed Conferences with ISABEL. In MMNS, pages 89–101, 2000.

[Rochwerger 2009] Benny Rochwerger, David Breitgand, Eliezer Levy, Alex Galis, Kenneth Nagin, Ignacio M. Llorente, Ruben Montero, Yaron Wolfsthal, Erik Elmroth, Juan Caceres, Muli Ben-Yehuda, Wolfgan Emmerich and Fermin Galan. The RESERVOIR Model and Architecture for Open Federated Cloud Computing. IBM Journal of Research and Development, vol. 53, no. 4, 2009. 188 BIBLIOGRAPHY

[Rodríguez 2009] Pedro Rodríguez, Daniel Gallego, Javier Cerviño, Fernando Escribano, Juan Quemada and Joaquín Salvachúa. VaaS: Videoconference as a service. In CollaborateCom, pages 1–11, 2009.

[Rodríguez 2012] Pedro Rodríguez, Javier Cerviño, Irena Trajkovska and Joaquín Salvachúa. Advanced topics in videoconferencing based on WebRTC. In 2012 IADIS Collaborative Technologies, Lisbon, Portugal, 2012. IADIS.

[Rosenberg 2002] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler. SIP: Session Initiation Protocol. RFC 3261 (Proposed Standard), June 2002.

[Ruth 2005] P. Ruth, P. McGachey and Dongyan Xu. VioCluster: Virtualization for Dynamic Computational Domains. In Cluster Computing, 2005. IEEE International, pages 1 –10, sept. 2005.

[Ruth 2006] P. Ruth, Junghwan Rhee, Dongyan Xu, R. Kennell and S. Goasguen. Autonomic Live Adaptation of Virtual Computational Environments in a Multi-Domain Infrastructure. In Autonomic Computing, 2006. ICAC ’06. IEEE International Conference on, pages 5 – 14, june 2006.

[Saint-Andre 2007] Peter Saint-Andre. Jingle: Jabber Does Multimedia. IEEE MultiMedia, vol. 14, pages 90–94, January 2007.

[Salvachúa 2008] Joaquín Salvachúa, Juan Quemada, Sandra Aguirre, Alberto Mozo, Antonio Tapiador, Antonio Fumero, Isidro Padilla, Juan Carlos, Fernando, Javier Cervi no and Diego Moreno. La plataforma iTecSoft: Un caso de colaboración inter-organizativa 2.0. In Libro de Actas de las XVIII Jornadas Telecom I+D, pages 1– 4, 2008.

[Schooler 1989] Eve Schooler and Stephen Casner. A packet-switched multimedia conferencing system. SIGOIS Bull., vol. 10, pages 12–22, January 1989.

[Schulzrinne 1998] H. Schulzrinne, A. Rao and R. Lanphier. Real Time Streaming Protocol (RTSP). RFC 2326 (Proposed Standard), April 1998. BIBLIOGRAPHY 189

[Sivathanu 2010] S. Sivathanu, Ling Liu, Mei Yiduo and Xing Pu. Storage Management in Virtualized Cloud Environment. In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pages 204 –211, july 2010.

[Song 2009] Biao Song, M.M. Hassan, Eui-Nam Huh et al. A Hybrid Algorithm for Partner Selection in Market Oriented Cloud Computing. In MASS, 2009.

[Sotomayor 2008] Borja Sotomayor, Ruben Santiago Montero, Ignacio Martin Llorente and Ian Foster. Capacity leasing in cloud systems using the opennebula engine. Cloud Computing and its Applications, 2008.

[Sotomayor 2009] Borja Sotomayor, Ruben Santiago Montero, Ignacio Martin Llorente and Ian Foster. Virtual Infrastructure Management in Private and Hybrid Clouds. IEEE Internet Computing, vol. 13, no. 5, pages 14–22, 2009.

[Sottile 2002] Matthew J. Sottile and Ronald G. Minnich. Supermon: A High-Speed Cluster Monitoring System. In In Proc. of IEEE Intl. Conference on Cluster Computing, pages 39–46, 2002.

[Tapiador 2008] Antonio Tapiador, Antonio Fumero, Joaquín Salvachúa and Javier Cerviño. Identidad Extendida en Redes Sociales. In Libro de Ponencias de la VII Jornadas de Ingeniería Telemática, pages 293– 296, Alcalá de Henares, España, 2008. Universidad de Alcalá de Henares.

[Times 1927] The New York Times. Far-Off Speakers Seen as Well as Heard Here in a Test of Television. The New York Times, April 1927.

[Tordsson 2012] Johan Tordsson, Rubén S. Montero, Rafael Moreno-Vozmediano and Ignacio Martín Llorente. Cloud brokering mechanisms for optimized placement of virtual machines across multiple providers. Future Generation Comp. Syst., vol. 28, no. 2, pages 358–367, 2012.

[Trajkovska 2012] Irena Trajkovska, Pedro Rodríguez, Javier Cerviño and Joaquín Salvachúa. Opportunities and Challenges of Implementing P2P Streaming Applications in the Web. In 2012 IADIS Collaborative Technologies, Lisbon, Portugal, 2012. IADIS. 190 BIBLIOGRAPHY

[Tripathi 2003] Anand R. Tripathi, Tanvir Ahmed and R. Kumar. Speciﬁcation of Secure Distributed Collaboration Systems. In IEEE International Symposium on Autonomous Distributed Systems (ISADS), April 2003.

[Use Case Discussion Group 2009] Use Case Discussion Group. Cloud Computing Use Cases v2.0, 2009.

[Vaquero 2009] Luis M. Vaquero, Luis Rodero-merino, Juan Caceres and Maik Lindner. A break in the clouds: Towards a cloud deﬁnition. ACM SIGCOMM Computer Communication Review, pages 50–55, 2009.

[Voras 2011] I. Voras, B. Mihaljevic, M. Orlic, M. Pletikosa, M. Zagar, T. Pavic, K. Zimmer, I. Cavrak, V. Paunovic, I. Bosnic and S. Tomic. Evaluating open-source cloud computing solutions. In MIPRO, 2011 Proceedings of the 34th International Convention, pages 209 –214, may 2011.

[Wang 2010] Lizhe Wang, Gregor von Laszewski, Andrew Younge, Xi He, Marcel Kunze, Jie Tao, Cheng Fu, Lizhe Wang, Gregor Laszewski, Andrew Younge, Xi He, Marcel Kunze, Jie Tao and Cheng Fu. Cloud Computing: a Perspective Study. New Generation Computing, vol. 28, no. 2, pages 137–146, April 2010.

[Weissman 2009] Jon Weissman and Siddharth Ramakrishnan. Using Proxies to Accelerate Cloud Applications. In HotCloud’09 Proceedings of the 2009 conference on Hot topics in cloud computing, 2009.

[Welsh 2001] Matt Welsh, David Culler and Eric Brewer. SEDA: an architecture for well- conditioned, scalable internet services. In Proceedings of the eighteenth ACM symposium on Operating systems principles, SOSP ’01, pages 230–243, New York, NY, USA, 2001. ACM.

[Welsh 2002] Matthew David Welsh. An architecture for highly concurrent, well-conditioned internet services. PhD thesis, University of California, Berkeley, 2002. AAI3082454.

[Wischik 2008] Damon Wischik, Mark Handley and Marcelo Bagnulo Braun. The Resource Pooling Principle. ACM CCR, 2008. BIBLIOGRAPHY 191

[Wolski 1999] Rich Wolski, Neil T. Spring and Jim Hayes. The Network Weather Service: A Distributed Resource Performance Forecasting Service for Metacomputing. Journal of Future Generation Computing Systems, vol. 15, pages 757–768, 1999.

[Zhang 2010] Qi Zhang, Lu Cheng and Raouf Boutaba. Cloud computing: state-of-the-art and research challenges. Journal of Internet Services and Applications, vol. 1, pages 7–18, 2010. 10.1007/s13174-010-0007-6.