UNIVERSIDAD POLITÉCNICA DE MADRIDaparació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

UNIVERSIDAD POLITÉCNICA DE MADRID

Escuela Técnica Superior de Ingenieros de Telecomunicación

CONTRIBUTION TO MULTIUSER VIDEOCONFERENCINGSYSTEMS BASED ON CLOUD COMPUTING

TESIS DOCTORAL

Javier Cerviño ArribaIngeniero de Telecomunicación

Madrid, España2013

Departamento de Ingeniería de Sistemas Telemáticos

Escuela Técnica Superior de Ingenieros de Telecomunicación

CONTRIBUTION TO MULTIUSER VIDEOCONFERENCING SYSTEMS BASEDON CLOUD COMPUTING

Autor: Javier Cerviño ArribaIngeniero de Telecomunicación

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

2013

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

Presidente:

Vocal:

Vocal:

Vocal:

Secretario:

Suplente:

Suplente:

Realizado el acto de defensa y lectura de la Tesis el día 6 de mayo de 2013 en Madrid, habiendoobtenido la calificació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 ofthese systems has been increased recently due to, on the one hand, improvements in Internetaccess, networks of companies, universities and houses, whose available bandwidth has beenincreased whilst the delay in sending and receiving packets has decreased. On the other hand, theadvent of Rich Internet Applications (RIA) means that a large part of web application logic andcontrol has started to be implemented on the web browsers. This has allowed developers to createweb 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 andinvolves a reduction in the price of backend systems. This offers the possibility of implementingweb services on the Internet with no need to spend a lot of money when deploying infrastructuresand resources, both hardware and software. Nevertheless there are not many initiatives that aim toimplement videoconferencing systems taking advantage of Cloud systems.

This dissertation proposes a set of techniques, interfaces and algorithms for theimplementation of videoconferencing systems in public and private Cloud Computinginfrastructures. The mechanisms proposed here are based on the implementation of a basicvideoconferencing system that runs on the web browser without any previous installationrequirements. To this end, the development of this thesis starts from a RIA application withcurrent 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 beenimplemented to allow end users to participate in videoconferencing rooms that are managed indifferent Cloud provider servers. To do so this dissertation starts from the results obtained fromthe previous techniques and backend resources were implemented in the Cloud. A traditionalvideoconferencing service which was implemented in the department was modified to meettypical Cloud Computing infrastructure requirements. This allowed us to validate whether CloudComputing public infrastructures are suitable for the traffic generated by this kind of system. Thisanalysis focused on the network level and processing capacity and stability of the CloudComputing systems. In order to improve this validation several other general considerations weretaken in order to cover more cases, such as multimedia data processing in the Cloud, as researchactivity has increased in this area in recent years. The last stage of this dissertation is the designof a new methodology to implement these kinds of applications in hybrid clouds reducing thecost of videoconferencing systems.

Finally, this dissertation opens up a discussion about the conclusions obtained throughout thisstudy, resulting in useful information from the different stages of the implementation ofvideoconferencing systems in Cloud Computing systems.

RESUMEN

Los sistemas de videoconferencia multiusuario permiten la comunicación entre más de dosusuarios que pueden interactuar a través de cámaras de video, micrófonos y otros elementos. Enlos últimos años el uso de estos sistemas se ha visto incrementado gracias, por un lado, a la mejorade las redes de acceso en las conexiones a Internet en empresas, universidades y viviendas, quehan visto un aumento del ancho de banda disponible en dichas conexiones y una disminuciónen el retardo experimentado por los datos enviados y recibidos. Por otro lado también ayudó laaparación de las Aplicaciones Ricas de Internet (RIA) con las que gran parte de la lógica y delcontrol de las aplicaciones web comenzó a ejecutarse en los mismos navegadores. Esto permitió alos desarrolladores la creación de aplicaciones web cuya complejidad podía compararse con la delas 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 elabaratamiento de los costes para sistemas de backend, ofreciendo la posibilidad de implementarservicios Web en Internet sin la necesidad de grandes desembolsos iniciales en las áreas deinfraestructuras y recursos tanto hardware como software. Sin embargo no existen aún muchasiniciativas con el objetivo de realizar sistemas de videoconferencia que aprovechen las ventajasdel Cloud.

Esta tesis doctoral propone un conjunto de técnicas, interfaces y algoritmos para laimplentación de sistemas de videoconferencia en infraestructuras tanto públicas como privadasde Cloud Computing. Las técnicas propuestas en la tesis se basan en la realización de un serviciobásico de videoconferencia que se ejecuta directamente en el navegador sin la necesidad deinstalar ningún tipo de aplicación de escritorio. Para ello el desarrollo de esta tesis parte de unaaplicación RIA con tecnologías que hoy en día permiten acceder a la cámara y al micrófonodirectamente desde el navegador, y enviar los datos que capturan a través de la conexión deInternet. Además se han implementado interfaces que permiten a usuarios finales la participaciónen salas de videoconferencia que se ejecutan en servidores de proveedores de Cloud. Para ello separtió de los resultados obtenidos en las técnicas anteriores de ejecución de aplicaciones en elnavegador y se implementaron los recursos de backend en la nube. Además se modificó unservicio ya existente implementado en el departamento para adaptarlo a los requisitos típicos delas infraestructuras de Cloud Computing. Alcanzado este punto se procedió a analizar si lasinfraestructuras propias de los proveedores públicos de Cloud Computing podrían soportar eltráfico generado por los sistemas que se habían adaptado. Este análisis se centró tanto a nivel dered como a nivel de capacidad de procesamiento y estabilidad de los sistemas. Para los pasos deanálisis y validación de los sistemas Cloud se tomaron consideraciones más generales paraabarcar casos como el procesamiento de datos multimedia en la nube, campo en el que comienzaa haber bastante investigación en los últimos años. Como último paso se ideó una metodología deimplementación de este tipo de aplicaciones para que fuera posible abaratar los costes de lossistemas de videoconferencia haciendo uso de clouds híbridos.

Finalmente en la tesis se abre una discusión sobre las conclusiones obtenidas a lo largo deeste amplio estudio, obteniendo resultados útiles en las distintas etapas de implementación de lossistemas de videoconferencia en la nube.

Agradecimientos

Ante todo quiero agradecer el trabajo de mi director de tesis, Joaquín Salvachúa, por su apoyo ypor contagiarme en innumerables ocasiones su optimismo en los momentos malos de miinvestigación. Igualmente me gustaría agradecérselo al resto de personal del departamento, enespecial a Juan Quemada, Gabriel Huecas, Santiago Pavón y Mónica Cortés por su ayuda parapreparar 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, alos Isabelinos. No voy a poner nombres porque, para alguien que hace una tesis es ocupar dos otres páginas, y si veis ésta comprenderéis que me he pasado del límite ya. Voy a agradecermomentos y anécdotas que entre todos me habéis dado durante todo este tiempo: la bienvenida aldepartamento, que para mi fue como una fiesta continua que duró un mes entero, con variasconferencias, cenas, etc., de las que recuerdo gente bailando con parejas extrañas y gentesaliendo con urgencia del coche de Santi, etc. Gracias por tantas y tantas lecturas de proyecto finde carrera, tras las que siempre hemos conversado tranquilamente en el B-122. Por aquellassobremesas 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 lascenas 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 nocaben 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 comolos que más a empezar esta aventura y me habéis seguido ayudando todo este tiempo, sinimportar lo lejos que estéis.

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

Como siempre, y como con todo, la que más me ha apoyado eres tú, Bea. Gracias a ti, porquenadie como tú ha "sufrido" tanto esta tesis, y nadie como tú me ha sabido dar consejos tan buenosa 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 mejoressobrinos en el mundo entero!

Muchísimas gracias a todos!

Contents

AbstractResumenAcknowledgmentsList of IllustrationsList of Tables

1 Introduction 11.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Related Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 ITECBAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 ECOSPACE (IST-2005-35208) . . . . . . . . . . . . . . . . . . . . . . . 71.3.3 C@R (IST-2006-034921) . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.4 GLOBAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Structure of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.1 Chapter 2: State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.2 Chapter 3: Interface for Videoconferencing in the Cloud . . . . . . . . . 91.4.3 Chapter 4: Videoconferencing System Architecture . . . . . . . . . . . . 91.4.4 Chapter 5: Methodologies for Testing Cloud Computing Infrastructures . 101.4.5 Chapter 6: Cost-Effective Videoconferencing for Hybrid Clouds . . . . . 101.4.6 Chapter 7: Validation And Results . . . . . . . . . . . . . . . . . . . . . 101.4.7 Chapter 8: Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 State of the Art 112.1 Cloud Computing Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Overview of Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . 112.1.2 Cloud Computing Providers . . . . . . . . . . . . . . . . . . . . . . . . 192.1.3 Cloud Computing Platforms . . . . . . . . . . . . . . . . . . . . . . . . 252.1.4 Related Cloud Research . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2 Technologies for Rich Internet Applications . . . . . . . . . . . . . . . . . . . . 322.2.1 Adobe Flash Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.2 Java FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.3 Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.2.4 AJAX Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.5 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.3 Multiparty Videoconferencing Systems . . . . . . . . . . . . . . . . . . . . . . 482.3.1 History of Multiparty Videoconferencing Systems . . . . . . . . . . . . 492.3.2 Signalling Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.3.3 Technologies For Sending Media Flows . . . . . . . . . . . . . . . . . . 58

CONTENTS

2.3.4 Web VideocOnferencing Systems . . . . . . . . . . . . . . . . . . . . . 62

3 Interface for Videoconferencing in the Cloud 653.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.3 Marte Web Videoconferencing Architecture . . . . . . . . . . . . . . . . . . . . 67

3.3.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.4 Videoconferencing and Cloud Computing . . . . . . . . . . . . . . . . . . . . . 713.5 Nuve: Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.5.1 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.5.2 Rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.5.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.5.4 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.6 Nuve API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.6.1 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.6.2 Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773.6.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.6.4 Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.7.1 Description of the problem and experiences . . . . . . . . . . . . . . . . 823.7.2 Security in Nuve: MAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.8 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883.8.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883.8.2 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.9 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4 Videoconferencing System Architecture 954.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.3.1 Conference Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.4.1 Isabel-based videoconferencing . . . . . . . . . . . . . . . . . . . . . . 1044.4.2 Flash-based videoconferencing . . . . . . . . . . . . . . . . . . . . . . . 1054.4.3 SIP-based videoconferencing . . . . . . . . . . . . . . . . . . . . . . . . 1054.4.4 VNC and desktop sharing . . . . . . . . . . . . . . . . . . . . . . . . . 1064.4.5 Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106


5 Methodologies for Testing Cloud Infrastructures 1095.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.3 Amazon Network Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.3.1 Important network features . . . . . . . . . . . . . . . . . . . . . . . . . 1135.3.2 Architecture of the measuring environment . . . . . . . . . . . . . . . . 115

CONTENTS

5.3.3 Measurement results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.3.4 Network Measurements for Stream Processing Systems . . . . . . . . . . 1205.3.5 Processing measurements for Stream Processing Systems . . . . . . . . . 1225.3.6 Discussion For Stream Processing Systems in the Cloud . . . . . . . . . 123

5.4 Multimedia Streaming Experiments . . . . . . . . . . . . . . . . . . . . . . . . 1245.4.1 Tools and statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245.4.2 Scenario architecture description . . . . . . . . . . . . . . . . . . . . . . 1265.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.5 Adaptive Cloud Stream Processing Algorithm . . . . . . . . . . . . . . . . . . . 1295.5.1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.5.3 Experimental Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 132


6 Cost-Effective Videoconferencing for Hybrid Clouds 1376.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.2 Motivation and Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.3 Validation of Hybrid Cloud for a Videoconferencing System . . . . . . . . . . . 140

6.3.1 General methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.3.2 Cost analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.3.3 Results Validation and Performance Evaluation . . . . . . . . . . . . . . 145

6.4 Test scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466.4.1 Project resource usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476.4.2 Research using Conference Manager . . . . . . . . . . . . . . . . . . . . 147


7 Validation And Results 1497.1 Validation in European Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

7.1.1 ECOSPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497.1.2 Collaboration At Rural . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517.1.3 GLOBAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

7.2 Validation in National Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557.2.1 ITECBAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557.2.2 IBA and CyberAula 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 158

7.3 Dissemination of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.3.1 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.3.2 Research Visit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627.3.3 Teaching and Seminars . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

8 Conclusions 1658.1 Videoconferences Interfaces in Cloud? . . . . . . . . . . . . . . . . . . . . . . . 1668.2 Factors to be considered in the implementation on Clouds? . . . . . . . . . . . . 1688.3 How to adapt videoconferencing to Hybrid Clouds? . . . . . . . . . . . . . . . . 1698.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698.5 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

CONTENTS

Bibliography 177

Illustrations

2.1 Layered design of a cloud datacentre network architecture . . . . . . . . . . . . 172.2 Amazon EC2’s main components . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Percentage of clients with RIA sandboxes installed . . . . . . . . . . . . . . . . 342.4 JavaFX 2.0 Architecture Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 392.5 HTML5 APIs and related technologies . . . . . . . . . . . . . . . . . . . . . . . 472.6 Multiparty Videoconferencing Technical Components . . . . . . . . . . . . . . . 492.7 AT&T’s Picturephone component diagram . . . . . . . . . . . . . . . . . . . . . 502.8 Example of Messages Sent During a SIP Session . . . . . . . . . . . . . . . . . 552.9 List of Messages Used in Jingle . . . . . . . . . . . . . . . . . . . . . . . . . . 572.10 Overview of real-time protocols and standards . . . . . . . . . . . . . . . . . . . 62

3.1 Nuve Layer Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.2 Authentication Sequence Messages . . . . . . . . . . . . . . . . . . . . . . . . . 873.3 Service Deletion Programming Logic . . . . . . . . . . . . . . . . . . . . . . . 903.4 Bandwidth and CPU consumption in different scenarios . . . . . . . . . . . . . . 91

4.1 Conference Manager Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 984.2 Conference Manager REST API . . . . . . . . . . . . . . . . . . . . . . . . . . 994.3 Conference Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . 1044.4 Videoconferencing real scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.1 Architecture of the measuring environment . . . . . . . . . . . . . . . . . . . . 1125.2 Measurement results between datacentres EU-US . . . . . . . . . . . . . . . . . 1175.3 Measurement results between datacentres EU-AP . . . . . . . . . . . . . . . . . 1185.4 Measurement results between datacentres US-AP . . . . . . . . . . . . . . . . . 1195.5 Experimental set-up for network measurements . . . . . . . . . . . . . . . . . . 1205.6 Jitter experienced when sending streams to Amazon EC2 . . . . . . . . . . . . . 1215.7 Comparison of network- and application-level delay on Amazon EC2 . . . . . . 1215.8 Performance of Esper as a function of time on Amazon EC2 . . . . . . . . . . . 1225.9 Increase in throughput with different instance sizes on Amazon EC2 (Different

shades/colours correspond to different VMs.) . . . . . . . . . . . . . . . . . . . 1235.10 Node distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.11 The 99.7th percentile of jitter in each scenario . . . . . . . . . . . . . . . . . . . 1355.12 Bytes received in each scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.13 Packet losses in each scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.14 Elastic DSPS with query partitioning across processing VMs . . . . . . . . . . . 1365.15 Dynamic adaptation of VM numbers based on changes in input rates . . . . . . . 136

ILLUSTRATIONS

6.1 Typical Cloud Node Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416.2 Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.3 Cost differences between Cloud architectures . . . . . . . . . . . . . . . . . . . 1456.4 Cost of an Isabel Hybrid Session . . . . . . . . . . . . . . . . . . . . . . . . . . 147

7.1 ECOSPACE’s Primitives for Managing Nuve Functionalities . . . . . . . . . . . 1507.2 Videoconferencing Login Page in ECOSPACE . . . . . . . . . . . . . . . . . . . 1517.3 Example of Marte Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527.4 Screenshot of a recorded event in GlobalPlaza . . . . . . . . . . . . . . . . . . . 1547.5 Form to create an event in GlobalPlaza . . . . . . . . . . . . . . . . . . . . . . . 1557.6 Global Plaza Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567.7 Global Plaza Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577.8 iTecSoft Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587.9 iTecSoft Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.10 iTecSoft Videoconferencing Client . . . . . . . . . . . . . . . . . . . . . . . . . 1607.11 CyberAula Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Tables

2.1 Layered Architecture Of Cloud Computing . . . . . . . . . . . . . . . . . . . . 152.2 List of Cloud Infrastructure Providers . . . . . . . . . . . . . . . . . . . . . . . 252.3 List of Rich Internet Application Frameworks . . . . . . . . . . . . . . . . . . . 352.4 Comparison of Web Videoconferencing Systems . . . . . . . . . . . . . . . . . 64

3.1 Types of HTTP Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.2 Resources From The Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 733.3 HTTP methods used for XML/JSON contents . . . . . . . . . . . . . . . . . . . 813.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 find 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 flexible 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 specific 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 "infinite" 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 specific 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 define 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 sufficient

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.


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 traffic 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 final 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


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 financial 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 workflow 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 first 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âAZs 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


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 definition, a rural area is an area with a population density below 100 inhabitants per km2.Thiscreates 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 istraditionally 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 definition 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.


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 traffic, 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 first 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 definition 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 definition 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


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 fine-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 finally 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

http://www.itu.int/rec/T-REC-X/en


Table 2.1 : Layered Architecture Of Cloud ComputingH

AR

DW

AR

E&

SOFT

WA

RE

STA

CK CLIENTS

Cloud Computing users. Consumers of any cloudservice.

CL

OU

DIN

FRA

STR

UC

TU

RE

SERVICESWeb services. Flickr API, Google Maps API,Storage

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

PLATFORMSVirtual hosting. Use a preconfigured appliance or acustom software stack, AMP, GlassFish, etc.

OPERATING SYSTEMRent a preconfigured OS. Add your ownapplications. Example: DNS server

VIRTUAL SERVERSRent a virtual server. Deploy a VM image or installyour own software stack

PHYSICAL SERVERSRent a compute grid. Example of this would be HPCapplications

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 preconfigured 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.


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


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.


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 efficient 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 benefits. 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


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 find references to a more granular classification 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.


Amazon AWS It is composed of Amazon EC2 (Elastic Compute Cloud) and Amazon S3

(Simple Storage Service) among other services. Currently the highest profile 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 figure 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 firewall; Block Storage volumes are similar to SAN (Storage Area


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.

Security Group

Availability Zone – Data center

Region – Geographic Location

VolumeSnapshot

AMIInstance

I

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 find 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.


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 find CDN, cloud

storage, load balancers, dedicated servers and the possibility of locating virtual machines in

different locations: San Francisco, and Ashburn.


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 configuration of virtual machines through a web

portal and through a RESTful API. And among other features they offer hardware load balancing,

integrated firewalls, 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 first 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.


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 configurations. 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 flow

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


Table 2.2 : List of Cloud Infrastructure Providers

Provider Billing model Interface type Load Balancing SLAAmazon EC2 1 hour SSH/GUI/API 4 99.95%

AT&T Synaptic 1 hour SSH/GUI/API 4 99.9%CloudSigma 5 minutes SSH/GUI/API 7 100%ElasticHosts 1 hour SSH/GUI/API 7 100%FlexiScale 1 hour SSH/GUI/API 7 100%

GoGrid 1 hour SSH/GUI/API 4 100%JoyentCloud 1 month SSH/GUI/API 4 100%Layeredtech 1 month SSH/GUI/API 7 100%

Locaweb 1 month SSH 7 99.9%Opsource 1 hour SSH/GUI/API 4 100%Rackspace 1 hour SSH/GUI/API 7 100%ReliaCloud 1 hour SSH/GUI/API 4 100%RSAWEB 1 month SSH/GUI 7 ND

Storm 1 hour SSH/GUI/API 4 100%Terremark 1 hour SSH/GUI/API 4 100%VPSNET 1 minute SSH/GUI/API 7 100%

availability of load balancing mechanisms, which can be SSH, GUI (Web or through applications)

and API interfaces, and finally 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


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 first 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.


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,

flexible and highly modular with well defined 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

scientific 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.


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 scientific workflow 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 configuration 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


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


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


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


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 flexibility difficult.

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 flow: 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


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 fixes, bug fixes, 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 specific 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.

JUL ’08 DEC ’08 MAY ’09 OCT ’09 MAR ’10 AUG ’10 JAN ’11 JUN ’11 NOV ’110%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Flash Player

Java FX

Silverlight

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 figure was obtained in


Table 2.3 : List of Rich Internet Application Frameworks

AdobeFlash

MicrosoftSilverlight

OracleJavaFX

JavaScriptToolkits

HTML5

ProgrammingLanguage

AS 3.0.NET

FrameworkJava JavaScript JavaScript

UI DefinitionLanguage

MXML XAML FXMLHTML /

CSSHTML /

CSSOpen Source 4a 4b 4 4 4

AcceleratedGraphics

4 4 4 7 4

Animations 4 4 4 7 4

Offline Mode 4 4 4 7 4

Media Streaming 4 4 4 7 4

Videoconf.Capabilities

4 4 4 7 7c

Wide MobileSupport

4d 7e 7f 4 4

Without plug-ininstallation

7 7 7 4 4

Cross-browserCompatibility

4 4 4 7 4g

aThere is an Open Source version called Adobe Flex SDKbThere is an Open Source version of Silverlight called Moonlight that can be used in LinuxcAlthough there is a draft specification, there are not any implementationdIn the case of iOS-based devices there is only support for Flash native applicationseSupported only in Window Phone 7fSupported only in BlackBerrygThere 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 figure 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

http://www.statowl.com


The remainder of this section shows the most important RIA technologies that the reader could

find 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 file with the extension .swf (Shock Wave Flash). Then, this

file 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 first 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


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 figure 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.


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 difficult 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 defining user interface in a JavaFX application. JavaFX


provides different APIs coded in Java for accelerating graphics with GPUs, rendering videos and

playing audio files, 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

Toolkit Media Engine

Web

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


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 first 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 benefit 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 simplifies 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:


• 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

officially 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 difficult 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 first 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 figure 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 officially supporting another project called Moonlight, which is an open source implementation

of Silverlight for Linux and other UNIX-like operating systems.


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 files; 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 offline 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 official 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 files 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.


• 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


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, offline 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


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 fifth 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.


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

specification like WebSocket, RTP, and so on.

There are also new APIs, such as a offline 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 files

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

specification. 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 specifications 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 specifications.

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.


CSS3

MathML

3.0

SVG Selectors

L1

Navigation

Timing

Navigation

Timing

XmlHTTP

Request 1

Geo

Location

Contatcs

API

WebGL

HTTP

Caching

RDFa

WAI-ARIA Device

Orientation

Animation

Timing

Calendar

API

Touch

Events

File API

Media

Capture

Indexed

Database

Web

Workers

Micro

data

Audio

Video

Drag

and

Drop

Canvas

2D

Web

Messaging

Web

Sockets

HTML +

RDFa

Web

Storage

Web SQL

HTML

Markup

HTML5 Taxonomy & Status (December 2011)

W3C Recommendation

Candidate Recommendation

Last Call

Working Draft

Non-W3C Specoifications

Deprecated W3C APIs

By Sergey Mavrody 2011 | CC Attribution-ShareAlike 3.0

CSS3

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 specifications 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


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 definition, 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

confirmation 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

Policy Control Floor Control

Media Control

Media Handling

Conference Application

Signaling

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 flow. 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 files such as Floor Server Control Markup

Language (FSCML).

Next section briefly 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


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

Media

Control Unit

Display and

Video Capture Device

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


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-


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


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


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 first release, the SIP protocol has been extended to also include streaming multimedia

distribution, instant messaging, presence information, gaming, file 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 identified 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 confirm 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.


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.

INVITE: sip:[email protected]

“Calls”

[email protected] INVITE: sip:[email protected]

100 - Trying

180 - Ringing Rings 180 - Ringing

200 - OK Answers 200 - OK

BYE Hangs up

200 - OK

User

Bob

User

Alice

Proxy

Talking Talking RTP

ACK

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


Protocol (SDP), that provides detailed description of media flows 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 configuration 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 definitively accept a session negotiation. This indicates that the

responder is ready to proceed with the session.


• 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 definitions 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 configuration

for an audio stream. And message security-info action is used to send information related to

establishment or maintenance of security preconditions.

session-initiate

content-accept,

content-add,

content-modify,

content-reject,

content-remove,

description-info,

session-info,

transport-accept,

transport-info,

transport-reject,

transport-replace

session-accept

content-accept,

content-add,

content-modify,

content-reject,

content-remove,

description-info,

session-info,

transport-accept,

transport-info,

transport-reject,

transport-replace

session-terminate

PENDING

ACTIVE

ENDED

Figure 2.9 : List of Messages Used in Jingle


There are several implementations of Jingle protocol. The first 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 first on (RTP) is the standardized option. The second one (RTMP) belongs to Adobe

despite it being published in an open specification.

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


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 defining

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

specification of the protocol for public use.


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 difficult typical P2P communications. On the other hand, there is an


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 specified for sending multimedia information through

the Internet. The great majority is defined 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 first 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

defines VCR-like commands, such as play, pause and stop, to facilitate real-time remote

control of media files 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.


RTCP RTP

IP

Call Control Media Delivery

H.225

Q.931

H.323

RAS

UDP

H.245

RTSP

Audio/

Video RPC

RTMP

TCP UDP

Jingle

XMPP

TCP

SIP

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


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 officially 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 traffic

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.


Table2.4

:Com

parisonofW

ebV

ideoconferencingSystem

s

Plug-inM

ultipleU

sersM

obileR

ecordA

rch.D

esktopSharing

Slideshow

White-

boardA

PIO

pensource

Google

Hangouts

44

(limited)

47

Distributed

44

44

7

TokBox

4

(Flash)4

?4

(non-free)

Distributed

&C

entralized7

77

47

FlashM

eeting4

(Flash)4

(turns)7

4C

entralized7

47

77

Big

Blue

Button

4

(Flash)4

(turns)4

(Android)

4C

entralized4

47

74

GoToM

eeting4

(Flash)4

(limited)

4

(audioonly)

4C

entralized4

47

74

Cisco

WebE

X

4

(Flash-

audioonly)

4

(limited)

44

Centralized

44

77

7

EV

O4

(Java)4

(limited)

74

Centralized

47

47

7

OpenM

eetings4

(Flash)4

77

Centralized

47

47

4

Vyew

4

(Flash)4

74

Centralized

44

47

7

Vokle4

(Flash)4

74

Centralized

77

77

7

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 define the operations of this interface; section 3.7 describes the

designed security mechanism to authenticate requests to the user interface; and, finally, 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. Specifically it tries to overcome the first 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 flexible 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 find 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 efficient

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


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 first 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 first 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 identifier

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

1) POST /open/1 HTTP/1.1Content-Type: app/x-fcs →

HTTP/1.1 200 OKContent-Type: app/x-fcs

<sid>

2) POST /idle/<sid>/<seq> HTTP/1.1Content-Type: app/x-fcs →

HTTP/1.1 200 OKContent-Type: app/x-fcs

<data>

3)POST /send/<sid>/<seq> HTTP/1.1Content-Type: app/x-fcs

<data>

→HTTP/1.1 200 OKContent-Type: app/x-fcs

<data>

4) POST /close/<sid>/ HTTP/1.1Content-Type: app/x-fcs → HTTP/1.1 200 OK

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/<sid>/<seq>,

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 traffic 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 difficult, and it would complicate the implementation of desktop sharing and of a open

system (this objective will be discussed later).


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 flexibility and

3.4. VIDEOCONFERENCING AND CLOUD COMPUTING 71

scalability. For this purpose we tend to create open source applications, which could be easily

modified 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 modifies 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 flexibility: the architecture is flexible, so it can adapt and scale itself

depending on the number of users. In the present version of Nuve, this property is not yet


implemented, but in the future, Nuve offers scalability and flexibility 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 configurable 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, flexible, 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 Definition

Users It represents the third parties’ users who will communicate withothers 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 andgive users access to communicate in each of these rooms.

Rooms They are the virtual spaces where the users will collaborateamong 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


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 define 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 define 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

http://www.json.org


Flex Application

RTMP Server

User Access Controller

Marte API

User Access Controller

REST Security Filter

Nuve

User

Token consumer

Room Manager

/roomUser Token

/user/token

Service Manager

/service

ServicePO

ST

/token

#to

ken

Marte

Instance

Connect(#

token

)

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/<id>/user/<username>, being id the room identifier

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:

/room/<id>/user/<username>

3.6. NUVE API 77

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

The response would have the next structure:

HTTP/1.1 200 OKContent-Type: application/xmlContent-Length: 60[CRLF]<user>

<username>Bob</username><role>participant</role><status>online</status>

</user>

Furthermore, we could also ask for the entire list of connected users by sending a GET

command to the URL /room/<id>/user/. We could even throw a user out from the room by

sending a DELETE message to /room/<id>/user/<username>.

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.

/room/<id>/user/

/room/<id>/user/<username>


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/<id> 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:

<noscript><object id="MarteRoom" ><param name="movie" value="Marte.swf"/><param name="quality" value="high"/>...<embed src="Marte.swf"quality="high"type="application/x-shockwave-flash"...play="true"/></object></noscript>

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 first 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.1Content-Type: application/jsonContent-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 PermanentlyContent-Type: application/jsonContent-Length: 26Location: /room/MyRoom[CRLF]"room":"name":"MyRoom"

As we see in this example, the response in REST models is a message of the type

/room/

/room/<id>

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 first 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/<service_id>). 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 first two ones.

Below is an example of a service described in XML format:

<service><name>Facebook</name><id>123okopwqeop21893</id><key>u94832er893wjhr893j98</key>

</service>

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,

/room/MyRoom

/service

/service/<service_id>


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 define 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 identifiers 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.1Content-Type: application/xmlContent-Length: 63[Security info][CRLF]<token>

<username>Bob</username><role>participant</role>

</token>

When the server receives this request, Nuve creates a new unique identifier 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 4 7 7 4

/room 4 4 4 4

/token 7 4 7 7

/service 4 4 7 4

HTTP/1.1 301 Moved PermanentlyContent-Type: application/xmlContent-Length: 26Location: /room/MyRoom/token/123p2j13io21[CRLF]<token>

<username>Bob</username><role>participant</role><id>123p2j13io21</id>

</token>

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.

/user

/room

/token

/service


Table 3.4 : HTTP methods used for HTML contents

GET POST PUT DELETE

/user 4 7 7 4

/room 4 7 7 4

/token 7 7 7 7

/service 4 7 7 4

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 workflow.

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

/user

/room

/token

/service

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 workflows. According to this, I reach the basic conclusion that in a context of

videoconferencing where the usual workflow 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/

http://aws.amazon.com/s3/

http://oauth.net/


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 first 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 identifier 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 specified, 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.


• 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 defines 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 flow 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.1Host: 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 UnauthorizedWWW-Authenticate: MAuth,

realm="marte3.dit.upm.es"

Now, the service knows that Nuve uses MAuth to authenticate requests and must fill in every

parameter to have its request approved and processed:

GET /rooms HTTP/1.1WWW-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 workflow followed after conference creation.

Web Browser Third Party Service Nuve Auth Service Nuve Conference Service

#token

Token Request for #user in #roomAccess Request

#token

Marte Client

Connect with #token

Connected

Init with #token

Check #token

Ok for #user in #room

Marte

Initialization

Auth Check

Auth Check

Room

update

7

1 2

345

6

8

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 identified himself in the context of the service.


2. The service issues a request to Nuve asking for access to the conference for that specific

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 finally 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


Is a user

connected?

OK

Delete Room

Delete User

from RoomYes

Delete Service

Has any

room?

No

Yes

No

Figure 3.3 : Service Deletion Programming Logic

the bandwidth consumption I show different figures 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:

BWtotal = N2users ·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

0 1 2 3 4 5 6 7 80

100

200

300

400

500

600

700

800

900

1000

Number of Users

Kil

obyte

s per

sec

ond

Real Data

Theoretical Data

(a) Bandwidth consumed by audio

0 1 2 3 4 5 60

100

200

300

400

500

600

700

800

900

1000

Number of Users

Kil

ob

yte

s p

er s

eco

nd

Real Data

Theoretical Data

(b) Bandwidth consumed by audio and video

0 2 4 6 80

10

20

30

40

Number of Users

Per

cen

tag

e o

f C

PU

(c) Percentage of CPU consumed by audio

0 1 2 3 4 5 60

10

20

30

40

Number of Users

Per

cen

tag

e o

f C

PU

(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:

BWtotal = N2users · (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 figure 3.4c we see how the percentage of CPU consumed varies in an audio conference,

while in figure 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:


BWtotal = ∑i

BWRoomi = ∑i

N2users f romi · (BWaudio +BWvideo) (3.3)

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, unmodified, 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 benefits 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 first

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.


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 find

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.comiihttp://flashmeeting.open.ac.uk/home.html

iiihttp://www.youtube.comivhttp://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 defined 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:


Scheduler

Executor

VNC

REST API

Master

GW

Flash

GW

SIP

App Handlers

Amazon EC2

VMWare

OCCI

Cloud Handlers

- Cloud type- Machine type

Machine tags

Start

Event

Stop

Event

Start

Session

Stop

Session

Jobs

Amazon EC2

VMWare

OpenNebulaEucalyptus

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 first requesting creation of such event and then creation of all of its sessions,

one by one.

In figure 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

id

events

id

sessions

streaming

web

player

Figure 4.2 : Conference Manager REST API

Table 4.1 : HTTP methods used for XML resources

GET POST PUT DELETE

/events 4 4 7 7

/events/eid 4 7 4 4

/events/eid/sessions 4 4 7 7

/events/eid/sessions/sid 4 7 4 4

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:

/events

/events/eid

/events/eid/sessions

/events/eid/sessions/sid


<event><id>eventID</id><name>eventName</name><type>

[conference, meeting, class]</type><enable-web>[true, false]</enable-web><enable-sip>[true, false]</enable-sip><enable-isabel>[true, false]</enable-isabel><web-url>http://web</web-url><sip-url>sip://sip</sip-url><isabel-url>

isabel://isabel</isabel-url>

</event>

An event representation gives information about its identifier, 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:

<session><id>sessionID</id><record>[true, false]</record><streaming>[true, false]</streaming><name>sessionName</name><initDate>

2010-02-01 18:00:00</initDate><endDate>

2010-02-01 19:05:00</endDate>

</session>

In this case the representation will offer information about the session identifier 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 first 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 specific configuration. 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:


Algorithm 1 Start Event Job AlgorithmRequire: eventId

1: event = DB.getEvent(eventId)2: machines = new MachineSet()3: for all machine in VMs needed do4: cloudHandler.instantiateVM(machine)5: machines.add(machine)6: end for7: ... wait until machines are ready ...8: Initialize machines.getMaster()9: Initialize machines.getRecorder()

10: Configure machines.getVNC()

1. Retrieval of the event configuration 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

configuration 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 configuration from the database. It is useful choose and get the

machine which will be terminated (line 1).

2. Reconfiguration 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 AlgorithmRequire: eventId

1: event = DB.getEvent(eventId)2: machines = new MachineSet()3: for all machine in event do4: if machine is VNC then5: Set default VNC configuration for machine6: end if7: cloudHandler.terminateVM(machine)8: end for

Algorithm 3 Start Session Job AlgorithmRequire: sessionIdEnsure: sessionId belongs to an Event

1: session = DB.getSession(sessionId)2: if session is Recording then3: Start Recording session4: 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 figure 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 AlgorithmRequire: sessionIdEnsure: sessionId belongs to an Event

1: session = DB.getSession(sessionId)2: if session is Recording then3: Stop Recording session4: end if


Control Operations

Audio and Video Stream

File access

Metadata Stream

Disks

Conference Manager

Red5Master

Recording

IST

VNCGW Web

IST

GW SIP

IST

SER

VCC / Global Plaza

Isabel

Machine

VenusRecorder

Player

Editor

Venus REST

Gateway

DST

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.


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 file 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


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.


(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 flexible 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 find 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 significant 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 significant 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 find 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 first

measurements of the cloud provider network, that is the first 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/


• 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 sufficient 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

Iperf Server

Iperf Client

Amazon

AP-Southeast-1

Amazon

US-East-1

Amazon

EU-West-1

ping

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 sufficient 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 finish 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 traffic 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


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, Wifi, etc. Thus, any streaming service must allow configuration 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


because applications usually implement buffers for incoming data that transforms the variable

jitter into fixed 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 overflow 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 figure 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.


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 configuration 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 figures 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 finally Round

Trip Time (RTT) graph indicates CDF of the round trip time delays between two nodes in different

regions.


106

107

108

0

0.2

0.4

0.6

0.8

1

Bandwidth

bits/second

CD

F

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.5

1

Jitter

ms

CD

F

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

x 10−4

0

0.5

1

Loss

%

PD

F

90 92 94 96 98 100 102 104 106 108 1100

0.2

0.4

0.6

0.8

1

RTT

ms

CD

F

Incoming

Outgoing

Figure 5.2 : Measurement results between datacentres EU-US

Measurements between regions

Figure 5.2 represents the measurements between Europe and USA regions, figure 5.3 represents

the measurements between Europe and Asia regions, and figure 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


106

107

108

0

0.2

0.4

0.6

0.8

1

Bandwidth

bits/second

CD

F

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.5

1

Jitter

ms

CD

F

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

x 10−4

0

0.5

1

Loss

%

PD

F

260 265 270 275 280 2850

0.2

0.4

0.6

0.8

1

RTT

ms

CD

F

Incoming

Outgoing

Figure 5.3 : Measurement results between datacentres EU-AP


106

107

108

0

0.2

0.4

0.6

0.8

1

Bandwidth

bits/second

CD

F

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.5

1

Jitter

ms

CD

F

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

x 10−4

0

0.5

1

Loss

%

PD

F

240 245 250 255 260 2650

0.2

0.4

0.6

0.8

1

RTT

ms

CD

F

Incoming

Outgoing

Figure 5.4 : Measurement results between datacentres US-AP


Asia Europe USA

PROCESSING

ENGINE SOURCE

PlanetLab

node

Cloud

instance

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 efficient 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 traffic.

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 a2007 Intel Xeon CPU.


1 2 3 4 5 6 7 8 9

0

2000

4000

PlanetLab nodes

Jitt

er (

ms)

high rate medium rate low rate

Figure 5.6 : Jitter experienced when sending streams to Amazon EC2

0 50 100 150 200 2500

100

200

300

Application−Level Round−Trip Time (ms)

Net

wor

k−Le

vel

Rou

nd−

Trip

Tim

e (m

s)

idealamericaasiaeurope

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.


0

50L

aten

cy(m

s)

Day 1 Day 2

7 8 9 101112131415161718190

2

x 104

Th

rou

gh

pu

t(t

up

les/

s)

Time of day, 24−hour format7 8 9 10111213141516171819

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/

http://esper.codehaus.org/


1 3 5 7 9 11 13 15 170

0.20.40.60.8

11.21.41.61.8

2x 10

5

Input Data Rate − x10000 tuples/s

Thro

ughput

− t

uple

s/s

Small VM instances

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

Large VM instances

Figure 5.9 : Increase in throughput with different instance sizes on Amazon EC2 (Differentshades/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


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 significantly. 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 trade-

offs 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 traffic, in order to compare

the results to the actual requirements of a multimedia transmission in terms of QoS. In the first

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 fill a gap in

sequence numbers. It is considered to be âAIJin timeâAI if it arrives in the same interval.


• 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:

σ2 =

1Ni−1 ∑

Ni

j=2(IPG j(i)−E[IPG(i)])2

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 figure

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

Norway

USA-1 France Taiwan

Puerto

RicoUSA-2

Brazil

Italy Germany

Spain

Japan China

Korea

1

2

3

4

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


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


are always sufficiently 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

specifics 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, N′, 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 DSPSRequire: totalInRate, N, maxRatePerVMEnsure: N′ s.t. projRatePerVM ∗N′ = totalInRate

1: expRatePerVM = btotalInRate/Nc2: totalExtraRateForVMs = 0; totalProcRate = 03: for all deployed VMs do4: totalExtraRateForVMs+=expRatePerVM-getRate(VM)5: totalProcRate+=getRate(VM)6: end for7: avgRatePerVM = b(totalProcRate/N)c8: if totalExtraRateForVMs > 0 then9: N′ = N + d(totalExtraRateForVMs/avgRatePerVM)e

10: maxRatePerVM = avgRatePerVM11: else if totalExtraRateForVMs < 0 then12: N′ = dtotalInRate/maxRatePerVMe13: end if14: projRatePerVM = totalInRate/N′

15: return N′

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 N′, 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).


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 file. 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 significant 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 benefits 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 efficiently improved by deploying part of the architecture inside Cloud networks. This


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.


0

20

40

60

80

100

120

Milliseconds

Figu

re5.

11:T

he99

.7th

perc

entil

eof

jitte

rin

each

scen

ario

05

10

15

20

25

30

MBytes received every 400 seconds

Figu

re5.

12:B

ytes

rece

ived

inea

chsc

enar

io

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Number of packets

Figu

re5.

13:P

acke

tlos

ses

inea

chsc

enar

io


Figure 5.14 : Elastic DSPS with query partitioning across processing VMs

100 200 300 400 500 600 7000

0.5

1

1.5

x 105

Tuple

s/se

c

Time (sec)

100 200 300 400 500 600 700

1

2

3

4N

um

ber

of

VM

sInput Rate Tuples dropped Number of nodes

(a) Small EC2 instances

100 200 300 400 500 600 7000

1

2x 10

5

Tu

ple

s/se

c

Time (sec)

100 200 300 400 500 600 7000

1

2

Nu

mb

er o

f V

MsInput Rate Tuples dropped Number of nodes

(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 fit 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 first 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 specific

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:


• CPU intensive modules. Parts of the application that consume most of the CPU cycles

needed to provide a service. In this case I identified 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 specific 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, traffic 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

BWin(j,1)

BWin(j,2)

BWout(j,2)

BWout(j,1)

Cst(Xi)

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

Ccpu(j,Xi)

BWst(j)

Ctr-in(1,Xi) Ctr-out(2,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 = ∑i∈bw,cpu,stor

Ccpu(Xi)+Cbw(Xi)+Cstor(Xi) (6.1)

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) = ∑j

Ccpu( j,Xi) t (6.2)

This formula along with the following ones complies with figure 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


of hours that are going to be considered.

Cbw(Xi) = 3600 t ∑j∑k

Cint( j,k,Xi) (6.3)

Formula 6.3 is the result of adding together all costs generated from different traffic sources

in each j node of Xi Cloud provider. In this case I assume the constant 3600 because traffic 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) = ∑j

3600 t Cst(Xi)BWst( j) (6.5)

Finally, formula 6.5 is related to the storage costs of each j node of Xi Cloud provider. Here

I have defined the storage as a constant data flow saved on virtual disks. Next, I have introduced

BWst as the rate (per second) at which the data is stored in the disk.


Transcoder (high CPU)

Web Server (medium CPU)

Recorder (medium CPU)

a

b

c

d

e

f a) BWweb-in

b) BWweb-out

c) BWweb-in

d) BWweb-video

e) BWweb-video

f) BWweb-video

Xweb Xtr Xrec

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


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 minNweb−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 first 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 traffic must be considered internal, which in

general presents lower prices.

For calculation we can replace the values of bandwidth streams (BWin, BWout , etc.), figure 6.1,

with the corresponding ones in scenarios represented on figure 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


0 10 20 30 40 50 60 70 80 90 100−40

−20

0

20

40

60

80

100Cost Differences with Hybrid Clouds

%

Number of users

Hybrid Cloud

CloudSigma

AmazonEC2

RackSpace

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

find 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


in which this system was used and finally I trace the way for future research directions that can be

motivated from this work.

6.4 Test scenarios

I have established five 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 first 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

- !

0,10 !

0,20 !

0,30 !

0,40 !

0,50 !

0,60 !

0,70 !

0,80 !

0,90 !

1,00 !

Multiple videos VNC with video VNC with slides VGA with video VGA with slides

OUT

IN

CPU

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 five 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


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 confirm 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 benefit 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 scientific

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 benefits, 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

ChangeConferenceMode

GetMarteUsersPIDAndStatus

DisconnectParticipant GetParticipantInfo

GetConferenceInfo GetMarteUsersPID

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 defined 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 first 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âAI, 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 identified 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.


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, Office, 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 traffic

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.


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 figure 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 figure 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/

http://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


0

50

100

150

200

250

300

350

400

450

Cu

mu

lati

ve

Ev

ents

0

20

40

60

80

100

ene-

09

feb-0

9

mar

-09

abr-

09

may

-09

jun-0

9

jul-

09

ago-0

9

sep-0

9

oct

-09

nov-0

9

dic

-09

ene-

10

feb-1

0

mar

-10

abr-

10

may

-10

jun-1

0

jul-

10

ago-1

0

sep-1

0

oct

-10

nov-1

0

Ev

ents

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/

http://www.jasig.org/cas/

7.2. VALIDATION IN NATIONAL PROJECTS 157

0

100

200

300

400

500

600

700

800C

um

ula

tiv

e V

ideo

s

0

50

100

150

200

250

ene-

09

feb-0

9

mar

-09

abr-

09

may

-09

jun-0

9

jul-

09

ago-0

9

sep-0

9

oct

-09

nov-0

9

dic

-09

ene-

10

feb-1

0

mar

-10

abr-

10

may

-10

jun-1

0

jul-

10

ago-1

0

sep-1

0

oct

-10

nov-1

0

Vid

eos

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, figure 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.


SE

RV

ER

CL

IEN

T

User Interface (Flex)

Marte/Nuve Client

Module

Collaboration Handler

Module

Authentication

Module

Marte/Nuve Server Collaboration Handler ServerAuthentication 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 figure 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


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


UPM

Global Plaza

Conference Manager

Isabel

Hardware Kit

Faculties at UPM

ETS

Telecommunications

Engineering

ETS Agronomics

Engineering

ETS Civil

Engineering

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


• 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.


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 significantly 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Ãsn e InformaciÃsn para 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.


Chapter 8

Conclusions

Implementation of real-time multimedia systems, and specifically 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 fit 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 identified 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 findings 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 finally 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.


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.

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 benefits when used as a

core of a multimedia streaming service.

The first conclusion of this work was that the QoS of a streaming service can be efficiently

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 benefit 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:

• CPU intensive modules. Parts of the application that consume most of the CPU cycles

needed to provide a service. In this case I identified 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 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


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

fluctuating 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, unmodified,

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 first 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 benefits 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 significant conclusion is that the QoS of a real-time

multimedia service can be efficiently 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


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.

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

cloud-based videoconferencing architecture.

• 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 efficiently. There are many

systems that can benefit 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 benefit 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 specifically videoconferencing

applications, W3C and IETF are currently working on the specification 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


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 specification 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-configuration

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 notification. 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.


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 Verification 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 Griffith, 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-Pacific, 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-Pacific,

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. Specifications 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-benefit 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-

Efficient 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

Configurable 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.

[Garfinkel 2007] Simson L. Garfinkel. 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 Vafiadis, 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 flexible 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 Profile 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 beneficial 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 Scientific Workflows. 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)

Specification, June 2009.

[Independent 1934] The Evening Independent. German Post-Office 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. Conflicting 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 Definition 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 Efiie 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 flexible 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. Specification 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 definition. 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.

Documents

UNIVERSIDAD POLITÉCNICA DE MADRIDaparació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