Deliverable D1.2 Report On of Cloud Service Classifications and Scenarios

Seventh Framework STREP No.
317846
D1.2 - Report on Cloud Service Classifications and Scenarios

Public
Socially-aware Management of New Overlay Application Traffic with Energy Efficiency in the Internet
European Seventh Framework Project FP7-2012-ICT- 317846-STREP
Deliverable D1.2 Report on of Cloud Service Classifications and Scenarios
The SmartenIT Consortium

Universitt Zrich, UZH, Switzerland Athens University of Economics and Business - Research Center, AUEB, Greece Julius-Maximilians Universitt Wrzburg, UniWue, Germany Technische Universitt Darmstadt, TUD, Germany Akademia Gorniczo-Hutnicza im. Stanislawa Staszica w Krakowie, AGH, Poland Intracom SA Telecom Solutions, ICOM, Greece Alcatel Lucent Bell Labs, ALBLF, France Instytut Chemii Bioorganicznej PAN, PSNC, Poland Interoute S.P.A, IRT, Italy Telekom Deutschland GmbH, TDG, Germany
Copyright 2013, the Members of the SmartenIT Consortium

For more information on this document or the SmartenIT project, please contact: Prof. Dr. Burkhard Stiller Universitt Zrich, CSG@IFI Binzmhlestrasse 14 CH8050 Zrich Switzerland Phone: +41 44 635 4331 Fax: +41 44 635 6809 E-mail: info@smartenit.eu
Version 1.5
Page 1 of 95

Public
Seventh Framework STREP No. 317846
Document Control
Title: Type: Editor(s): E-mail: Author(s): Description of cloud and overlay service classifications and final scenario development Public Matteo Biancani, Paolo Cruschelli matte.biancani@interoute.com, paolo.cruschelli@interoute.com Matteo Biancani, Alessandro Predieri, Matthias Wichtlhuber, Fabian Kaup, Sergios Soursos, George Petropoulos, Michael Seufert, Tobias Hofeld, Valentin Burger, Sylvaine Kerboeuf, Sabine Randriamasy, Thomas Bocek, Corinna Schmitt, Burkhard Stiller, Gerhard Halinger, Roman Lapacz, Krzysztof Wajda, Rafal Stankiewicz, Grzegorz Rzym, Mateusz Wielgosz, Ioanna Papafili, Manos Dramitinos, George D. Stamoulis. D1.2-v1.5
Doc ID:
AMENDMENT HISTORY
Version
V0.1 V0.2 V0.3 V0.4 V0.5 V0.6 V0.7 V0.8 V0.9 V0.10 V1.0 V1.1 V1.2 V1.3 V1.4 V1.5
Date
May 13 2013 Jun 7 2013 Jun 13 2013 Jun 1 2013 Jul 4 2013 Jul 18 2013 Jul 20 2013 Jul 20 2013 July 22 2013 July 29 2013 July 31th 2013 August 23 2013 August 30 2013 Sept 24th 2013 Oct 01 2013 October 24th 2013
th th th
Author
IRT IRT IRT IRT IRT IRT IRT IRT IRT IRT IRT IRT IRT IRT IRT IRT
Description/Comments
First table of content Minor changes on template for scenario definition Input from different partners Minor changes in Document structure Partners contribution Partners contribution Partners contribution Partners contribution TUD, IRT contributions UniWue, AUEB contributions AGH AUEB UNIWUE contributions Comment from Document editor to various sections. Integrated comments from partners (UniWue, AUEB), changes to section 4 Partners contribution to sec 4 and sec 5 Comments solved by partners. Deliverable ready for internal review. Final version ready for EC submission
Legal Notices The information in this document is subject to change without notice. The Members of the SmartenIT Consortium make no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of the SmartenIT Consortium shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Page 2 of 95
Version 1.5

Public
Table of Contents
1 Executive Summary 2 Introduction 3 Cloud Service Classification Relevant to SmartenIT
3.1 3.2 Methodology for Cloud Service Classification in SmartenIT Cloud Applications Survey Results 3.2.1 Service Relevance Survey Results 3.2.2 Application Relevance Survey Results Methodology for Cloud Scenarios Definition and Analysis Template for Scenario Definition General Aspects Common to SmartenIT Scenarios 4.3.1 General Aspects for the Definition of SmartenIT Scenarios Inter-cloud Communication 4.4.1 Scenario Overview 4.4.2 Interaction between Actors 4.4.3 Financial Configuration 4.4.4 Technical Issues 4.4.5 State-of-the-art Limits 4.4.6 SmartenIT Innovation Global Service Mobility (User Mobility) 4.5.1 Scenario Overview 4.5.2 Framework Definition 4.5.3 Interaction between Actors 4.5.4 Financial Configuration 4.5.5 Technical Issues 4.5.6 State-of-the-art Limits 4.5.7 SmartenIT Innovation Exploiting On-line Social Networks Information Social Awareness 4.6.1 Scenario Overview 4.6.2 Framework Definition 4.6.3 Interaction between Actors 4.6.4 Financial Configuration 4.6.5 Technical Issues 4.6.6 State-of-the-art Limits 4.6.7 SmartenIT Innovation Collaboration for Energy Efficiency 4.7.1 Scenario Overview 4.7.2 Interaction between Actors 4.7.3 Financial Configuration 4.7.4 Technical Issues 4.7.5 State-of-the-art Limits 4.7.6 SmartenIT Innovation SmartenIT Scenario Consolidation and Final Refinement 4.8.1 Operator-Focused Scenario 4.8.2 End- user-focused Scenario Current Trends of Network Traffic Measurement Mechanisms, Information Sources, and Tools 5.2.1 Mechanisms 5.2.2 Tools 5.2.3 Dedicated Measurement Devices 5.2.4 PERFAS: A Network-wide Performance Monitoring System 5.2.5 Information Sources Measurement Requirements
7 9 11
11 14 14 15
4 SmartenIT Scenarios Definition

4.1 4.2 4.3 4.4
18
18 19 19 19 22 23 27 29 31 32 33 33 34 37 38 40 41 43 44 44 45 47 48 49 49 50 51 52 53 56 57 58 58 58 59 62 64
4.5
4.6
4.7
4.8
5 Traffic Trends and Analysis

5.1 5.2
66
67 69 69 70 77 77 79 80
5.3
Version 1.5
Page 3 of 95

Public
5.4 5.5 6.1 6.2
Relation of Traffic Measurements and Analysis to Scenarios Relation of Measurements and Analysis to Architecture Modules Key Outcomes and Lessons Learnt Next Steps
81 82
6 Summary and Conclusions
85
85 87
7 SMART Objectives Addressed 8 References 9 Abbreviations 10 Acknowledgements
88 91 93 95
Tables
Table 3-1: Technical characteristics for cloud service classification. .............................................12 Table 3-2: Non-technical characteristics for cloud service classification. ......................................12 Table 3-3: Results of the service relevance survey. .......................................................................14 Table 3-4: Mean ratings of Video / Music on Demand. ................................................................16 Table 3-5: Mean ratings of File Storage / File Sharing applications. ...........................................17 Table 4-1: Relevant SLAs with SmartenIT framework. ..................................................................21 Table 4-2: Bandwidth and Latency demand for different type of cloud applications ......................22 Table 4-3: Template instantiation for inter-cloud communication scenario. ...................................24 Table 4-4: Template instantiation for Global Service Mobility scenario. ........................................34 Table 4-5: Stakeholder's Interests. .................................................................................................39 Table 4-6: Template instantiation for Social Awareness scenario..................................................45 Table 4-7: Template instantiation for Collaboration for Energy efficiency scenario. ......................53 Table 4-8: Key issues and relevant feature of SmartenIT initial scenarios. ...................................60 Table 4-9: Key issues and relevant feature of SmartenIT final scenarios. .....................................61 Table 5-1: Accuracy of time synchronization methods between measurement agents. ................79 Table 5-2: Traffic measurements related to scenario. ....................................................................82 Table 6-1: Mapping of key feature to the final SmartenIT scenarios. .............................................86 Table 7-1: Overall SmartenIT objectives addressed. .....................................................................88 Table 7-2: Specific SmartenIT objectives addressed. ....................................................................88
List of figures
Figure 4-1: Evolution from Single Cloud to Inter-cloud scenario. ...................................................23 Figure 4-2: Scenario Overview of Stakeholders and types of mobility. ..........................................34 Figure 4-3: Illustration of types of service mobility .........................................................................37 Figure 4-4: Offered services and service purchases. .....................................................................41 Figure 4-5: Service Placement Algorithm. ......................................................................................42 Figure 4-6: Social awareness scenario for file storage and video on demand...............................45 Figure 4-7: Collaboration for energy efficiency scenario. ...............................................................52 Page 4 of 95
Version 1.5

Public
Figure 4-8: Collaboration within Datacenter Operators Federation (focus on network layer). .......53 Figure 5-1: Projection of Mobile Access Network Traffic in the United States [46]. .......................67 Figure 5-2: Composition of IP traffic in Europe in fixed (left) / mobile (right) networks [46]. ..........68 Figure 5-3: D-ITG architecture. .......................................................................................................71 Figure 5-4: Tstat: a) monitoring probe setup, b) analysis workflow [25]. ........................................72 Figure 5-5: Tstat: example results. .................................................................................................73 Figure 5-6: CoralReef architecture [28]. .........................................................................................74 Figure 5-7: CoralReef example outcome (1 day analysis) [31]. .....................................................74 Figure 5-8: Blinc FTP graphlet [32]. ................................................................................................75 Figure 5-9: Popular cloud applications ...........................................................................................76 Figure 5-10: PERFAS Measurement tool set with control station and distributed agents. ............78
Version 1.5
Page 5 of 95

Public
(This page is left blank intentionally.)
Page 6 of 95
Version 1.5

Public
1 Executive Summary
This document is the deliverable D1.2 Report on Cloud Service Classification and Scenarios of Work Package 1 Traffic Measurements and Scenario Definitions within the ICT SmartenIT Project 317846. The objectives of this deliverable are summarized as follows: Cloud service classification, comprising cloud application survey and used methodology. Traffic measurement and analysis to provide a characterization of traffic and demands of cloud based applications and services. Moreover the impact of traffic measurements on SmartenIT architecture are outlined with detailed analysis with relevant SmartenIT solution modules. Full scenario description, stakeholder identification, investigation of their technical and business dependencies and interactions, analysis of the potential benefit in terms of traffic and cost optimization of their cooperation, incentives to be provided to each stakeholder to achieve cooperation.
Concerning the first objective, its main aim is to provide a classification of Cloud services and applications that are relevant within the SmartenIT framework. The most common and most popular cloud services have been analyzed, classified and ranked to be positioned w.r.t. SmartenIT project main interests and needs. One of the main outcomes of this objective is the identification of applications/services to be used to characterize the SmartenIT scenarios. The second objective is to report on recent trends in traffic monitoring and analysis, to overview most common approaches and concepts related to traffic monitoring and to propose most practical approaches and open-source applications to performs raw data traffic analysis for SmartenIT needs. Trends for global IP traffic will also be presented. Moreover, traffic monitoring requirements for each SmartenIT scenario are identified. A brief overview of SmartenIT components for traffic monitoring is given and their potential deployment in the SmartenIT ecosystem is discussed. The third objective is the complete and detailed description of those scenarios considered relevant for the SmartenIT project. A scenario is defined according to the SmartenIT Description of Work (DoW) [51]: A scenario is an overall outline of real world actions and events occurring during an interaction with the underlying SmartenIT system. It describes the general behavior of all system mechanisms and enables the identification of challenges and problems to be solved in order to achieve desired functionality. The three scenarios identified within the DoW (sec. B1.1.2.2. Project Scenarios) plus the fourth scenario defined after partner proposal can be identified in the following: 1. Inter-cloud communication scenario (focusing on the issues related to the traffic generated in a multi-domain environment where different parties interests i.e. Data Center operator and Internet Service Provider collides)
Version 1.5
Page 7 of 95

Public
2. Global Service Mobility (focusing on Cloud Application Provider issues when trying to ensure proper service mobility with no QoE degradation) 3. Exploiting online social Networks Information Social awareness (focusing on how to exploit social awareness information to operate cloud traffic management) 4. Collaboration for Energy efficiency (focusing on inter-Data Center interaction driven by energy efficiency issues) All SmartenIT scenarios are described, starting from the general definition as outlined within the SmartenIT DoW, with a top-down approach by identifying at first common macro categories grouping general aspects required for the scenario characterization: each macro category has been further specialized to allow for a complete and exhaustive characterization of the scenario. The characterization of the four SmartenIT scenarios has been driven by two main aspects: 1. Actors identification and their mutual relationship from a business point of view 2. Technical characteristics (in terms of requirements) and limitations pertaining to the different scenarios. After having identified overlapping features and synergies across scenarios, a final refinement of the scenario description is outlined and two final merged macro scenarios have been described. WP1 activities have developed the basis for SmartenIT future work. In particular, the use-cases and traffic management solutions will be concretized in WP2 based on the two macro-scenarios, respectively. Traffic management solutions as described in D2.2 already consider those two macro-scenarios. Use cases will be defined in the upcoming D2.3. The SmartenIT architecture being developed in WP3 will consider the traffic measurement tools as analyzed in D1.2 and will ensure proper deployment modalities tailored on the macro-scenarios identified across this deliverable.
Page 8 of 95
Version 1.5

Public
2 Introduction
Cloud computing can be seen as a metaphor for the Internet: an abstraction of the complex infrastructure it conceals. It stands for a style of computing in which IT-related (Information Technology) capabilities are provided as a service, allowing users to access these services from the Internet without knowledge of, expertise in, or control over the technology that supports them. In this context, the terms Software -as-a-Service (SaaS) or Internet of Services are also used. Cloud computing has generat ed much interest recently and developments in this space are quickly ramping up. However, the successful evolution of Cloud infrastructures and service offerings face complex multi-party technical, business and security requirements. From a different point of view Clouds are defined as [7], ...a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically configured to adjust to a variable load (scale), allowing also for optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guaranties are offered by the Infrastructure Provider by means of customized SLAs [Service Level Agreements]. The instantiation of Cloud computing is, thus, a complex task requiring many technical and business skills, as well as significant financial investments. Components include: the building and operation of vast Data Centers supporting the Clouds; high-capacity broadband networks of massively distributed computing systems; flexible service oriented architectures, supporting dynamic service composition and provisioning based on Web Services Security (WS Security) and other open standards; distributed information infrastructures and virtualization technology.
An additional layer of complexity is added by the fact that within the Cloud service landscape many actors are involved (Cloud Application Provider, Data Center Operator, Internet Service Provider, Social Networks information Provider, Energy Provider), each one offering different types of resources and infrastructure to finally compose the service that most of time is perceived in a transparent way by the final consumer. The rest of the document is organized as follows: Chapter 3 is dedicated to Cloud service classification. The main objective of the chapter is to provide a survey of cloud applications and service and operate a positioning within SmartenIT framework. Chapter 4 is dedicated to SmartenIT scenario definition. It shows the following structure: o Section 4.1: methodology for scenario definition, o Section 4.2: template for scenario analysis, o Section 4.3: aspects common to all scenarios description. o From Section 4.4 to Section 4.7 the four relevant scenarios are described in details.
Version 1.5
Page 9 of 95

Public
o Section 4.8 is dedicated to a final refinement of the scenario analysis, which after having identified commonalities and synergies across the scenarios, propose two final macro-scenarios that will be used for future WP2, WP3 and WP4 activities within SmartenIT project. Chapter 5 is dedicated to the analysis of traffic monitoring related features. It shows the following structure: Section 5.1: description of current trends of network traffic; Section 5.2: measurement mechanisms, sources of traffic information and tools for its acquisition, Section 5.3: requirements for data collection and analysis are gathered, Section 5.4 and Section 5.5: traffic measurements and analysis and its relationship with SmartenIT scenarios and architecture modules.
In Chapter 6, the main outcomes achieved are analyzed and discussed, possible risks are identified and SmartenIT innovation potential is evaluated as a way to overcome actual cloud scenario limitations. Finally, in Chapter 7 the SMART objectives achieved with this deliverable are identified.
Page 10 of 95
Version 1.5

Public
3 Cloud Service Classification Relevant to SmartenIT

The number of cloud service applications provided in the Internet is constantly increasing. To be able to focus on a manageable subset of applications to work on in SmartenIT, a cloud application survey has been conducted among the project partners. The purpose of the survey was to identify the services and concrete applications of these services which most relevant for SmartenIT, based on carefully selected criteria. The methodology adopted to identify and assess the different cloud characteristics consisted of two different steps. At first we classified the technical and non-technical aspects in order to identify two nearly orthogonal directions. Within the technical area we identified hardware and network requirements, traffic characteristics, service complexity and structuring (e.g., with or without caching, delay tolerant or not, etc.). In the non-technical area we assessed more societal aspects like popularity, target users base, user devices and mobility requirements. Then we proceeded with a survey among the SmartenIT partners to rank relevance, intervention potentials and expectations on the different characteristics. Our assessment was based on the research and commercial background of the SmartenIT partners, who represent a consistent European community of renowned network researchers, a global network equipment vendor and big network Data Center operators. Primary aim of this assessment process was to select the most relevant optimization areas in which new research interventions are needed and the SmartenIT project can contribute.
3.1 Methodology for Cloud Service Classification in SmartenIT

In Table 3-1 and Table 3-2 (which have been compiled after internal survey among SmartenIT partners) the technical and non-technical dimensions for the classification of cloud services are described. Nine major categories of overlay services have been qualitative evaluated, such as video/music on demand, e.g., YouTube, live video/HDTV/music, e.g., Netflix, video conferencing/VoIP, e.g., Skype, remote desktop, e.g., remote desktop for cloud platforms such as Windows Azure, collaboration, e.g., Google Docs, file storage/sharing, e.g., Dropbox, instant messaging, e.g., Viber, WhatsUp, gaming, e.g., Gaikai, and online social networks, e.g., Facebook, Concerning the technical characteristics of the overlay services examined, we have found that the services employing high quality video, either video on demand, live streaming or even gaming, have high requirements in terms of hardware, applications requiring interconnection of nodes geographically distributed, e.g., for real-time collaboration or to perform quick synchronization of files, are considered to have medium hardware requirements, while low quality video conferencing applications, as well as VoIP and instant messaging applications have the lowest requirements in terms of hardware of all overlay applications.
Version 1.5
Page 11 of 95

Public
Table 3-1: Technical characteristics for cloud service classification.

Technical Characteristics Hardware requirements Network requirements Degree of interactivity Service complexity Delay-tolerance
Traffic volume
Overlay Services Video/TV/music on demand Live video/TV/music streaming Video conferencing/VoIP Remote desktop Collaboration File Storage/File Sharing Instant messaging Gaming Online social networks High High Low Low Medium Medium Low High Medium High High High Low Low Low High Low High High High Low Medium Low High Medium Low Low High High Medium Low Medium High Medium Low Medium High Medium Low Low Low High Medium Low Low Low Low Medium High Medium Low High High Low Low Low Low High Low Low Medium
Medium Medium
Table 3-2: Non-technical characteristics for cloud service classification.

Non-Technical Characteristics Potential for Social Awareness Potential for Energy Efficiency Medium Medium High High High High High Low Medium Version 1.5
Overlay Services Video/music on demand Live video/HD TV/music streaming Video conferencing/VoIP Remote desktop Collaboration File Storage/File Sharing Instant messaging Gaming Online social networks High High Medium Low Low High Low Medium High Consumer Consumer Business/ Consumer Business Business Consumer Consumer Consumer Consumer Medium Medium Low Low Low High Low Medium Medium High High Low Low Low High High Medium High High High Low Low Low High Low Medium High
Page 12 of 95
Degree of Global Service Mobility
Degree of Inter-Cloud Communication
Target Customers
Popularity
Cache-ability

Public
Additionally, services generating high traffic volumes, e.g., video on demand, and real-time applications, or services that combine both characteristics, have strict requirements in terms of network conditions, while applications for inter-connection of nodes geographically distributed, e.g., remote desktop and collaboration applications are considered to have medium requirements; the remaining services are considered to have low network requirements. Specifically, regarding generated traffic volumes, apart from video-related services reported previously, which generate high volumes of traffic, online storage, remote desktop and online social networks are assumed to generate medium traffic volumes, while the remaining services, e.g. VoIP, instant messaging, etc. to produce low traffic volumes. Note that especially for online storage and online social networks traffic is expected to significantly increase in the near future [8]. Moreover, services requiring real-time interaction of geographically distributed nodes are those with highest system complexity, while live video streaming or online social networks seem to have medium complexity. Services such as video on demand, online storage and instant messaging are the simplest to deploy. Furthermore, real-time and video services such as live streaming, video conferencing, gaming, etc. are clearly not delay-tolerant, while real-time services which are less bandwidth-intensive are considered to be delay-tolerant in a medium level. Non-real-time applications such as file storage and online social networks are considered to be highly delay-tolerant. Finally, video on demand and file storage are considered to be highly cache-able, e.g., their data can be handled by a caching approach, while traffic generated by the remaining ones cannot be addressed by a caching solution. On the other hand, concerning non-technical characteristics, all video-related services, including file storage (e.g. emerging online storage applications such as Dropbox) and online social networks are found to be highly popular, followed by medium popular video conferencing/VoIP and gaming, and less popular applications for collaboration and remote desktop services. The popularity of these applications is directly related to their target group, e.g., services of high and medium popularity addresses mainly consumers (i.e., residential customers), while services of lower popularity address business customers. Regarding the degree of inter-cloud communication required to be established by each services, we identified that it is high mainly for file storage, while the degree of global service mobility and exploitability of social information, it is high for video streaming (both video on demand and live video), as well as file storage, online social networks and instant messaging. Moreover, concerning the energy efficiency pertained by each category of services, we identified that it is important in the Data Center/Cloud side for video streaming, gaming, collaboration, remote desktop and file storage, while it is significant in the mobile device side in instant messaging and VoIP. Nevertheless, it is highly important in both sides in the case of online social networks. Apart from well-established applications, we have also addressed some emerging ones, e.g., online storage, collaboration. The reason for addressing also some less known applications is the fact that they can constitute nice examples for evaluating traffic management mechanisms where intervention potential is higher than other well established proprietary applications where intervention may not be applicable. Summarizing the investigation conducted in this chapter, we have provided a description of the aforementioned applications from multiple viewpoints, in terms of their hardware, network and system requirements, as well as popularity, relevance to significant terms and approaches such as social awareness and energy efficiency, and their intervention
Version 1.5
Page 13 of 95

Public
potential. The identified characteristics will play a fundamental role and are provided as input to the next section of this document, in order to identify potential directions for optimization of the overlay applications and to estimate the expected gains thereof.
3.2 Cloud Applications Survey Results

The Cloud application survey was performed among the partners in two steps. The first step was a service relevance survey. Its goal was to identify the most relevant services for SmartenIT. In the second step most relevant applications were selected out of the most relevant service categories. 3.2.1 Service Relevance Survey Results For each service the relevance of 13 criteria was rated with a value from 1 to 5 for not relevant at all to very relevant for SmartenIT. The criteria were based on the categories from the cloud service classification (see Table 3-1 and Table 3-2), but also considered technical aspects of SmartenIT and future work in other WPs. The selected criteria were the following: optimization potential (QoE, traffic, energy), addressed scenario (inter-cloud communication, global service mobility, and social awareness), scientific and industrial impact, intervention potential (related to WP3), feasibility of theoretical analysis (related to WP2), feasibility of proof of concept in SmartenIT (related to WP4), popularity, and legal freedom. Additionally, the services were divided into services for end-users and service enabling technologies, i.e., technologies which are used for cloud services and thus are relevant for inter-cloud communication and energy efficiency scenarios. Table 3-3 shows the cloud services with highest sum over all criteria. For end-users most relevant services in the survey are File Storage and File Sharing and Video on Demand. For the service enabling technologies Data Centers are rated most relevant for SmartenIT. For each service the relevance of 13 criteria could be rated with a value from 1 to 5 for not relevant at all to very relevant for SmartenIT. The table shows the service sorted according to the sum over all criteria. The colour representation is an indicator of the value itself. Table 3-3: Results of the service relevance survey.
Page 14 of 95
Version 1.5

Public
3.2.2 Application Relevance Survey Results Based on the most relevant services File Storage and Video on Demand a subsequent survey on applications relevant for SmartenIT was conducted. The criteria were limited to 8 (see Table 3-4) to cover only the criteria which differ for the considered applications. Table 3-4 shows the results for the Video / Music on Demand applications. T he mean values over all partners are given for each criterion, as well as the sum over all criteria. The applications rated most relevant for SmartenIT were YouTube, iTunes, Maxdome and Telekom Entertain. The Video / Music on Demand application m ost relevant for SmartenIT is YouTube since it has the highest mean scores, is very popular and produces a high traffic volume. There are many applications like DailyMotion, Netflix or Vimeo which are not so popular. The problem with these applications is the limited intervention potential. The clients are based on html5 / flash player and are proprietary. Hence, it is hard to intervene by modifying the service with manipulating the client or server functionality without collaboration with the application provider, i.e. Netflix. Mechanisms that intervene in the network transparently like caching or pre-fetching might still be applicable for such applications. There are other applications which also show high mean scores, but were only filled by few partners. First application with a decent score but low significance is iTunes. The intervention potential might here also be rather low, since it is limited to the Apple universe. Second there is TV on demand applications like Telekom Entertain and Maxdome which gain a lot of popularity recently. However intervention potential is also low for these application, still Telekom Entertain is a product of one of the project partners. That could help to get an implementation of a developed mechanism in a running system. Out of scope for a SmartenIT solution are Video / Music on Demand applications are YouTube-like video streaming applications that are less popular, so are TV station media services which only reach a limited client based. Music on demand is popular but has a very little traffic volume compared to video applications.
Version 1.5
Page 15 of 95

Public
Table 3-4: Mean ratings of Video / Music on Demand.
Table 3-5 shows the results for the File storage, File sharing applications. The mean values over all partners are given for each criterion, as well as the sum over all criteria. The applications rated most relevant for SmartenIT were Dropbox, Google Drive, BitTorrent and PiCsMu. The File Storage application most relevant for SmartenIT is Dropbox since it has the highest mean scores, is very popular and produces a high traffic volume. The intervention potential of Dropbox is not expected to be high, but has still to be investigated. However, SmartenIT now also has the Dropbox Python sources reverse engineered according to [12]. Zettabox is an application similar to Dropbox which was developed by a project partner and has high intervention potential therefore. OwnCloud is an open source Dropbox clone and also gives the opportunity to modify a Dropbox like file storage application. Although BitTorrent got high scores in the survey it is very likely out of scope. It has already been addressed in the preceding project SmoothIT. The optimization mechanisms are already highly developed and the share of P2P traffic is less significant. However the peer-to-peer paradigm might gain re-importance for private or company peer-to-peer networks or for P2P assisted live streaming as addressed in B itTorrent Live. Furthermore the P2P technology might be utilized in a SmartenIT solution to assist content delivery networks and to reduce traffic asymmetry. PiCsMu is an application that builds on top of existing Cloud services, which was implemented by one of the SmartenIT partners. Therefore, it has a very high intervention
Page 16 of 95
Version 1.5

Public
potential. However, it exploits Cloud service terms of usage and this might not be accepted on a long term when heavily used by Cloud service providers. Google Drive also has very high scores, but has very limited intervention potential since it is a proprietary solution. Out of scope for a SmartenIT solution according to the scores in the survey are File Storage / File Sharing applications like file hosting, e-mail, Skype, Facebook, mobile personal assistants, generic apps / advertisement. In most cases they are not or no longer popular or their intervention potential is limited. Table 3-5: Mean ratings of File Storage / File Sharing applications.
In a subsequent phone conference on the survey all partners agreed to have YouTube and Dropbox as primary applications that represent the services Video on Demand and File Storage. If a modification of the client / server functionality is needed for a solution the corresponding Open Source implementations like Zeta-Box, PiCsMu, Owncloud for File Storage and VLC for Video on Demand may be used.
Version 1.5
Page 17 of 95

Public
4 SmartenIT Scenarios Definition

The definition of SmartenIT scenarios requires the selection of an appropriate methodology for those scenarios definitions and analysis, a respective template for their description, and space for the discussion of general aspects and relevant information.
4.1 Methodology for Cloud Scenarios Definition and Analysis

The definition of scenario is given according to SmartenIT Description of Work (DoW, [51]): A scenario is an overall outline of real world actions and events occurring during an interaction with the underlying SmartenIT system. It describes the general behavior of all system mechanisms and enables the identification of challenges and problems to be solved in order to achieve desired functionality. The analysis of the four scenarios relevant for SmartenIT project is a process that has been carried on in four different steps: 1. Scenario and use-cases concept definition 2. Template for scenario definition 3. Template instantiation and initial scenario description 4. Scenario refinement and final (macro-)scenario description The first steps main purpose is to outline the formal definition of scenario and use-case concepts, by creating a common understanding among all partners regarding the differences of the two areas. The final decision, as agreed by whole SmartenIT consortium, was to define the scenario in a generic way (tailored on SmartenIT needs) focusing on technical and business aspects driven by the mutual interaction among all actors defined in selected scenarios. The final scenario characterization should be comprehensive enough to contain the proper driven use-cases. The second steps main aim is the creation of a template to be used as a tool for the formal description of scenario. Such a template is intended as an operation tool to encompass all main characteristics of the scenario of interest. The template has been created with a top-down approach, starting from the general definition of scenarios as outlined within the DoW. With the top-down approach macro-categories have been created grouping homogeneous aspects relevant for the scenario, and each macrocategory has been more specialized within a subset of characteristics. The template for scenario description is described in details in the next chapter. The third steps main purpose is related to the detailed scenarios description by creating, for each of the four scenarios relevant for SmartenIT project, a complete and detailed template instantiation. For that purpose, partners have been grouped in four working groups, each one dedicated to the development of one scenario. The fourth step is related to the final refinement of the scenario analysis, which after having identified commonalities and synergies across the scenarios, propose two final macro-scenarios that will be used for future WP2, WP3, and WP4 activities within the SmartenIT project.
Page 18 of 95
Version 1.5

Public
4.2 Template for Scenario Definition

As outlined in the previous subchapter the template for the scenario description is an operational tool used to create a comprehensive description of the different scenarios. The four main scenarios (3 main scenarios as outlined in the DoW and one scenario as a result of partners proposition) relevant for SmartenIT framework show a common group of similar aspects but they differ in the final purpose, each one highlighting one or more key points of SmartenIT potential intervention. The template will be used to give a harmonized view of the scenarios themselves, highlighting similarities and focusing, when necessary on the relevant differences. The results obtained from the different scenario description will be used across Section 4.8 to achieve a scenario refinement. The following global aspects (or macro-categories) must be addressed to properly establish a characterization of each SmartenIT scenario: Framework definition: it includes a description of actors involved in the actual scenario, an overview of the services offered by involved Data Center Operators and a description of Service quality with details on SLA, QoS (Quality-of-Service) and QoE (Quality-of-Experience) and their mutual interactions. Interaction between actors: it includes a description of actors relevant for the actual scenario as well a description of their interest and mutual relationships, mainly from a business point of view. Financial configuration: it includes a description of the revenue models and cost models for the service relevant of the actual scenario. Technical issues: it includes a description of a variety of issues characterizing the actual scenario, ranging from security issues to horizontal requirements (interactions between Data Center Operators) and vertical requirements (cross-layer interactions ISP network information shared with Data Center Operator). State-of-the-art limits: it includes a description of main technological and business barriers as well a description of the possible risks of actual scenario. SmartenIT innovation: it includes a high level view of the potential of SmartenIT intervention within the selected scenario.
4.3 General Aspects Common to SmartenIT Scenarios

The definition of the scenarios involves a certain number of key features that are not scenario-specific but common to all scenarios. For the sake of clarity, features like the definition of the actors within the relevant scenarios, the service offered within the scenario and some QoS related considerations will be discussed in the following chapter. Key features specific to scenario (and not comprised in the following paragraph) will be described in the proper scenario section. 4.3.1 General Aspects for the Definition of SmartenIT Scenarios SmartenIT scenarios are composed by a wide range of different stakeholders each one having its own characteristics and interests. Cloud Service Providers are the actors offering cloud services to end-user. In the actual scenario instantiation they can be represented by a medium/small company which
Version 1.5
Page 19 of 95

Public
leverages on IaaS Cloud services (computational power and storage) offered by Data Center Operators to provide services to its end-user. Data Center operator is represented by the collapsed roles of entity/company owning and managing a Data Center. A Data Center is a facility used to house computer systems and associated components, such as telecommunications and storage systems. Within the actual scenario the candidate Data Center operator is a small/medium size company that, unlike typical Data Center owned by big player (like Amazon or Google), have limited dimensions (in terms of resources to be deployed) and limited geographical presence. Since the target role is a small Data Center with no geographical redundancy and small footprint, Data Center Operator role terminology will be used across this deliverable even if the term Cloud operator is more comprehensive. Internet Service Provider (ISP) is an organization/company that offers to end-user access to the Internet and related services. ISP actors in the scenario can be categorized [1] in Tier 1 ISP (ISP that has access to the entire Internet Region solely via its free and reciprocal peering agreements), Tier 2 ISP (is an Internet Service Provider that purchases transit to reach some destination(s) within an Internet Region) and Tier 3 ISP (who solely purchase IP transit from other networks (typically Tier 2 networks) to reach the Internet). From a different point of view the Internet Service Provider entities can be distinguished into two main categories: Core and access network providers. Core network providers offer high speed connection (typically ranging from 1Gbps to 100Gbps) over backbone transport network (realized on different and mixed technologies ranging from SDH (Synchronous Digital Hierarchy), OTN (Optical transport Network) to a pure carrier Ethernet transport) with the possibility to offer to business customer L2/L3 VPN (Virtual Private Network) services (mainly over MPLS/IP technology). Access network providers offer connectivity services to residential user (mainly with ISDN (Integrated Services Digital Network) or xDSL (x Digital Subscriber Line) technology) with typical speed ranging from 1 Mbps to 100 Mpbs. Moreover mobile users are of great interest for SmartenIT scenarios, with their access via Mobile Network Operator based on GSM, UMTS, and LTE technologies. End-users in SmartenIT ecosystem can be mainly divided in business users (who leverages on cloud services to expand their business) and consumers (who purchase cloud services for entertainment and communication purposes). The services analyzed in the actual scenario are the typical cloud services for nonbusiness user i.e. video streaming service, file storage service, and pure IaaS service (computing + hosting) for both business and non-business users. Data Center operators can leverage on both private and public cloud model to deliver services, with the initial assumption that business users are offered via private model. Whenever a service is purchased (at whichever level) a service-level agreement is negotiated between two or more parties, where one is the customer and the others are service providers. This can be a legally binding formal or an informal "contract" (for example, internal department relationships). Contracts between the service provider and other third parties are often (incorrectly) called SLAs because the level of service has been set by the (principal) customer, there can be no "agreement" between third parties; these agreements are simply "contracts." Operational-level Agreements (OLA), however, may be used by internal groups to support SLAs.
Page 20 of 95
Version 1.5

Public
Different levels agreement can be established according to the different involved parties providing the service (Cloud service provider, Data Center Operator, Internet service provider) and involved parties purchasing the service (Consumer user, Business user, Cloud Service Provider and Data Center Operator). In Table 4-1 SLA relevant within the actual SmartenIT scenario are listed. Table 4-1: Relevant SLAs with SmartenIT framework.
Actor providing the service Cloud Service provider Cloud Service provider Cloud Service provider Actor purchasing the service Consumer user Consumer user Type of service Video Streaming service File Hosting service Typical SLA Service Availability Service Availability Data security Data recovery Service Availability Data security Data recovery Disaster recovery Service Availability Data security Data recovery Disaster recovery Performance Monitoring Service Availability Data security Data recovery Disaster recovery Guaranties on key performance indicators Network availability Hardware availability Guaranteed Bandwidth Guaranteed Bandwidth, Latency Leased Line, VPN services Security Services (FW, IPS) Guaranteed Bandwidth, Latency Leased Line, VPN services Security Services (FW, IPS, DDoS protection) Network availability
Business user
File Hosting service
Cloud service provider
Business user
Infrastructure as a service
Data Center operator
Cloud service provider
Infrastructure as a service
Internet Service provider
Consumer user
Connectivity service
Internet Service provider
Business user
Connectivity service (high speed, VPN)
Internet service provider
Data Center Operator
Connectivity service (high speed, VPN, redundant access)
QoS refers to a broad collection of networking technologies and techniques. The goal of QoS is to provide guarantees on the ability to deliver packets by some form of superior service level (w.r.t. typical best-effort service), and to provide a predictable service response which is unaffected by external conditions such as the number of concurrent traffic flows, or their generated traffic load. Elements of network performance within the scope of QoS often include availability (uptime), bandwidth (throughput), delay (end-toend, round trip delay, Jitter), and error rate (bit errors, packet loss). Different services and different application have their own requirements in terms of QoS figures. Whenever a
Version 1.5
Page 21 of 95

Public
service is delivered to end-user the contractual SLA should contain proper reference to the minimum requirements for delivered QoS, see Table 4-2 for a raw example of typical cloud application demands on Bandwidth and Latency. Table 4-2: Bandwidth and Latency demand for different type of cloud applications
Basic Cloud application Download speed Upload speed Latency < 750kbps < 250kbps > 160ms Intermediate Cloud application 750kbps 2500kbps 250kbps 1000kbps 100ms 160ms Advanced Cloud application > 2500kbps > 1000kbps < 100ms
The QoS and inter-domain aspects are also of interest for SmartenIT. Most intra-domain solutions are not applicable or fail to scale in the inter-domain Internet context. End-to-end QoS also depends on the performance parameters of the all systems involved in the service delivery starting from Data Center network infrastructure to the terminal equipment. QoS involves prioritization of network traffic. QoS can be targeted at a network interface, toward a given server or router's performance, or in terms of specific applications. A network monitoring system must typically be deployed as part of QoS, to insure that networks are performing at the desired level. QoE is a measure of the overall level of customer satisfaction with a vendor. QoE is related to but differs from Quality of Service, which embodies the notion that hardware and software characteristics can be measured, improved and perhaps guaranteed. In contrast, QoE expresses user satisfaction both objectively and subjectively. The QoE paradigm can be applied to any consumer-related business or service in Information Technology (IT) and consumer electronics. To some extent, QoE is userdependent because some customers are easier to please than others. The best QoE evaluations are direct measures, referred as Mean Opinion Score (MOS), and are obtained by polling or sampling a large number of subscribers. Major factors that affect QoE include cost, reliability, efficiency, privacy, security, interface user-friendliness and user confidence. Environmental variables that can influence QoE include the user's terminal hardware (for example, hard-wired or cordless telephone set), the working environment (for example, fixed or mobile) and the importance of the application. Due to the great focus of QoE measurements in IT business, a large literature has been developed to derive QoE measurements in an indirect way in the form of algorithms to map QoS parameters to QoE figures. For example in [3] it is discussed how the human satisfaction (QoE) of HTTP (Hyper Text Transfer Protocol) service (Web browsing) is affected by the two main network QoS parameters, namely network delivery speed (bandwidth) and latency. QoE themes are of utmost interest for SmartenIT consortium which has already a consolidated partner expertise on this area ([53], [54]).
4.4 Inter-cloud Communication

The Inter-cloud is an interconnected global "Cloud of Clouds" and an extension of the Internet "network of networks" on which it is based. The term was first used in the context of cloud computing in 2007 when Kevin Kelly opined that "eventually we'll have the intercloud, the cloud of clouds the Data Center of the future [2].
Page 22 of 95
Version 1.5

Public
The Inter-cloud scenario is based on the key concept that each single cloud does not have infinite physical resources or ubiquitous geographic footprint. If a cloud saturates the computational and storage resources of its infrastructure, or is requested to use resources in a geography where it has no footprint, it would still be able satisfy such requests for service allocations sent from its clients. The Inter-cloud scenario addresses such situations where each cloud would use the computational, storage, or any kind of resource of the infrastructures of other clouds. Such forms of cloud exchange, peering, or roaming may introduce new business opportunities (such as cost-effective assets optimization, power saving, and on-demand resources provisioning) among cloud providers if they manage to go beyond the actual operational framework [3]. Sharing resources between different Data Centers on one hand allows Data Center Owners to offer wider range of services (service composition), to avoid resources exhaustion due to peaks in resource utilization but on the other hand has a negative impact on the WAN (Wide Area Network) traffic caused by new traffic pattern generated (Virtual Machine migration, database exchange/synchronization). Figure 4-1 ([4]) briefly summarizes the evolution of cloud computing framework from the very old scenario based on legacy systems towards the multi-domain inter-cloud scenario whose importance is foreseen to grow in the next years.
Figure 4-1: Evolution from Single Cloud to Inter-cloud scenario. The main topics of the selected scenario are the interaction of the formed overlay network with the underlying connectivity infrastructure offered by Internet Service Providers, SmartenIT potential of traffic optimization to allow energy efficiency and QoE enhancements, business relationships analysis as well as SLA/OLA impacts in the interaction among different players. 4.4.1 Scenario Overview The complete and detailed instantiation across the template for inter-cloud communication scenario is given in Table 4-3.
Version 1.5
Page 23 of 95

Public
Table 4-3: Template instantiation for inter-cloud communication scenario.

Title Inter-cloud communications Scenario objective The inter-cloud communication scenario focuses on the interaction between cloud service providers acting in a multi domain operation topology. The scenario is focused on a Federated Cloud model in which different Data Center Operators join together in a Cloud federation to allow resource sharing between the different Cloud players with the final aim to deliver service with expected SLA to their end-user. The main topics of the selected scenario are: The interaction of the formed overlay network with the underlying connectivity infrastructure offered by Internet Service Providers. SmartenIT potential of traffic optimization to allow cost savings, energy efficiency for the ISP and QoE enhancements for end-users. Business relationships analysis (to verify if the analysis as performed in D1.1 applies to here). SLA/OLA impacts in the interaction among different players. The objective of this scenario is to allow the formation of federations so that small Data Center Operators can benefit, while allowing the ISPs to deploy special Traffic Management (TM) processes that ease the communication between clouds or Data Centers and minimize their costs. These Traffic Management processes can be offered as a service by the ISPs to the Cloud and/or Data Center Operators that want to form a Cloud federation. Framework definition Actors Cloud Service Providers (offers software or application services to enduser, e.g., SaaS) Data Center Operators (merged role of Data center operator and Cloud Provider for IaaS Service, i.e. it owns and manages one or multiple Data Centers) Internet Service Provider (access and backbone network) offering connectivity service over both public and private networks. They can be further distinguished to: Transit network providers: Providers selling global Internet connectivity (wholesale market). Edge network providers: Providers serving end-users of a region (retail market), customers of Transit network providers Users can be divided in two categories: o Business users, IT Companies mainly interested in purchasing pure IaaS service (Computing and Storage) o Consumers, private users who purchase cloud service for entertainment and content sharing purposes Application/Service End-user services overview Video/file Streaming service File Hosting service Service enabling technologies Virtual Data Center resources (IaaS pure service) Service Quality Service quality is to be referred to the following main areas: SLA (Service Level Agreement), QoS (Quality-of-Service), QoE (Quality-of-Experience) for end user Energy efficiency Each item should be further investigated depending on mutual interaction between involved parties, with focus on the parts relevant to SmartenIT, like: SLA between the Cloud Service Provider and the End-User as part of the
Page 24 of 95
Version 1.5

Public
contractual agreement for the selected service. SLA between the Cloud Service Provider / Data Center and the network operator End to End Quality of Service (Latency, Jitter, Round-trip Time, Throughput, Packet Loss) as the quantitative measure performed by ISP of the end-to-end path performances. Quality-of-Experience, as perceived by end-user, as a measure of the goodness of the service offered by Cloud Service Providers and purchased by end-users. Its actually measured by Cloud service Providers and some mechanism should be provided by SmartenIT solution to feedback QoE related information to Data Center Operator and to ISP. Interaction between actors Stakeholders interests Cloud Service Provider interests: monetization of services purchased by end-user, increase the exposure of contents. Data Center Operator interests: energy efficiency within Data Center, avoiding performance bottlenecks, offer high availability features, reduce traffic on ISP network. Internet service Provider, keep low the usage on owned links, keep low the traffic on transit links, provide a delivery service with guaranteed QoS to its customers, avoid congestion. Stakeholders The main relationship between actors: relationship Contrasting interests (non-homogeneous stakeholders) o Data Center operator will share resources among federation utilizing WAN links of Internet Service Provider. Internet Service provider wants to maintain as low as possible the link utilization and balance the incoming traffic across his interconnection points and network o Cloud Service Provider want to operate some traffic management for traffic directed over ISP owned links o Internet service provider wants to maintain as low as possible traffic on transit links, wants to achieve an optimization of its resources (avoid links congestion, energy efficiency) Competitive interests (homogeneous stakeholders) o Different Internet Service providers not willing to cooperate o Different Cloud Service Providers not willing to form Federation Within SmartenIT framework both contrasting and competitive interests could be overcome by leveraging on the benefits SmartenIT traffic management solution and by the incentives in forming the Cloud Federation. Financial configuration Revenue model Cloud Service Provider: pay-per-use model, free access with basic capabilities, monthly/weekly subscription access with enhanced capabilities, flexible form of payments based on service bundles Data Center Operator: pay-as-you-go model, monthly/weekly subscription Internet service provider: pay-as-you-go model (95% rule), monthly/weekly subscription, peering/transit options with other Internet Service providers, peering with IXP (Internet Exchange Point), VPN/leased lines products for business customers Cost Model Cost reduction for Cloud service Providers and business end-users Possible cost increase for ISP (OPEX (Operational Expenditures) due to inter-cloud traffic) Cost reduction for Data Center Operators when joining the Cloud federation Possible cost increase for ISP (OPEX due to inter-cloud traffic) Technical issues Performance Quantitative Key Performance Indicators (KPI):
Version 1.5
Page 25 of 95

Public
Measurement
Security issues
Horizontal requirements
Vertical requirements
o Metrics for Energy efficiency [6] Power Usage Effectiveness (PUE) Carbon usage Effectiveness (CUE) Water usage Effectiveness (WUE) o End to end QoS measurements (round-trip time, jitter, peak bit rate, mean bit rate, traffic burstiness) o Service availability Qualitative performance measurements based on real traffic analysis All performance measurements need to be utilized to feed the SmartenIT traffic management solution deployed within the actual scenario in order to take optimized decision on Cloud traffic forwarding. Federated Cloud Service Providers should agree on common framework to allow unified management of security issue related to their customer data (i.e. if convergent encryption is used by Cloud Service Provider A, the same model must be used by partner Cloud Service Provider B) Cloud Federation should take into account different Security laws depending on country of Cloud Service Provider Overlay (Cloud) to physical (network) level security concerns due to virtualization/lack of control over aspects of the service (e.g., traffic should not pass a rivals network) Horizontal requirements (or intra-layer requirements): Proper protocols/agreements between Data Center Operators to join the federation and to exchange relevant data for resources sharing Interaction between ISP (Peering, transit) Vertical requirements (or Cross layer requirements) Interaction between Cloud Service Provider and ISP (potential Collaboration and metric exchange, co-location of SmartenIT components) Interaction between Cloud Service Provider and end user (End-to-end performance/QoE measurement, collocation of SmartenIT components Difficulty to gather statistics on Cloud related traffic when crossing single/multiple ISP domains Standard Protocols for Inter-cloud communication not fully developed QoS for inter-domain services not emerged in the market, while intradomain QoS can be supported Use of standard interface to be offered from different Data Center Operators joining the federation to the end-users. No or little possibility to leverage on already-done theoretical analysis on selected service/application Legal issues (different security laws depending on country) Users may be concerned about the fact that private data are managed by third party Cloud Service Provider who is joining the Federation Missing a well-defined framework for commercial agreement and for charging within the cloud federation entity. ISPs between federating cloud/data center operators need to make bilateral agreements, perhaps in redefining how classes of services are handled by them. Competing Stakeholders (i.e. Smaller Data Center Operators) not willing to establish economic agreements Conflicting incentives and possible spill-over effects with existing business agreements Possible risks factors: Selected application/service with little potential for SmartenIT intervention
State-of-the-art limits Technological barriers
Other barriers specific for the scenario Business barriers
Risks
SmartenIT innovation Key innovation The key innovation of SmartenIT within the actual scenario is mainly related to the following two key areas:
Page 26 of 95
Version 1.5

Public
Energy efficiency (in both Data Center and ISP infrastructure) Offer economic incentives between stakeholders (Cloud Service Provider and ISP) to provide a fair optimization of cloud traffic. Coordination via SLAs and incentives of multiple actors to provide the end-to-end service in a win-win fashion for all the actors involved
4.4.2 Interaction between Actors The wide range of actors that have been identified within the actual scenario has mutual relationships that are mainly business driven. The main interest of the Cloud Service Provider is the monetization of services purchased by the end users and the Data Centers. To this end, the cloud service provider attempts to attract demand and differentiate its product offerings so as to serve various market segments with different prices/packages, so as to extract as much of its customers surplus as possible. Its main concern is also to respect the SLA it has with its customers and properly dimension its infrastructure to cover the respective demand and redundancy requirements. Efficient network connectivity for its premises and in order to reach its customers also implies interaction with the Internet Service Provider, who needs to perform Traffic Engineering in order to meet the Cloud Service Providers (CSP) needs. In the general case of multi-domain presence of the CSP, there are not quality guarantees for inter-domain connectivity in the market, as opposed to intra-domain traffic. Interconnection with other CSPs can reduce the transit fees it pays to the ISP. The Data Center Operator is primarily concerned with the efficient use of is infrastructure, i.e. make the best use of energy consumed for the completion of the maximum possible amounts of task. It is possible that a part of its infrastructure is purchased from some Cloud Service Provider under an IaaS or PaaS model. Similarly to the CSP, its main concern is also to respect the SLA it has with its customers and properly dimension its infrastructure to cover the respective demand and reduce its costs. A main attribute for its costs besides energy is transit costs for the data transfers: An emerging trend is Data Center interconnection, similarly to the donut peering model of ISPs: Data Centers are gradually interconnecting with other Data Centers via exchange points so as to reduce transit costs. Another interesting emerging prospect is that of federations: since in the data center business multi-location presence and locality in execution of tasks is crucial so as to be competitive, small data center operators may team up and build a federation by combining their resources and aligning their business processes so as to appear as a large virtual data center operator to their potential large business customers. In this case, interactions within the Federation are policed by means of business policy rules defining what are the rights and obligations of each Federation member. The Internet Service Provider aims to maintain good quality in his network, which gives him a competitive edge in the market. The ISP interacts with other ISPs via peering and possibly transit agreements (if not Tier-1) for the management of the traffic of his customer, both upstream and downstream. Providing guarantees for the delivery of portions of the traffic and/or isolating a part of the traffic of Data Centers and/or ISPs (e.g., via VPNs, leased lines, or private paid peering agreement) is a source of potential revenue for the ISP. The main goal of the ISP is to meet the SLAs of his customers with cost and energy efficient resource provisioning and to manage the incoming traffic which is possibly delivered to him via multiple interconnection points. An additional goal for Tier-1 and Tier-2 ISPs is to sell transit interconnection agreements to other ISPs, Data Center Operators and Cloud Service Operators.
Version 1.5
Page 27 of 95

Public
End users are to a large extent unaware of the business agreements and interactions among the other stakeholders. They are aware of the description, cost and quality (QoS) of the services they purchase, e.g. Internet access from an ISP, file hosting from a Content Service Provider (CSP). The end users are sensitive to the reliability and availability of the service, the support they receive when needed, as well as the performance of the service and the resulting QoE attained. All those features are typically defined in the contract/SLA of the service between the end user and the respective service provider. In case multiple providers are needed for the provisioning of a certain service, the respective interactions are hidden by the end users due to the nesting of the internal SLS, who solely interacts with a single point of service, i.e. the provider from which he has purchased the end-to-end service. The main relationship between actors can be categorized as belonging to two distinct areas that are defined in the following: Contrasting interests (non-homogeneous stakeholders): Data Center Operators will share resources among federation utilizing WAN links of Internet Service Provider and potentially wants to operate some traffic management for traffic directed over ISP owned links Cloud Service Provider and Data Center Operator may be cooperating via business interactions so as to help each other improve its market position and be compensated for the resources leased, and at the same time competing for non-overlapping sets of customers, thus rendering a question on how much to cooperate versus how much to compete.
Internet service providers want to achieve an optimization of its resources (avoid links congestion, energy efficiency). Competitive interests (homogeneous stakeholders): Different Internet Service providers may not be willing to cooperate. This is in particular evident in routing today where multiple issues such as hot potato routing, selective degradation of the quality of peering links, de-peering or refusal to interconnect clearly demonstrates the fierce competition and complex business games among the different ISPs, Due to the inherently decentralized nature of Internet, these issues reduce the efficiency of the network and often deter investments (e.g. due to fear of business stealing through properly dimensioned peering links) Different Data Center Operators may not be willing to form Federation. Also even if they do intend to do so agreeing on a commonly acceptable set of rules, admittance policies and alignment of business processes is a cumbersome task that requires strong commitment and high effort, resulting in initial overheads for the Data Center Operators that may (or not) deter them from joining the federation.
One of the main goals of SmartenIT solution is the possibility to overcome the limitations imposed by different business strategy of different actors by: Propose incentives for the cross layer interaction, by leveraging on information asymmetry that is experienced in a layered network (information asymmetry between ISP (network layer) and Data Center Operators (overlay network)) Propose incentives for the cooperation between smaller Data Center Operators to allow the formation of a Cloud Federation to allow resource sharing and to be more
Page 28 of 95
Version 1.5

Public
competitive and achieve a larger market share otherwise dominated by big Data Center Operators Propose Federation types (homogeneous/heterogeneous) reflecting multiple degrees of cooperation and horizontal/vertical integration among its members and respective policy rules Evaluate and assess their impact on individual stakeholders and the ecosystem as a whole.
4.4.3 Financial Configuration Regarding Cloud Services (encompassing both Data Center Operators and Cloud Service Providers), the most frequently used pricing model is the pay-per-use model, in which the user pays a static price for a unit used, often per hour, Giga Byte (GB), or CPU-hour (Central Processing Unit). The pay-per-use pricing model is a simple model, in which units (or units per time) are associated with fixed price values. This simple concept is widely used for products (services), whose mass production and widespread delivery has made price negotiation impractical. The dominance of the above pricing models can be explained due to the fact, that users often prefer simple pricing models (like pay-peruse or subscription) with a static payment fee. The reasons might be the ease of understanding and accounting, the clear base of calculation but also psychological reasons, such as overestimation of usage and avoidance of occasional large bills, even when the fixed-fee costs more over time. Dynamic pricing (also called variable pricing) is a pricing model, in which the target service price is established as a result of dynamic supply and demand, e. g. by means of auctions or negotiations. This pricing model is typically used for calculating the price of differentiated and high value items. From the Internet Service Provider point of view, different revenues strategy can be applied depending on the kind of mutual agreement between different service providers: The Internet Transit service is typically a metered service outside of the residential market. The unit price for Internet Transit services varies widely, but the service itself is typically priced based on traffic volume measured at ingress and/or egress routers or a fixed access bandwidth is provided at a monthly rate. Peering is typically a free arrangement, with each side deriving about the same value from the reciprocally arrangement. If there is not equal value, sometime one party of the other pushes for a Paid Peering relationship. With paid peering, one side extracts additional concessions in the form of a metered rate, or whereby one side pays for the transport for the other, or one side has to pay for transport and colocation.
Internet Service providers revenues in their mutual relationships with end-users are mainly regulated by two different consolidated strategies: the pay per use model and the monthly/weekly charge model. The services purchased from the end users generate the money flows that support the entire service and finance the provisioning of its segments. The subscription of the end user could either be explicit (pay per-service case) or implicit (subscription is bundled in the end-users contract paid by the end-user to his provider for a group of services that are provisioned as a single contract). For the management of aggregate traffic flows, it is expected that the purchaser of the involved traffic contracts, typically the Data Center Operator and Cloud Service Provider
Version 1.5
Page 29 of 95

Public
will have to compensate the involved networks (if any) for carrying this traffic on top of their network and depending on the quality constraints that have to be met. These costs are typically transit costs while additional network costs include energy consumption, renting of space in Internet exchange points (if applicable), maintenance and operation costs for the IT infrastructure in place, software and hardware upgrades, customer support. Regarding money flows and financial configuration, there are two distinct charging layers with separate/co-existing money flows: the aggregate level traffic charging at the network layer (ISP charging) and the per-service instantiation based charging at the application layer (end-user payments). End users typically subscribe for a given service with certain requirements that might have implicit QoS requirements (e.g., file hosting) or explicit QoS requirements (e.g., VPN, business connectivity services) for the network. These are reflected in the SLA with the respective ISP. Note that currently ISPs exchange at the points of interconnect solely data and BGP (Border Gateway Protocol), thus attaining the desirable QoS over inter-AS (Autonomous System) network footprint requires ad-hoc stitching of multiple contracts with the respective ISPs; inter-domain QoS is currently lacking in the market, though research projects (e.g., ETICS) and companies (e.g., Deutsche Telekom DT) have recently announced the potential and mechanisms of establishing QoS interconnect. The current revenue model in the ISP world is that small networks (i.e.Tier-3 ISPs) as well as Data Center and Cloud Service Provider compensate upstream ISPs (i.e. Tier-1 or Tier2 Transit Network Service Providers) for Internet connectivity. However some largefootprintTier-3 ISPs often succeed to attain some revenue from content providers in order to guarantee high quality for their services. Those agreements are bilateral, typically confidential and implemented via private interconnection of the two parties and custom TE (Traffic Engineering) solutions and BGP configuration. In the case of federations of clouds and Data Centers, some revenue sharing scheme must be decided by the involved parties. We envision that these federations will be highly specialized; addressing a specific target market and service and their operations will be regulated by common business policy rules that are unanimously approved by the federation members. Well known mechanisms for revenue apportionment, such as Shapley values or even auction-based stock market-like mechanisms for the dynamic allocation of resources (e.g., storage and additional bandwidth on-demand), comprise potential candidate solutions. The ISPs must invest to compete for the money-generating traffic; investments are expected to be individual, i.e. on a per-stakeholder basis, while federations and alliances, e.g., in the form of capacity and network deployment sharing, are also possible as complements. Also interconnection costs for the creation of new network routes, establishing presence in additional Internet exchange points and creating private peering links are part of the complex picture. In the case of federations, it is envisioned that some minimum amount of investment and network/storage availability will be required by the members of the federation, so as to be eligible to remain as active federation members and benefit from the resulting brand name and economies of scale. The smart management of the traffic flows may also impede costs to the ISPs. Vertical integration in the market between the ISPs, the Data Centers and the clouds is also likely, thus creating a complete customer solution controlled by a single business entity. The cloud and federation paradigms will allow increased awareness over the different costs over different
Page 30 of 95
Version 1.5

Public
parts of the network, and computational infrastructure thus, serving towards sustainable market prices and efficient serving of end-users needs. 4.4.4 Technical Issues Next, a certain number of technical characteristics relevant for the actual scenario will be selected and discussed. The first technical issue is related to performance measurements. Performance measurements mechanisms are at the basis of the proposed SmartenIT traffic management solution to be deployed within the actual scenario. A wide range of KPI metrics have been identified in the following: Energy consumption metrics are gathered at end-user device and at devices within ISP infrastructure. Those metrics must be gathered at ISP layer and made available for the SmartenIT modules on the overlay network. Then the collected metrics are used by SmartenIT traffic management module to optimize the traffic, e.g. to find the best path within ISP network to allow for energy savings. QoS measurements are performed at network layer in ISP network devices (routers and switches) on the basis of real-time traffic measurements. From traffic measurements (aggregated values of transmitted/received bytes and octets based on SNMP queries for relevant devices interfaces) QoS figures (throughputs, latency, round-trip time, jitter) are derived and sent to SmartenIT decision making modules to drive decisions on traffic management. QoE measurements can be divided in two categories: direct measurements (obtained evaluating with several metrics the quality of the service perceived by user) and indirect measurements (obtained by mapping QoS and traffic characteristics to QoE with proper algorithms). Regarding direct QoE measurements there are 5 areas to be considered: 1. Quality of experience must be measured at the ultimate point of delivery the end users computer or Smartphone typically using an embedded testing app. The further benefit of using an embedded test app is that it can scale practically and rapidly across an entire subscriber base. 2. Test the Application as a Whole Experience. QoE test scripts goes beyond individual technical measurements to analysis of KPIs that affect an application. For example, to measure how well video streaming works, metrics such as packet loss, latency and jitter are subjectively weighted through a video quality algorithm to determine their combined effect of the actual customer experience. 3. The type of traffic used when testing quality of experience needs to be representative of the application being analyzed. 4. Flexible and Large Scale Deployment. Operators need to have the flexibility to rollout out quality of experience measurement technology to selected groups or individuals, as required. Ideally thousands of subscribers are monitored on a continuous basis in order to understand trends and proactively manage experience through demographic analysis. Easy-to-deploy, non-invasive data collection and retrieval technology is required. 5. No Subscriber Impact. When using people as part of a test strategy consideration needs to be given on the impact the testing may have to their normal use of broadband services. There are numerous security issues for cloud computing as it encompasses many technologies including networks, databases, operating systems, virtualization, resource
Version 1.5
Page 31 of 95

Public
scheduling, transaction management, load balancing, concurrency control and memory management. Therefore, security issues for many of these systems and technologies are applicable to cloud computing. For example, the network that interconnects the systems in a Cloud has to be secure. Moving databases to a large data center involves many security challenges such as virtualization vulnerability, accessibility vulnerability, privacy and control issues related to data accessed from a third party, integrity, confidentiality, and data loss or theft. Furthermore, virtualization paradigm in cloud computing results in several security concerns. For example, mapping the virtual machines to the physical machines has to be carried out securely. Data security involves encrypting the data as well as ensuring that appropriate policies are enforced for data sharing. In addition, resource allocation and memory management algorithms have to be secure. Finally, data mining techniques may be applicable to malware detection in clouds. In different cloud service models, the security responsibility between users and providers is different. According to Amazon, their EC2 addresses security control in relation to physical, environmental, and virtualization security, whereas, the users remain responsible for addressing security control of the IT system including the operating systems, applications and data. Data Center Operator SLA mapping/negotiation. Within the context of inter-cloud federation in which different cloud providers join together with the main aim to share resources, proper SLA mapping for the offered service should be foreseen. Since the SLA related to the service is contract established between Cloud service provider and end-user and the end-user is unaware of where its data are stored and what resources are used to compose its service (resources that can potentially come from different Data Center Operators), proper SLA figures should be negotiated when forming the inter-cloud federation in order to ensure that selected service are offered with the contractual SLA. SLA mapping (negotiation) should be provided within the formed overlay network. At the time of writing no standard protocol/framework exist to provide this functionality. A certain set of Horizontal Requirements is expected to regulate the relationship among intra-layer homogeneous actors to properly establish communication and exchange information. In order to join the federation different Data Center Operators should expose metrics about their available resources, the service they can offer as well as the related SLA. Moreover Data Center Operators must exchange information regarding security practice to handle data (in case of database replica between Data Center Operators). Also Vertical Requirements should be foreseen when describing the interface among cross-layer non-homogeneous actors. Those requirements are related to the interaction between Data Center Operator and ISP (potential Collaboration and metric exchange, colocation of SmartenIT components) and to the interaction between Cloud Application Provider and end user (End-to-end performance, QoE measurement, co-location of SmartenIT components). The main goal of vertical communication is to allow the possibility of overtaking the Information Asymmetry between Cloud Service Provider (who decides when and where position its resources) and ISP (who has the complete view of the topology of its network). 4.4.5 State-of-the-art Limits The scenario depicted so presents a certain number of practical limitations which can potentially limit the major outcomes of SmartenIT project. The first limitation is a business limitation. One of the main assumptions made during the scenario description is the collaboration of stakeholders, especially between Cloud Service Provider and Internet
Page 32 of 95
Version 1.5

Public
Service provider. From a business point of view such a collaboration (exchanging of information and hosting of SmartenIT components) could be unfeasible unless it can be demonstrated that a collaborative approach can provide benefits for both parties. From the technical limitations point of view a certain number of limitation arise mainly related to the forming of the federation due to the fact that actually there is no standard approach to manage all the issue analyzed so far (security issues, SLA mapping, exposure of available resources). Finally a market limitation is that inter-domain QoS interconnect is not available as a market product in the Internet interconnection ecosystem. 4.4.6 SmartenIT Innovation The key innovation of SmartenIT within the actual scenario is mainly related to the following key topics: Proper traffic management solutions to achieve energy efficiency solution in both Data Center domain (Virtual machine migration) and ISP infrastructure (fair network utilization to reduce the load of device and allow to avoid link congestion) Enhancement of Quality of Experience as perceived by end-user. QoE metrics are measured on end-user domain and used to drive decision by SmartenIT traffic management component. Offer economic incentives between stakeholders (Cloud Service Provider and ISP) by providing a fair optimization of cloud traffic. Offer incentives and resolve tussles for the establishment of Federation and/or other incentive-compatible collaborative paradigms. Coordination via SLAs and incentives of multiple actors to provide the end-to-end service in a win-win fashion for all the actors involved. SmartenIT initial architecture has been described in D3.1 project deliverable [56]. The depicted SmartenIT solution is intended to be deployed within the actual scenario in a distributed way, with different components (implementing the full or a limited set of SmartenIT functionalities) hosted at data Center Operator premises (overlay manager), at Internet Service Provider premises (S-Box - Traffic Manager) and at end-user level (QoE monitoring). The SmartenIT service uses traffic, energy and economic information as input variables, aiming at, (a) minimizing energy consumption in the network (and potentially in the Data Centers), (b) optimizing traffic handling within operators networks, including Clouds and Data Centers, and (c) offering resource scheduling services in a cloud federation environment. This is achieved through a series of SLAs and traffic management mechanisms in the value chain that enforce the desired routing, energy efficiency and QoS attributes on an end-to-end deterministic or statistical basis.
4.5 Global Service Mobility (User Mobility)

The mobility of services is a key success factor for the cloud concept, as it allows moving services (e.g., virtual machines or content) within or among Data Centers worldwide, allowing for an optimal placement with respect to the optimization goals relevant for the stakeholders. Within the global service mobility scenario, we add several innovative aspects to the common concept of service migration, e.g., the terms of vertical and horizontal service mobility, which also take the users capabilities as a service provider into account (see Figure 4-2).
Version 1.5
Page 33 of 95

Public
Figure 4-2: Scenario Overview of Stakeholders and types of mobility. In the following, the framework definition of the scenario is given, starting with an identification of the stakeholders and their inherent interests. We identify new business opportunities by analyzing interactions of the stakeholders and define technical means to foster Internet Service Provider and Application Provider interaction for the benefit of both sides. Moreover, we provide a concept, how Internet Service Providers can get into competition with cloud providers by using the concept of User-owned Nano Data centers (uNaDas). 4.5.1 Scenario Overview The complete and detailed instantiation across the template for inter-cloud communication scenario is given in Table 4-4. Table 4-4: Template instantiation for Global Service Mobility scenario.
Title Scenario Overview The Global Service Mobility scenario focuses on the placement of services, taking two dimensions into account: Horizontal mobility describes the mobility on one level of aggregation, e.g., among Data Centers and/or Nano Data Centers (NaDa) Vertical mobility describes the mobility across levels of aggregation e.g., from Data Centers to Nano Data Centers and vice versa Global Service Mobility
In this scenario, we intend to find an optimal placement of services by maximizing two main metrics: Energy efficiency of the service, including the data center level, the core network and the enduser, especially when using mobile devices Quality of Experience of the end-user These metrics are constantly evaluated by the stakeholders entities in a dynamic optimization
Page 34 of 95
Version 1.5

Public
process, so the placement of a service may change during operation. The main goal of this scenario is to go beyond existing approaches using social data as an additional input for the optimization problem. The scenario as a whole focuses on the Internet Service Provider as a main stakeholder. The ISP gives recommendations on the horizontal placement of services and provides a platform for enabling vertical service mobility. Framework definition Actors Application Providers Data Center Operators ISPs End-users End-user services Video/file Streaming service File Hosting service Service enabling technologies Virtual Data Center resources (IaaS pure service) The scenario focuses on the interaction of ISP, Data center Operator and Cloud Application provider, where the ISP assists the Application provider in offering global service mobility. Service Quality Interaction between actors Stakeholders interests Application Providers: Satisfy QoS/QoE and energy efficiency requirements of end user, minimize cost for infrastructure (network access and computation) Data Center Operators: Monetization of infrastructure (network, computation), reduction of costs (energy efficiency), satisfy application providers/end users needs ISPs: Increase revenue from infrastructure (network), reduction of cost (peered links), satisfy QoS/QoE needs of data center operators and mobile end users QoS/QoE for application provider, energy efficiency, measured, e.g., by the application provider QoS/QoE for network operators, energy efficiency, measured, e.g., by the application provider and end-user QoS/QoE for end user, energy efficiency, measured, e.g., by the enduser
Service overview
Stakeholders relationship
End users: Satisfy own QoS/QoE, minimize network access cost, minimize energetic expenditures for network access Application Providers: Paid* by (mobile) end user for services Pays cloud providers or DC provider for access to infrastructure (storage, computation) Data Center Providers: Paid by application provider for infrastructure (computation, network, storage) ISPs: Provides network access to customers (data center operators and end users), thus monetizing own infrastructure End users: Pays* application providers and ISP for service/network access to satisfy own QoS/QoE needs (*) Either using money or advertisement
Version 1.5
Page 35 of 95

Public
Financial configuration Revenue model ISP offers additional services using his own infrastructure o Recommendations for content placement to cloud providers and application providers w.r.t. to QoS/QoE for a set of data center locations per end-user o Detection/prediction of movement of users as a service, according placement of services o IaaS, offloading using uNaDas to application providers/cloud providers o Caching of content to cloud providers Recommendations for content placement have to be generated ISP has to provide incentive for users to provide resources (computation, offloading via users WiFi), where incentives cannot be provided in a self organizing way
Cost Model
Technical issues Performance Measurement Main metrics are energy efficiency and QoS/QoE o Computational resources (data center efficiency, cooling) o Network core energy resources (switching, wireless access network) o End users devices (battery drainage) o End user QoE (start time to the service, video quality, wireless link quality) Secure service execution independent of location to keep privacy of end users Management of user identities is dependent on the concrete implementation of mechanisms In the case of 3G offloading via uNaDas (User-owned Nano Data Centers), a restriction of access might be necessary Trust relations from Online Social Networks can be included Interaction of Data Center Operators may be necessary Interaction of end-users is necessary Interaction of ISP and Application Providers/Cloud Providers is necessary
Security issues Horizontal requirements Vertical requirements State-of-the-art limits Technological barriers
Business barriers
Risks
The described use cases include an ALTO based approach for ISP Application Provider interaction. Therefore, an adaptation of the ALTO protocol might be necessary. [9] Energy efficiency of uNaDas uNaDa prices Willingness of actors to interact (incentives) Securing business secrets of ISPs (e.g., network topology) Application Providers might roll out own uNaDa systems o This depends mainly on the time of entry into the market. Early innovators can gain a significant advantage. However, ISPs are in a good position, as they often sell subsidized hardware with their service subscriptions. Incentives might be too low, depending on the performance the SmartenIT solution can deliver o The incentive mainly depends on the performance of the solution, as the performance determines the incentive for
Page 36 of 95
Version 1.5

Public
adoption. The performance is to be measured during the course of the project. SmartenIT innovation Key innovation NaDa offloading, energy efficient approach taking Data Centers, Core Network and Mobile Access into account
4.5.2 Framework Definition Global service mobility is already happening in practice nowadays. Essentially, a migration of virtual machines or content between Data Centers with respect to the user position can be regarded as an instance of global service mobility.
Figure 4-3: Illustration of types of service mobility The global service mobility envisioned in SmartenIT relies on four distinguishing features: Horizontal and vertical service mobility: Besides the common movement of services within the same level of aggregation (e.g., migration among Data Centers), to which we refer as horizontal service migration from now on, we add an additional infrastructure layer consisting of user-owned Nano Data Centers (uNaDa). These devices are located in end-users premises and enable vertical migration of services: the movement of services and content closer to the user. Thus, within the scope of this scenario, global service mobility is an optimization of two movements, horizontal and vertical placement of the service, as depicted in Figure 4-3. Service mobility based on exploitation of social information: the placement of service will be optimized by taking into account some social information. Such information can be aggregated from different ways: from a direct cooperation with OSN applications and end users or from the ISP who might exploit its aggregated knowledge on users preference or users mobility. Energy efficiency for the placement of service: The optimization function is based on the energy efficiency of Data Centers, the core network, end-user devices, in addition to the Quality of Service/Quality of Experience requirements of the end-user. It will take into account the computational resources (data center efficiency, cooling), the network core energy resource (switching, wireless access network), the end users devices (battery drainage).
Page 37 of 95
Version 1.5

Public
Dynamic optimization process: The objective function is evaluated constantly in order to maximize the efficiency of placement and to perform frequent adaptation. Establishing this feedback loop allows optimizing the placement of services in a fluctuating environment, i.e., considering temporal changes in the optimization process.
As inferred above, the software services considered within the scope of this scenario are treated as being independent from their place of execution, i.e., being moveable objects. In particular, the service placement is performed with respect to three parameters describing the movement of a service from one location to another: Location: The horizontal and vertical placement of the service. Time: When to move a service. The movement can happen pro-actively, by using prefetching/caching mechanisms to move data in advance based on e.g., the prediction of user mobility or in a reactive way, to move the service, when the global service mobility is triggered by an unpredicted move. Type of movement: Deciding on what and how to move. For example a move may be a one data move, which means all the data is moved to a new location or a gradual move triggered by policies (most accessed data, most triggered services). 4.5.3 Interaction between Actors In the following, we describe the interests of actors of the scenario towards each other. A part of this analysis may have overlaps with chapters 4.4.3, 4.6.3, and 4.7.3. However, the analysis provided in this chapter is more user-centric than in other scenarios. The structure of the stakeholders interests is summarized in a matrix (Table 4-5: Stakeholder's Interests). Cloud Application Provider: The primary concern is to provide a good Quality of Service and a high level of trust of end users in the offered services in order to be able to monetize the services. The monetization is commonly done by either making the end-user accept a certain level of advertisement or by introducing pay walls to the service. On the other hand, there is pressure to keep the costs for infrastructure low, i.e., for renting resources from Cloud Providers and Co-location providers offering access to their Data Centers. Data Center Operator: Cloud Providers act on in the interest of Application Providers, as Application providers are direct customers of Cloud Providers. Usually, there will be some Service Level Agreement with Application Providers covering the relevant service level parameters for the service, which guarantees a satisfactory Quality of Service/Quality of Experience for the end-user. Cloud Providers are highly interested in keeping these agreements, as violations decrease their revenue. On the other hand, a critical factor is the cost for providing infrastructure while having a good utilization of the hardware. Besides the cost for hardware, the Cloud Provider is dependent on the ISP to provide network access, which is often also restricted to a certain QoS using Service Level Agreements. Internet Service Providers: ISPs are interested in offering network access to their customers, in order to monetize the provided infrastructure and to reach a good utilization. Moreover, ISPs feel increasing pressure to offer new services, where
Version 1.5
Page 38 of 95

Public
Application Providers and End-users are of major interest as customers. These additional services nowadays often only target end users (e.g., triple play offers). Offering new services to Application Providers would open new market opportunities for ISPs. Within the scope of the global service mobility scenario, we propose two new services (use cases one and two) the ISP can offer to Application Providers. Two factors influencing costs of ISPs are energy costs and the cost of peered and transit traffic from other Autonomous Systems. End-user: End-users are mainly interested in receiving a satisfactory Quality of Service and Quality-of-Experience at a reasonable price. Usually, the role of the enduser is limited to the role of a customer of the ISP, and Application Providers. Besides that, the energy efficiency of services and network access is a factor of increasing importance from the point of view of the end user, especially when considering mobile network access (e.g. through the limitation of battery lifetime when using a mobile device). Major business opportunities for the ISP can either be seen in additional services offered by Application and/or Internet Service Providers or in a reduction of access cost.
Please note we are using a simplified model. Application providers do not interact directly with the ISP. This may be true in some cases, e.g., with Dropbox using Amazon cloud storage services, while other application providers operate their own cloud infrastructures. Nevertheless, from a technical point view, this simplification is useful and does not prevent a logic pooling of a cloud provider and application provider where it might be necessary during the project. As a direct implication from this simplified model, end-users do not interact directly with cloud providers in the economic sense. Instead, the application provider is responsible for fulfilling an end-users requirements by choosing an appropriate infrastructure for the provided service. In Table 4-5 stakeholders interest are described with the assumption that greyed out text is either a self-reference or excluded by definition. Table 4-5: Stakeholder's Interests.
Interest toward Stakeholder Application Provider Cloud Provider ISP End-Users
Application Provider
Monetize offered services, reduce costs
Minimize cost for using infrastructure (IaaS, storage)
(Excluded by definition, interaction happens through Cloud Provider)
Satisfy QoS/QoE and energy efficiency requirements, monetize service
Cloud Provider/ Colocation Provider
Satisfy SLAs, monetize service
Monetize infrastructure, high utilization, reduce costs (energy)
Minimize cost of network access, SLAs
Satisfy QoS/QoE and energy efficiency requirements
Version 1.5
Page 39 of 95

Public
ISP
Offer new services
Satisfy SLAs, reduce traffic of peered links (peering costs), offer new services
Generate revenue from infrastructure, reduce peering costs, reduce energy costs, offer additional services Satisfy own QoE/QoS and energy efficiency requirements, reduce access costs. (Either monetary
Satisfy QoS/QoE and energy efficiency requirements, monetize service, offer new services (e.g. triple play)
End-user
Satisfy own QoE/QoS and energy efficiency requirements, reduce costs for services*
(Excluded by definition, interaction happens through Application Provider)
Satisfy own QoE/QoS and energy efficiency requirements, reduce costs*
flows or advertisement).
Analyzing the stakeholders interests, there are several candidates who might emerge as providers and users of global service mobility. As two axes of service mobility are considered, both axes are discussed separately. Horizontal Service Mobility: Provision of horizontal service mobility is interesting from an ISPs and application providers perspective. Application providers are interested in maintaining a good ratio of revenue and costs. An optimal placement of a service among a number of cloud providers or own Data Centers can help in optimizing costs as well as meeting end-users requirements. However, the optimal placement of services is also in the interest of the ISP to reduce his operational costs, as a disadvantageous service placement can increase traffic from outside the providers Autonomous System (AS). As the topological information and cost structure of the provider is hidden, an Application Provider cannot take this information into account, when placing services. On the other hand, the ISP can provide useful information to Application providers, e.g., a prediction of the QoS/QoE reachable for a certain placement of a service as well as the prediction of user movement. Thus, there is an asymmetric interest here, which can be utilized by SmartenIT, e.g., by using an ALTO style approach [9]. Vertical Service Mobility: Vertical service mobility can be provided by the entity providing end-users with uNaDa hard-/ and software. This can either be the end-user himself, buying a uNaDa from a hardware vendor or even an application provider or the ISP providing the uNaDa hardware to the end-user. Both models are conceivable, however we focus on the ISP-driven model for several reasons: First, the ISP is in a good position to roll out a NaDa system, as he usually provides end-users with subsidized home gateway hardware anyways. This model also offers the opportunity for the ISP to offer additional services to application providers and to provide an alternative cloud-like infrastructure, which offers additional capabilities like offloading. Especially with respect to offloading, the ISP can also increase his own mobile network coverage.
4.5.4 Financial Configuration The global service mobility scenario fosters offering new services to Application Providers by the Internet Service Providers. These new services are intended to create new
Page 40 of 95
Version 1.5

Public
business opportunities for ISPs and help in monetizing their infrastructures in times of shrinking revenue for fixed/mobile network access [10]. Figure 4-4 depicts the flow of services offered and purchased between the actors of the scenario, where existing flows are depicted by a grey pair of arrows and flows enabled by the global service mobility scenario are depicted in black.
Figure 4-4: Offered services and service purchases. With respect to the two types of placement, the horizontal placement of services is intended to reduce the operational costs of the Internet service provider (OPEX reduction), while the vertical service placement allows ISPs to generate revenue from offering access to the uNaDa infrastructure. We discuss both axes separately: Horizontal Service Mobility: As described beforehand, there is an asymmetric interest between ISP and Application Provider, which can be utilized within the scope of this scenario. If both parties share information, the Application Provider can achieve a better placement of services with respect to QoE/QoS and the provider can reduce traffic over peered links. Thus, this type of arrangement decreases the ISPS OPEX and increases the attractiveness of services offered by the Application Provider, generating mutual interest in cooperation. Vertical Service Mobility: Vertical Service Mobility is represented by the possibility to place services on the uNaDa layer. For this purpose, the ISP can offer a cloud-like interface, which allows the reservation of resources. A selling factor unique to the uNaDa solution is the capability of providing short latencies and offloading capabilities using WiFi. However, the end-user needs an incentive for participating with his uNaDa in this system. This incentive is generated from the value, a user can receive from having a uNaDa system at home, which offers increased QoE/QoS, e.g., by prefetching movies for which a user would have to wait, otherwise.
4.5.5 Technical Issues QoS/QoE: The requirements of the end-user have to be met for specific applications. Quality of Service can be measured easily, as there is a set of formally defined metrics available (throughput, delay, and jitter). Quality-of-Experience can be measured either by including active feedback from the user or using models mapping QoS to QoE. However, QoE measurement will be more application specific than QoS measurement. Energy Efficiency: Energy consumption is a metric to be minimized for all actors of the scenario. This metric can either be measured directly (in Data Centers and core routers) or model driven (on mobile devices).
Version 1.5
Page 41 of 95

Public
Service Performance: The service performance is dependent on the type of service offered. Assuming a caching service to be migrated, metrics like cache hit ratio and overall bandwidth savings may play a role. These metrics will be defined per traffic management mechanism to be implemented.
Figure 4-5: Service Placement Algorithm. As we assume a constant monitoring of these parameters anyways, monitoring components defined within the scope of the SmartenIT architecture can serve as sources of performance measurement. A necessity to realize a dynamic optimization process are at least a social monitoring component and an energy monitoring component, as the services managed by the system are to be placed depending on the current energy consumption and social interactions (see Figure 4-5). Social Monitoring: The service placement based on social interactions, where content may be popular in specific regions or with specific groups, but not in other regions or other groups, is highly relevant to SmartenIT. In particular mobile users affect the service placement, as events gather large groups of people with similar interests. In these cases, it is expected to be beneficial in terms of energy efficiency and QoS metrics to re-locate services with high relevance to the audience physically closer to the event. Energy Monitoring: To optimize the overall power consumption of the information communication technology infrastructure, measurements or estimations of the energy consumption of all participating network entities are necessary, including end-user devices. Still, the different importance of the energy consumption of mobile devices and the network infrastructure must be considered. Given the overall power consumption might be optimized by moving respective services to a nearby uNaDa, the feasibility of the placement must be considered. The overall energy consumption might be minimized, but the service quality might suffer due to the available bandwidth and delay. Also the connection quality of mobile devices must be considered, when optimizing the energy consumption. Interfaces remains
Page 42 of 95
Version 1.5

Public
powered up, if packets are frequently re-transmitted or transmissions hang, if packets are lost, leading to an increased energy consumption and poor performance on mobile devices. Hence, also intelligent scheduling on the end user equipment as well as offloading possibilities must be considered. With respect to security, the main concern is privacy of data. This is true for end-users, which do not want to reveal their prevalence on content, position and their social information, as well as for ISPs and Application Providers, who want to keep certain information (e.g. network topologies) hidden, as this information affects their business success. Application Provider: Application providers possess information on user behavior and often social information on their users. Especially social information is usually only made available to third parties through highly restrictive interfaces, providing an aggregated view only. Keeping users privacy is essential for this actor, as his business only works with a high level of trust of users in the services offered by Application Providers. Cloud Provider: As Application Providers are customers of Cloud Providers, the same considerations regarding privacy hold, i.e., the Cloud Provider has to ensure secure execution of service in his Data Centers and prevent the access of untrusted third parties. Internet Service Provider: Internet Service Providers want to keep the details of their network (topology, details on routing, peering point agreements, link utilization, etc..) hidden. End-user: End-users want to keep their privacy, i.e., the social information is to be kept locally or at trusted sites only. Untrusted third parties may access this information in an aggregated way, only.
The management of user identities in this context is to be defined in the context of D2.2 within the scope of traffic management mechanisms addressing global service mobility. Several ways of user identity management are possible, where a single sign on solution using identities from online social network platforms is likely to be adopted. Horizontal requirements in this scenario are very low, as cloud providers offer standardized interfaces/APIs. Thus application providers can easily pick cloud providers and/or Data Centers. An ISPs uNaDa platform can be integrated easily in this environment by adopting a cloud-like interface to enable Application Providers to make use of uNaDas. The vertical requirements of the scenario include the fostering of Application Providers/ISP interaction. We identified an asymmetric interest of both sides, which can kick start interaction; however, technological barriers like missing common interface definitions have to be overcome. Traffic management mechanisms touching vertical requirements have to ensure balanced interests and benefits of both parties. 4.5.6 State-of-the-art Limits As insinuated above, one of the main technical barriers will be the definition of a common interface for Application Provider/Internet Service Provider interaction. A second field offering technological limitations is the uNaDa layer. The SmartenIT project can build upon the work of the Nano Data Centers project [11]. As the global service mobility scenario adds several innovative aspects like offloading capabilities and social information, it is necessary to refine parts of the original Nano Data Center platform.
Version 1.5
Page 43 of 95

Public
The main limitations with respect to business barriers can be boiled down to two main requirements traffic management mechanisms addressing global service mobility have to fulfill: Provide appropriate long-term benefits (incentives) for all parties to foster adoption of the SmartenIT solution regarding OPEX/CAPEX and revenue. Keeping the costs for adopting new solutions low. This becomes especially relevant, if long-term benefit is small.
This implies a further investigation on asymmetric interests between Application Provider and ISP within the scope of the definition of use-cases within WP2 activities. Regarding uNaDas, the adoption is mainly a question of prices and the QoS/QoE benefit that can be drawn from a uNaDa. A cheap uNaDa hardware platform can help in fostering adoption. For ISPs offering uNaDa access, there might be a risk of competition from Application Providers trying to set up their own uNaDa platform. 4.5.7 SmartenIT Innovation The key innovations contributed by the global service mobility scenario are twofold. First, we add an additional service layer (uNaDas) to allow for not only vertical service mobility, but also for horizontal service mobility. The uNaDa layer allows placing services very close to end-users and offers offloading capabilities via a second WiFi interface, thus also taking the energy efficiency of mobile devices into account. Besides that, the optimization process of service placement takes social information and the energy-efficiency of placement into account. A side effect of new possibilities introduced by SmartenIT is an expected improvement of the perceived network quality on end user devices. This is achieved by locating services closer to the end user, reducing the delay and improving the network throughput. Further, uNaDas allow sharing the WiFi connection of home routers, supporting the cellular infrastructure in providing good network coverage and throughput. The improved coverage again leads to lower energy consumption on the mobile devices, further improving the QoE of the mobile user. With respect to business aspects, the scenario focuses on ISP/Application Provider interaction, which can help ISPs to compensate for shrinking revenues.
4.6 Exploiting On-line Social Networks Information Social Awareness

In online social networks (OSNs), users voluntarily provide information about their lives, especially about their current situation or exceptional events. Nowadays these so called social signals are ubiquitous and can not only be collected from OSNs (e.g., friendships, interests, trust relevant metadata), but also from applications (e.g., messaging or call patterns) and sensors (e.g., location). Social awareness harvests these signals, extracts information (e.g., users social relationships, activity patterns, and interests), and exploits them in order to improve a cloud service. In the field of traffic management, social information is utilized for example to avoid congestion, increase bandwidth, or reduce latency. In that context, social awareness links social signals and information such as social network structure, users' preferences and behaviours, etc. to network management mechanisms. This means that such mechanisms exploit the information in order to perform efficient network management, content placement, and traffic optimization to enhance the performance of an overlay application (e.g., video streaming, file sharing).
Page 44 of 95
Version 1.5

Public
Figure 4-6: Social awareness scenario for file storage and video on demand In Figure 4-6 the social awareness scenario for file storage and video on demand is depicted. The content is distributed over the physical network to the user. Information from the social information provider (e.g., an OSN) about topology and trust of users or demand of a content item can be used to cache interesting content in local caches. This can improve the QoE of an end-user by reduced access times, or reduce the cross traffic of an ISP by exploiting locality. With respect to a SmartenIT socially-aware traffic management solution, the consortium agreed to first investigate the exploitation of social information, i.e. to assume that perfect social information is available (from a black box social information provider). After relevant mechanisms have been developed, the focus shall be moved towards how the necessary social information can be collected or harvested. 4.6.1 Scenario Overview The complete and detailed instantiation across the template for inter-cloud communication scenario is given in Table 4-6. Table 4-6: Template instantiation for Social Awareness scenario.
Title Social Awareness Framework definition End users Application providers Actors Data Center operator providers Internet service providers Social information providers Video/music on demand Service overview File sharing/file storage Optimize traffic management by exploiting social information Service description Input from social information provider, e.g. Version 1.5
Page 45 of 95

Public
o Importance / influence of nodes o Access patterns (temporal, geographical) o Growth and decay of topics o Locality of users o Trust relationships Improve traffic management by: o Pre-fetching, caching o Data off-loading o Local access o Load balancing o Routing, request redirection QoE of end users QoS for cloud service providers QoS for Internet service providers Resources needed for application provider/cloud service providers Energy efficiency Amount of inter-AS traffic / transit-costs
Service Quality Interaction between actors Application Providers: Satisfy QoS/QoE and energy efficiency requirements of end user, minimize cost for infrastructure (network access and computation) Cloud Service Providers: Monetization of infrastructure (network, computation), reduction of costs (energy efficiency), satisfy application providers/end users needs Stakeholders interests ISPs: Increase revenue from infrastructure (network), reduction of cost (peered and transit links), satisfy QoS/QoE needs of cloud providers and mobile end users End users: Satisfy own QoS/QoE, minimize network access cost, minimize energetic expenditures for network access Social Information Provider: Provide/sell social information, gather more social information Application Providers: Paid* by end user for services Pays ISP for network access Pays cloud providers or DC provider for access to infrastructure (storage, computation) Pays social information provider for end-user information Cloud Providers: Stakeholders relationship Paid by application provider for infrastructure (computation, network, storage) Social information providers Paid* by end user Paid by application provider, cloud service provider, ISPs for end-user information ISPs: Provides network access to customers (Data Center Operators and end users), thus monetizing own infrastructure Pays social information provider for end-user information End users: Pays* application and cloud providers and ISPs for service/network access to satisfy own QoS/QoE needs (*) Either using money or advertisement 1. Provider-based content delivery The cloud service provider is paid by the application provider
Financial configuration Revenue model
Page 46 of 95
Version 1.5

Public
The application provider may pay a cloud service provider to buy storage capacity and an ISP to buy connectivity between his Data Centers as well as to employ the ISP's cache/proxy server The social information provider also pays a cloud service provider to buy both storage and computation. The application provider is paid by an end-user. In a socially aware context, the cloud service provider may pay the social information provider, to get social information and metainformation by the latter. The social information provider might earn money by end-users using its service (e.g., service fees, advertisement)
Cost Model Technical issues Performance Measurement
2. Peer-assisted content delivery Compensation of the end-user for sharing his bandwidth, storage and computational power. Compensation either monetary, or performance-related. Cost reduction for Cloud service Providers and Application Providers Possible cost reduction for ISP (CAPEX/OPEX due to inter-domain traffic reduction) Comparison of service quality metrics with and without social awareness mechanism. Main metrics include: Resource utilization Cache hit-rates Traffic savings, transit cost savings for ISP Social information can contain sensitive user data Provided by social information provider or cloud service Interactions (sharing) between end users
Security Horizontal requirements Vertical requirements
Social information has to be used by application providers (i.e., integration into service/overlay), cloud service provider, or ISPs. State-of-art of actual technology Collection of social information: crawling might not be feasible Technological barriers Limited intervention potential of YouTube CDN (Content Delivery Network) Incentive mechanisms for provision of social information have to be Business barriers developed Risks No risks identified for the selected scenario SmartenIT progression beyond the state of art SmartenIT solution will exploit social information to efficiently manage Key innovation overlay traffic which will result in a higher service quality.
4.6.2 Framework Definition Each of these actors can benefit in different ways from social awareness, i.e., optimized traffic management based on the exploitation of social information. Therefore, the providers of this social information like online social networks play a central role in this scenario and are considered as a separate actor. Much different information about end users, e.g. their importance and influence, their temporal and geographical access patterns, and their relationships, can be utilized. Moreover, information about popularity growth and decay of content can be extracted from social networks. This leverages the improvement of traffic management mechanisms such as caching, data offloading, or load balancing. With respect to a SmartenIT socially-aware traffic management solution, the consortium agreed to first investigate the exploitation of social information, i.e. to assume that perfect
Version 1.5
Page 47 of 95

Public
social information is available (from a black box social information provider). After relevant mechanisms have been developed, the focus shall be moved towards how the necessary social information can be collected. Regarding considered services, the consortium selected two very popular services, i.e. video/music on demand and file sharing/file storage (cf. Chapter 3). The quality of these services has to be measured separately for providers and consumers. Thereby, it is important to look at QoS and needed resources for cloud and network operators and to look at QoE for end users. However, energy efficiency is a central metric and should be considered at all times. 4.6.3 Interaction between Actors Five actors can be identified within the social awareness scenario. The interactions of application providers, cloud providers, Internet service providers, end users, and the social information provider are partly similar to the descriptions in Sections 4.4.2 and 4.5.3, but the main aspects for this scenario will be outlined in this section. The application provider is interested in monetization of offered services, and that includes reduction of ISP infrastructure and cloud resource consumption costs. Satisfaction of end users is a crucial issue. To ensure this goal the QoS/QoE requirements should be met as well as the energy efficiency requirements. QoS/QoE parameters for services may be improved and also new services may be offered if social information is collected and used. It can also be used to reduce infrastructure costs if social information is exploited to reduce the utilization of resources. Exchange of social information may be therefore beneficial for all players. The Cloud provider is mainly interested in monetization of infrastructure, and reduction of its costs. Monetization of infrastructure is done by fulfilling Service Level Agreements and therefore guaranteeing satisfactory QoS/QoE parameters for end users. Reduction of costs, in case of cloud providers, focuses on best possible utilization of hardware both resource-wise and energy-wise. As it depends on ISP to provide network access this stakeholder will seek the best Service Level Agreement conditions for itself. The Internet service provider is interested in revenue from its infrastructure. This can be increased by high quality of network services that translates into satisfaction of cloud providers and also of end users. Supporting new services, possibly by employing social information, may be attractive for application providers and simultaneously make ISP more competitive towards end users and cloud providers. Such new services can also enable reduction of costs, by both more efficient use of own resources and keeping transit link traffic as low as possible. The end users main concerns are its own QoS/QoE, network access cost and energy consumption. This stakeholder is rather not involved in other stakeholders interaction s, being primarily a client of ISP and Application Provider. It is noteworthy, that costs in case of end user often can be expressed by being exposed to advertisements instead of being involved in monetary flow. Typically the end user will not be interested in disclosing social information directly; however it may be willing to give it up for profit or improved QoS/QoE. The social information provider wants to make money with its social information. Therefore, it can provide or sell the social information to application providers, cloud service providers, or Internet service providers. If the information can be used to improve a service, this creates incentives for end-users to provide information to the social
Page 48 of 95
Version 1.5

Public
information provider. If the social information provider offers a service itself like an online social network, these incentives lead to a higher number of users which can also increase revenue (e.g., advertisement) of its service. 4.6.4 Financial Configuration In this section, the financial configuration of the social awareness scenario is discussed. As an example, a video on demand application is used; however, all statements also apply to file storage applications. In the case, where the content delivery is performed by a video platform owned by a CDN Content Distribution Network), e.g. YouTube, then usually, the CDN Provider is paid by the Content Provider to replicate the latter's content in multiple servers close to the End-Users. The CDN Provider, then, can pay a Data Center Operator to buy storage capacity in the latter's Data Centers, while he can also pay an ISP to employ the ISP's cache/proxy server to diminish the distance to his End-Users. Similarly to the CDN case, the OSN provider also pays a Data Center Operator to buy both storage and computation. Moreover, a Content Provider can be paid by an End-User; specifically, the End-User may login using his unique credentials in the Content Provider's portal and rent movies from it paying with a credit card, e.g., the Netflix and Hulu cases. In a socially aware context, the CDN may pay the OSN Provider, i.e., provide him monetary incentives, so as to share with the former one, social information and meta-information about his End-Users. On the other hand, in the case of peer-assisted content delivery, similar revenue and sharing models apply, as well as similar money flows are expected as in the previous case. Nevertheless, the End-User must be compensated for sharing his bandwidth, storage and computational power. Compensation could be either monetary, e.g., reduction of price charged for connectivity services, or performance-related, e.g., upgrade of the User's access speed/package, or service-related, e.g., provision of an extra service such as free access to the IPTV/VoD (Internet Protocol Television/Video-on-Demand) platform. In the case, where the content delivery is performed by a video platform owned by a CDN or a Data Center Operator, inter-connection costs may be imposed by the Transit ISP to the Data Center Operator or the CDN for connecting his Data Centers. Additional costs may also be incurred for the CDN Provider due to the provision of local cache/proxy server by the ISP, and the social information potentially made available by the OSN provider. In the peer-assisted case, an extra cost may be inferred for the CDN as he may be obliged to compensate the End-Users for providing their resources for the delivery of non-User Generated content. Moreover, although the transit costs will be mitigated both for the CDN Provider and the edge ISP by the peer-assisted content delivery; OPEX might increase for the ISP due to the extra traffic in his network. 4.6.5 Technical Issues In the following paragraphs the technical issues of the aforementioned scenario are presented. Initially, the metrics to measure and co mpare the scenarios performance to real world cases are discussed, along with security and user identity management issues. Performance measurement metrics are mostly related to QoE, QoS and energy efficiency and required monitoring is different per actor: End users are interested in consuming high quality content without experiencing any technical issues. Hence, their QoE relies on the quality of the provided service, and more specifically, download times in the case of cloud storage service, and delay, packet loss and jitter in the case of video/music streaming. An embedded application in the end user device could perform these measurements, as well as consumed energy
Page 49 of 95
Version 1.5

Public
and consumers preferences and feedback, to compare the scenarios performance in the end-user level. Network service providers generally seek for services that reduce their traffic and costs and increase their revenue. Reduction of transit traffic and costs is also critical for tier-3 providers. Certain measurements have to be performed in the providers network equipment to identify their gains from the scenarios mechanisms, such as intra domain and transit links bandwidth and congestion, network and server equipment energy measurements, and cache servers hit and miss ratio. High quality services, revenue and end-users base are the main interests for application and Data Center Operators. Along with the measurements the end-user and network level, as described above, end-to-end monitoring of the application characteristics could be performed, such as requests time, latency and packet loss, and servers hit ratio and consumed energy.
Security is a crucial issue for all the scenario actors, and especially the end users. Social information sharing for the purposes of the scenario could expose end users sensitive information to external parties. Hence, it must be ensured that only the required information must be retrieved from the social network provider and shared between all the involved actors (end user-end user, end user-network provider, and end usercloud/application provider). In the case of WiFi sharing another important issue is the secure access to end user gateway. Users sharing their WiFi must be ensured that their internal network will be securely separated from external access, perhaps using VPN or firewall, and that their Internet connection and services will not be affected or harmed. The same measures apply to users connecting to share WiFis. Cloud and application providers should also take measures to manage and maintain the security and privacy of their services from spoofing, denial of service and other types of security attacks. User identity management is another important aspect, closely related to the security measures described above. End users could share and exchange their social information through existing social networks, while scenario-related information and notifications could be provided through the same networks. However, this solution has the disadvantage that this sensitive information could be exposed to other users or parties. Another solution would be the creation of an application, either on top of such social networks, where users could log in using their existing accounts, and then share their data securely only to other certified application users, or as another social network, explicitly targeting users interested in the scenario offerings. In the latter case however, the user base would be limited, resulting to minimal gains for the scenario. The horizontal requirements include the secure sharing of social and access information between end users, in order to access others network devices. Another important aspect will be the mapping of the existing user identities in a social network with the internal identities of the overlay formed (e.g., on a uNaDa level). On the other hand, the vertical requirements include the sharing of essential social information from the social network provider to the cloud and application providers, and the utilization of resources between either network providers, or network providers and cloud and application providers, to handle content pre-fetching and social-aware routing. 4.6.6 State-of-the-art Limits The scenario presents a certain number of practical limitations which can potentially limit the major outcomes of SmartenIT project. One of the main assumptions of this scenario is
Page 50 of 95
Version 1.5

Public
that social network provider are meant to monetize social information which could expose end-user sensitive information to third parties. Then, the first barriers are related to privacy and security limitations as exposed in the above technical issues (see Section 4.6.5.). From a point of view of the technological limitations, the first concern is the provision of privacy and security mechanisms and protocols on social information shared between all the stakeholders that will guarantee the exposure of only authorized information and that will respect the privacy of the end user information. A second concern arises related to the ability of collecting sufficient statistics of social information. The third concern is related to the complexity of exploiting such large dataset within a given time frame. From a business point of view the main risk arises from the lack of incentives mechanism for providing social information. The cloud service provider may pay the social information provider to get social information and meta-information by the latter under the condition that the improvement brought by social information aware traffic management or caching policies allows him to spare CAPEX (Capital Expenditure)/OPEX that will compensate the expense to obtain social information. Furthermore regulation aspect on privacy rights of end user might lead to insufficient social information which prevents a business deployment of a socially-aware traffic management solution. 4.6.7 SmartenIT Innovation The innovation of SmartenIT in the considered scenario lies in designing traffic management mechanisms that will handle the large volumes of traffic generated by video delivery, file storage and social networks, employing not only users interests but also social information as a new channel of information to characterize them and predict their behaviour, and by addressing the incentives of all involved stakeholders, i.e. Data Center operator, Cloud application Provider and Internet Service provider.. Specifically, the key innovation of SmartenIT is mainly related to the following key topics: Reduction of traffic on expensive inter-domain links and redundancy of content replication, Use of content caching, pre-fetching and placement techniques to assist video delivery, Building on a P2P-based (peer-to-peer) overlay based on users behaviour, i.e. requests, based on the social graph, their social activity and interests, to assist video delivery, e.g., uNaDas, Enhancement of Quality-of-Experience as perceived by end-user. QoE metrics are measured on end-user domain and used to drive decision by SmartenIT traffic management component. A SmartenIT mechanism could be seen so far as a set of architecture/functional elements embodied within the aforementioned stakeholders. Alternatively, such a module could be employed by a new entity, e.g., an OTT Provider (Over The Top), and placed among the existing stakeholders, so as to collect social information and provide it to the Cloud or the NSP, or the end-users themselves in the peer-assisted setup. Thus, the SmartenIT pointof-intervention can be either a module or "box" within the entity employing the mechanism, which would be responsible for coordinating with other similar "boxes" within other entities, and ultimately, communicating with the Content Provider. Alternatively, in the OTT Provider case or the peer-assisted one, the SmartenIT point-of-intervention is the role played by the OTT or a tracker orchestrating the P2P overlay. Of course, even in such a case, specific "boxes"/modules are necessary within the CDN and ISP, which will constitute the interfaces for the orchestration with the OTT/tracker. In all cases, alignment
Version 1.5
Page 51 of 95

Public
of the stakeholders' incentives regarding the exploitation of social awareness for content delivery is required for the adoption of such a solution by the market.
4.7 Collaboration for Energy Efficiency

Federation of clouds or Data Centers along with workload or data replication and live migration of virtual machines offer new effective ways to manage and optimize energy consumption individual for each Data Center (or Cloud) operator and overall for all members of the federation. This allows establishing new energy saving policies and procedures dealing with energy demand patterns of Data Centers and collaboration with energy producers. Apart from energy saving, also the exploitation of renewable energy sources may have high priority. Federated small/medium Data Centers or clouds are assumed by SmartenIT to have not only technical standardization and perform exchange of information, but are also considered to seek common goals and act as a larger virtual cloud. Thus, they create a decentralized energy ecosystem where the workload can be exchanged to address energy shaping requests from the Energy providers, economical demands (lower costs of energy in certain locations) or prioritizing access to stable renewable energy sources. Advanced adaptive power consumption requires close collaboration between Data Centers and Energy providers [2]. Normally the Data Centers are treated as common business customers expecting high level of energy but to achieve valuable benefits this relation has to be enriched. There are already efforts introducing interfaces between those two sides to share the information and dynamically adjust power consumption. The information about energy consumption and related implications can be included in SLAs between users of cloud services and Datacenter operator. Reduction of energy consumption profile of the users of the cloud services, e.g. by use of cloud services in offpeak hours, could be compensated by Datacenter operators with discounts or other benefits in order to achieve high optimization and thus lower energy consumption in their datacentres. Additionally, business agreements and SLAs including energy consumption aspects could be established between Datacenter operators for data and load migration and access to distributed energy sources
Figure 4-7: Collaboration for energy efficiency scenario. Figure 4-7 illustrates the federation of three Data Center Operators, each of which owns and controls two Data Centers. Additionally, the users of the cloud services, i.e. application providers, content providers, or end-users, and the energy provider are seen,
Page 52 of 95
Version 1.5

Public
representing the cloud traffic demand, and the energy supply respectively. The role of the Network Service Provider is considered central as one of the main targets of this scenario apart from reducing energy consumption, is also reducing inter-domain traffic; thus, its role separately depicted in Figure 4-8. In order to meet the traffic demand and simultaneously, reduce or maintain the energy supply, a traffic management mechanism is required to handle, e.g. data replication/migration among the federated parties.
Figure 4-8: Collaboration within Datacenter Operators Federation (focus on network layer). 4.7.1 Scenario Overview The complete and detailed instantiation across the template for inter-cloud communication scenario is given in Table 4-7. Table 4-7: Template instantiation for Collaboration for Energy efficiency scenario.
Title Collaboration for Energy Efficiency Scenario objective The collaboration for energy efficiency scenario focuses on the interaction between federated Data Center Operator entities acting in a multi domain operation topology to achieve energy efficiency. As aforementioned, the scenario is focused on a federation of clouds in which different Data Center Operators (or Clouds) join together in a super-cloud entity to allow resource sharing between the different cloud players with the final aim to deliver service with expected SLA to cloud service users, expected SLAs among them and ultimately low overall (and individual) energy consumption. The main topics of the selected scenario are: The interaction of the federated Data Center Operators with the underlying connectivity infrastructure offered by Internet Service Providers (ISPs). The interaction of the federated Data Center Operators with each other. SmartenIT potential of traffic optimization/resource selection to allow energy efficiency and QoS/QoE enhancements. Business relationships analysis. SLA impacts in the interaction among different players. Framework definition Data Center (or Cloud) operator: merged role of Data Center operator and IaaS Actors Provider, i.e., it owns and manages one or multiple Data Centers
Version 1.5
Page 53 of 95

Public
Internet Service Provider (ISP): offer access and connectivity service (both access and backbone) over both public and private networks. Users can be divided in two categories: o Business/corporate end-users: IT Companies mainly interested in purchasing pure IaaS/PaaS services (e.g., Computing, Storage) o Residential users: private users who purchase cloud services for entertainment and content sharing purposes Cloud service providers: Application/Content/OTT providers, which offer software or application services to end-user, e.g. SaaS Energy providers: merged role of Energy Plant Owner and Energy Distribution Network Provider, i.e., it provides power (electricity) to Data Center Operators (we ignore here ISPs as customers of Energy providers) Energy Broker: new role; orchestrate the collaboration between the Data Center Operators to achieve energy efficiency, map demand (load) to supply (resources) to meet (low) energy requirements (overall and/or individually) Applications (services to end-users): o Video streaming (VoD and LiveTV): e.g. YouTube, NetFlix, Vimeo o Online storage: e.g. Dropbox, Zettabox Services to providers: Service overview o IaaS: storage, hosting, e.g. Virtual Data Center (VDC) resources offers to content providers, or PaaS/SaaS providers (e.g., Amazon S3 supporting storage functionalities of Dropbox) o PaaS: computing (i.e. VMs) offered to research centers to perform simulations of large datasets, banking institutions to perform transactions SLA o Between Data Center operators (vertically, e.g., IaaS - PaaS) o Between Data Center operator and Cloud service provider o Between ISP and Data Center operator o Between Energy provider and Data Center operator SLAs o Between Data Center operators (horizontally, e.g., IaaS IaaS) Service Quality QoS for ISPs, Data Center Operators, Cloud service providers o End-to-end QoS (Latency, Jitter, RTD, Throughput, Packet Loss) as the quantitative measure of the end-to-end path performances. QoE for end-users o QoE as a sum of non-homogeneous parameters ranging from user satisfaction, service availability, service content, energy efficiency of user end terminal. Interaction between actors Increase revenues from inter-connection of cloud ISP providers; low network cost; optimized network bandwidth utilization (expected traffic patterns) Provide high QoE to users; reduce OPEX (i.e., interconnection costs, energy costs); improve his servers Data Center Operator utilization; avoid / limit congestion on his links/platform; limit energy consumption by his servers Stakeholders interests Meet energy demand, eliminate outages; reduce OPEX Energy provider including transmission costs; increase revenue Cloud service provider Enjoy high QoE, availability, etc. as dictated by the (Application/Content/OTT established SLA; reduce OPEX (i.e., cost for IaaS/PaaS provider) service) Enjoy high QoE as dictated by the established SLA; End-user enjoy high bandwidth and reduce energy cost Contrasting interests (non-homogeneous stakeholders) Stakeholders o The Data Center Operator will share resources among federation utilizing relationship WAN links of the ISP. The ISP wants to maintain as low as possible the link utilization.
Page 54 of 95
Version 1.5

Public
The Data Center Operator wants to operate some traffic management for traffic directed over the links of the ISP. o The ISP aims to maintain as low as possible traffic on transit links, wants to achieve an optimization of its resources (avoid links congestion, energy efficiency). o The Data Center Operator may target to achieve low energy consumption by consolidating all load in one location, which might have negative impact on the QoS of the Cloud service provider. o The Energy Broker aims to achieve overall energy efficiency within the federation. In short time scales, one member of the federation (Data Center Operator) might see his individual energy consumption increased. Competitive interests (homogeneous stakeholders) o Different ISPs not willing to cooperate. o Different Data Center operator not willing to form federation. o The Data Center Operator will share resources and bare the load initially destined to another member of the federation. Cloud service provider: pay-per-use model, free access with basic capabilities, monthly/weekly subscription access with enhanced capabilities, flexible form of payments based on service bundles. Data Center Operator: pay-as-you-go model, monthly/weekly subscription ISP: pay-as-you-go model (95% rule), monthly/weekly subscription, peering/transit options with other ISPs, peering with IXP. Energy provider: o Time-of-Use (ToU): customers pay different prices at different times of the day, while on-peak prices are higher and off-peak prices are lower than a standard rate. o Critical Peak Pricing (CPP): very high critical peak prices are assessed for certain hours on event days (10-15 hours yearly). Cost reduction for Cloud service providers and end-users Cost reduction for Data Center Operator in the federation (due to connectivity and energy consumption) Cost reduction for ISP (due to reduced inter-cloud traffic)
Financial configuration Revenue model
Cost Model Technical issues
Performance Measurement
Security
ISP Inter-AS and inter-domain traffic Intra-AS traffic End-to-end QoS metrics: Congestion on links Delay Hops Data Center Operator: End-to-end QoS metrics Energy consumption based on traffic/work load, time of use, peak hours, etc. Energy provider None (we do not focus on the performance metric of the Energy provider, as it is not considered to be a stakeholder that makes any decision) Cloud service provider End-to-end QoS metrics End-user QoE (cumulative of qualitative and quantitative parameters) Agreement on access to customers private data within the federation. Agreement on common security framework within the federation. Federation should take into account different security legislation in different countries.
Version 1.5
Page 55 of 95

Public
Horizontal requirements
Vertical requirements
Encrypted traffic (VPN, tunneling). Free-riding between Data Center Operator; User identity management the application/content provider offering a service to end-users; a unique interface must be provided to the end-user by the Cloud service provider, while migration of the service that is delivered to him from a Data Center Operator to a different one must be transparent. Interactions between data center operators: Proper protocols/agreements between Data Center Operators to join the federation and to exchange relevant data for resources sharing o IaaS IaaS o PaaS PaaS Interactions between ISPs: Peering, transit agreements Cross-layer interactions ISP Data Center operator Data Center Operator Data Center Operator (IaaS PaaS) Data Center Operator Cloud service provider Data Center Operator End-user Cloud service provider End-user
State-of-the-art limits Technological ALTO/inter ALTO protocol non-fully developed for SmartenIT purposes barriers Data Center Operators may not be willing to form a federation, cooperation needed, incentives need to be provided In the case of introducing a new entity, i.e., the Energy Broker, who will control it; collaboration needed again Business barriers Relationship of energy consumption to workload; is it linear? Relationship of energy cost to workload; is it linear? Better to keep low load in many Data Centers, or fully utilize a few and keep others down? Risks Free-riding of a Data Center Operator; accountability issues SmartenIT innovation Design an either distributed or centralized mechanism to make decision on where, i.e., in which cloud/Data Center within the federation, workload should be allocated at some time (e.g., on a per minute, hour basis) to keep low overall Key innovation and individual energy consumption cost. Target: energy efficiency.
4.7.2 Interaction between Actors The ISPs are interested in increasing revenues from providing inter-connection of Data Center Operators, and OTT Providers; additionally, they are interested in providing their end-users Internet services with high QoE so as to assure that their loyalty, sustain their revenues due to Internet access services and increase them by offering new services to their customers. Simultaneously, they are interested in maintain their network in good shape by optimizing the network bandwidth utilization high, while avoiding congestion and preserving low latency. The Data Center Operator is interested in providing high QoE to his customers, i.e. OTT or end-users, while reducing its operational costs (i.e., inter-connection costs, energy costs). In particular, it aims to improve the utilization of its servers, to avoid or limit congestion on its links and platform; as well as to limit the energy consumption by its Data Centers.
Page 56 of 95
Version 1.5

Public
The OTT Provider aims to provide high QoE, availability, etc. as dictated by the established SLA to his customers, i.e. end-users, while simultaneously to reduce its operating costs, i.e., cost for buying IaaS/PaaS service, Internet connectivity, etc. Concerning the relationships between pairs of the identified stakeholders, we distinguished those to two categories based on the nature of the interests, i.e., contrasting or competitive ones. Specifically, we identify the following relationships: Contrasting interests (non-homogeneous stakeholders) o Data Center Operator will share resources among federation utilizing WAN links of ISP. Internet Service provider wants to maintain as low as possible the link utilization. o Data Center Operator wants to operate some traffic management for traffic directed over ISP links. o ISP wants to maintain as low as possible traffic on transit links, wants to achieve an optimization of its resources (avoid links congestion, energy efficiency). o Data Center Operator may target to achieve low energy consumption by consolidating all load in one location, which might have negative impact on QoS of the OTT. o Energy Broker aims to achieve overall energy efficiency. In short time scales, one member of the federation (Data Center Operator) might see his individual energy consumption increased. Competitive interests (homogeneous stakeholders) o Different ISPs not willing to cooperate. o Different Data Center Operators not willing to form federation. o Data Center Operator will share resources and bare the load initially destined to another member of the federation. SmartenIT will address the contrasting and competitive interests of the various stakeholders and will overcome those limitations by offering some form of incentives, e.g. reduction of cost for ISPs and Data Center Operators, in terms of inter-domain traffic and energy consumption respectively, QoS for OTT providers, and QoE for end-users. 4.7.3 Financial Configuration The revenues of the Cloud service provider may be based on a pay-per-use model. Alternatively, customer could be provided with free access to cloud services offering basic capabilities, while enhanced cloud service could be charged a monthly/weekly subscription. Additionally, bundles of cloud services could be provided, e.g. storage and content management for a content provider, employing flexible form of payments or discounts. Similarly, the Data Center Operator can employ either a pay-per-use model, or more often a weekly/monthly subscription for specific service characteristics, e.g. TBs of storage, CPU cycles. ISP: pay-as-you-go model (95% rule), monthly/weekly subscription, peering/transit options with other Internet Service providers, peering with IXP. Energy provider: o Time-of-Use (ToU): customers pay different prices at different times of the day, while on-peak prices are higher and off-peak prices are lower than a standard rate. o Critical Peak Pricing (CPP): very high critical peak prices are assessed for certain hours on event days (10-15 hours yearly)
Version 1.5
Page 57 of 95

Public
4.7.4 Technical Issues This section presents a set of technical issues which are specific to the aforementioned scenario. Due to the federation nature and presence of close collaboration of distributed and independent stakeholders the scenario is similar to the inter-cloud communication scenario; therefore issues of the inter-cloud scenario (discussed in Section 4.4.4) are relevant to this scenario as well. The focus here is on the energy efficiency and the use of renewable energy sources. One of the challenges faced by SmartenIT is collecting energy consumption statistics, aggregating them, storing and sharing among stakeholders in a standardized manner. This should include privacy policies, which means that stakeholders can control what and how the information is shared (because of some reasons, e.g. business ones, stakeholders should be able to hide, or transform into a more general format, a set of confidential information). An information model to organize energy consumption statistics and related metadata should be flexible for a system proposed by the SmartenIT project. Available standardized or well-known solutions should be analyzed. Another challenge is establishing the communication channel between Data Center Operators and Energy providers. This is required to create a decentralized energy ecosystem where energy consumption is fully controlled and managed dynamically. Such approach is especially promising to increase the use of renewable energy. Procedures and formats how the SLAs are established between stakeholders in the outline ecosystem have to be considered. Moreover, free-riding between Data Center Operators must be avoided. Specifically, a Data Center Operator may push load generated by his customer, i.e. a Cloud service provider, to other Data Center Operators within the federation, while there is availability and low energy consumption in his Data Centers. Appropriate pricing of off-loading data/workload will allow avoiding such free-riding effects. Finally, regarding user identity management the application/content provider offering a service to end-users, a unique interface must be provided to the end-user by the Cloud service provider, while migration of the service that is delivered to him from a Data Center Operator to a different one must be transparent. 4.7.5 State-of-the-art Limits The main limitation identified at the moment is the lack of standards and business interest to introduce an advanced dynamic management of collaboration between Data Center Operators and Energy providers. Nowadays, the energy consumer does not have the information from Energy providers that could allow him to manage energy consumption in a decentralized energy ecosystem. Unfortunately, it is not expected to find by SmartenIT in the coming one or two years an Energy provider willing to jointly work on the concept of communication channel. 4.7.6 SmartenIT Innovation In this scenario, SmartenIT will design and specify traffic management mechanisms to efficiently perform exchange of workload between storage and computational resources in different Data Center operators, at low operational cost, in terms of both inter-connection costs and low energy consumption, simultaneously assuring high users QoE. The traffic management mechanisms to be specified will comprise simpler, yet effective traffic
Page 58 of 95
Version 1.5

Public
management mechanisms such as alternative route selection, scheduling, etc. combining them also with economic and performance (i.e. QoS/QoE) criteria. The SmartenIT service in this scenario will employ traffic, energy and economic information as input variables, aiming at: (a) minimizing energy consumption by the cloud / data center, (b) optimizing traffic in operators networks, , and (c) offering resource scheduling services in an environment of a cloud federation. These targets can be achieved through a series of SLAs between different providers (as well as OLAs between different Data Center Operators) and traffic management mechanisms in the value chain that enforce the desired routing, energy efficiency and QoS attributes on an end-to-end deterministic or statistical basis. A SmartenIT mechanism could be seen as a set of architecture/functional elements embodied within the aforementioned stakeholders, or placed as an extra entity among them, so as to coordinate and enforce the collaboration for the efficient energy consumption behaviour among all players. In the first case, the SmartenIT point-ofintervention would be a module or "box" within the entity controlling the data centre, which would be responsible for coordinating with other similar "boxes" within other Data Centers, and ultimately, communicating with the Energy provider. Alternatively, the SmartenIT point-of-intervention could be a new entity, specifically the Energy Broker, who will be responsible for orchestrating the energy consumption by the involved parties, e.g., Data Centers and gateways. Of course, even in such a case, specific "boxes"/modules are necessary within the Data Centers, which will constitute the interfaces for the collaboration with the Energy Broker. This view is fully supported by actual SmartenIT architecture (as depicted in [56]) which has been designed with a certain degree of flexibility in order to allow for external interfaces.
4.8 SmartenIT Scenario Consolidation and Final Refinement

The four scenarios identified so far have been described as separated individual scenarios. Nevertheless some consideration can be taken regarding possible refinement in scenario description, due to the synergies and overlap among the scenarios, as indicated also by the previous analysis made on them. In particular, the following aspects should be considered: The scenarios have been described starting from the identification of a group of main features characterizing the scenario themselves (Inter-cloud communications, Service mobility, Social awareness and energy efficiency). From a certain point of view those scenarios cannot be positioned on the same logical level: some of them can be seen as a trigger and other as an effect of interactions within the cloud ecosystem and also some of them can be considered as features complementary to the other scenarios described. In that sense Social awareness can be seen as a trigger (social awareness information are used to derive actions on traffic management and content placement) of service mobility aspects that are present in all scenarios. Other important triggers can be identified in user mobility and energy efficiency. In such a framework Inter-cloud communication can be seen as an effect of interaction among different clouds triggered by user mobility or Data Center Operators driven by energy efficiency considerations. The scenario description activity (WP1) is very closely related to use-case definition activity (WP2). A preliminary work on use-cases demonstrates that there are a certain number of use-cases that clearly are overlapping across the different scenarios: o Use cases related to caching/prefetching of content across the cloud
Version 1.5
Page 59 of 95

Public
o Use cases related to resource allocation among different clouds or Data Centers o Use cases related to energy efficiency considerations The role of the end-user is of the utmost importance within all the scenarios, even if there are scenarios where the user is a mere stakeholder (only purchasing a service) and scenarios in which the user is actively participating with other actors within the scenarios.
The abovementioned considerations are explicitly depicted in Table 4-8, where all key issues relevant for each scenario are described. Table 4-8: Key issues and relevant feature of SmartenIT initial scenarios.
Scenario Inter-cloud communication Cloud service provider, Data Center Operator, Internet service provider. Effect of interaction with Cloud (e.g. triggered by user mobility, energy efficiency). Energy efficiency Data Center Operator, Internet service provider, Energy Broker. Social Awareness Social information provider, End Users, Cloud Application Provider, Internet service provider. Triggers interaction with Cloud. Can be utilized in other scenario (SAW scenario). Global service mobility Cloud Application Provider, Internet service provider, End users, (Data Center operator). User mobility triggers interaction with the Cloud Present in all scenarios Placement of services horizontally (e.g. among Data Centers or NaDa) and vertically (from Data center to NaDa). ISPs assists Cloud Application provider in offering global service mobility. ISP provides incentives to users to provide resources (uNaDa). Energy efficiency and Data Center level, ISP core network, (mobile) end-user QoE enhancements for end-user.
Main actor
Interaction with Cloud
Triggers interaction with Cloud.
Key feature
Formation of Cloud Federation. ISPs deploy special TM solutions. Leveraging information asymmetry between ISP and Data Center Operator.
Interaction of federated Cloud for Energy efficiency. Resource scheduling within the federation.
Leveraging on Social Information for traffic management Provider-based or peer-assisted content delivery Traffic management e.g. pre-fetching, caching trusted data offloading.
Main Goal for traffic optimization
Cost savings and energy efficiency for ISPs and for Data Center Operators.
Cost reduction for Cloud Service Providers, endusers and ISPs (due to reduced inter-cloud traffic).
Cost reduction and energy efficiency for Data Center Operators (possibly for ISPs) Enhancements of QoE and energy efficiency at enduser.
All considerations taken so far identify a certain number of aspects that exhibit synergies and overlaps among the four initial scenarios. To this end, the SmartenIT consortium, after internal discussion, has agreed to present a refinement of the scenarios by presenting two final macro-scenarios with the following purposes:
Page 60 of 95
Version 1.5

Public
Ease the future work on use-case by offering two final scenarios with consolidated characteristic and non-overlapping features, to narrow down the scope of usecases, exploit complementarities, mitigate overlaps and duplicated work and properly drive future WP2 activities. Enhance the deployability and re-usability of SmartenIT solution to be offered as a service to Internet Service Provider and Data Center Operators, since in real-world deployments the complementarities of different scenarios would also be present in actual business cases of market value and interest. Offer a more consolidated point of view on economics and business interactions within the scenarios by shifting scenario focus on wholesale market (network and Data Center operators) and retail market (end-user point of view).
The strategy for merging the scenario and properly derive the description of the two final macro-scenarios can be identified in the following: Each of the four initial scenarios identify a key feature which describes from the selected point of view proper interactions among the selected actors The two final macro-scenarios are identified by proper mix of already described key features and classification to the wholesale or retail market respectively.
The resulting macro scenarios are: (1) Macro-scenario-1, focused on Cloud/Data Center/Network Operator point of view of interaction within primarily the cloud ecosystem (2) Macro-scenario-2, focused on end-user point of view of interaction within the cloud ecosystem All relevant information related to selected final scenario are conveyed to Table 4-9, where all the properties that the two final scenarios inherit from the four initial scenarios are demonstrated. Table 4-9: Key issues and relevant feature of SmartenIT final scenarios.
Operator focused scenario Data Center Operator, Main actor Internet service provider, Energy Broker. Market Wholesale market Federation of Data Centers Fair optimization of the resource of its infrastructure Key feature Interaction between Data Center operator and ISP Mobility of services and contents across Cloud Federation Potential leveraging on Social Awareness information Major goal of traffic optimization Cost, energy efficiency for Data End-user focused scenario Social information provider, End Users, Cloud Application Provider, Internet service provider. Retail market Mobility of users, service and contents Will utilize Social awareness Improved content delivery and placement Traffic management by allowing for pre-fetching, caching and data offloading
QoE enhancements for end-user
Version 1.5
Page 61 of 95

Public
Center Operator and ISP
Energy efficiency for end-users
SmartenIT solution
Deployed at the administrative interface separating DC Operator and ISP.
Involvement of end-user in the deployment of SmartenIT solution via uNaDa.
In the following paragraph the resulting macro-scenario will be described, their key features and their relationships with constituent initial scenario will be highlight. The description will be focused on actors interactions and economic/business motivations. 4.8.1 Operator-Focused Scenario Cloud services are offered in a transparent way to the end-user, without details on where the contents are physically located, how the service is composed and which technologies the cloud services leverages. In that sense operations such as the Virtual machine migration, the content movement or database synchronization are totally transparent to the end-user who purchases the cloud service. Moreover, the end-user is not aware of how the services are composed and what synergies must be provided by ISP, Cloud Application Providers and Data Center Operators, i.e. the major stakeholders in the wholesale market. In fact, the end-user itself in the actual scenario is solely the stakeholder purchasing a cloud service and does not actively participate t o other partners interactions, though his needs and requirements are implicitly taken into account by the wholesale market stakeholders and impact their business strategies and interactions. Such a consideration led us to foresee that in the actual scenario one of the main actor and the principal driving force for the all interaction of the partners is the Cloud/Data Center Operator, which must operate a very large and complex infrastructure and has to deal with a variety of issues: complexity of services to be offered to its customers energy efficiency of internal infrastructure fair optimization of the resources of its infrastructure Interactions with ISP in terms of extra-traffic crossing ISP WAN links Cloud Federation interactions and relationships/agreements with other Cloud/Data Center Operators.
The actual macro-scenario can be seen as a the union of previously described ICC and EEF scenarios, thus inheriting all key features, all limitations and all interactions among players. The only refinement to be taken in consideration is related to the end-user role, to be considered just a stakeholder in the described chain value. The macro-scenario thus identified is focused on benefits and limitations inherent to the formation of a Cloud Federation (resource sharing and allocation within the federation), to energy efficiency thematic (both related to Data Center and to ISP infrastructures). In such a scenario Mobility of content/service is intended as mobility of resources across the federation of clouds, driven by previously identified Data Center needs rather than driven by end-user actions. Social awareness will also play relevant part on this scenario, thus providing a trigger to operations among the different actors. It is assumed that, the level of aggregation, the
Page 62 of 95
Version 1.5

Public
granularity and the scope of social information to be used within the actual scenario are different (wider) from Social awareness key features as intended for the end-user focused scenario (which will be described in the following chapter). SmartenIT solution will be deployed at the administrative interface that separates Data Center Operator and Internet Service Provider. The deployment of SmartenIT solution can be seen as an additional service offered to ISP/Data Center Operator that will drive Data Center Operator decisions on content and resource placing. More in general it will help to regulate the interaction among Data Center Operators within the formed federation. For completeness and clarity reasons, we provide just for this meta-scenario the business interactions and financial configuration under this new merged scenario. This is a generalization of the analysis of its constituent scenarios and it demonstrates the resulting complementarities and the gains in the analysis that can be gained by working on the two meta-scenarios. Since this scenario focuses on the wholesale market, this subsection presents the costs and revenue streams among the value chain Information (i.e. Clouds/Data Centers) and Internet Service Providers. From the Internet Service Provider point of view, different revenue models can be applied depending on the kind of mutual agreement between different Internet service providers that are involved in the end-to-end service: The Internet Transit service is a metered wholesale service that is priced on a perMbps basis and metered using the 95th percentile rule. Peering is typically a settlement-free arrangement, with each side deriving about the same value from the reciprocal arrangement. If there is not equal value, as indicated by asymmetric traffic ratio, then a Paid Peering relationship is enforced: the network terminating the largest portion of the bilateral traffic is compensated for this asymmetry by the sending network.
On the other hand, the revenues of the Cloud/Data Center may be based on a pay-peruse model or more often a weekly/monthly subscription for specific service characteristics, e.g., Terabyte of storage or CPU cycles. In the latter case, customers could be provided with access to cloud services offering basic capabilities for a lower price, while enhanced cloud service could be charged a higher monthly/weekly subscription. Bundles of cloud services could be also provided, e.g. storage and content management for a content provider, employing flexible form of payments or discounts. In the case of federations of clouds and Data Centers, some revenue sharing scheme must be decided by the involved parties due to the fact that there is a common cost and value generated by the joint business conducted that must be apportioned to the federation members. We envision that these federations will be highly specialized; addressing a specific target market and service and their operations will be regulated by business policy rules unanimously approved by the federation members. Well known mechanisms for revenue and cost apportionment, such as Shapley values or auctionbased stock market-like mechanisms (i.e. double auctions, spot and futures markets) for the dynamic allocation of resources (e.g., storage, computational power and additional bandwidth on-demand), comprise potential market-based solutions. Clouds and ISPs must invest in their respective infrastructure so as to attract demand and compete for the money-generating traffic respectively. Investments are expected to be individual, i.e. on a per-stakeholder basis, while in the longer-term federations and
Version 1.5
Page 63 of 95

Public
alliances, e.g. in the form of capacity and network deployment sharing, are also possible as complements. In the case of federations, it is envisioned that some minimum amount of investment and network/storage availability will be required by the members of the federation, so as to be eligible to remain as active federation members and benefit from the resulting brand name and economies of scale. Finally, vertical integration in the market among the ISPs, the Data Centers and the Clouds (and also some other Information Service Provider such as a large Content Provider offering popular content and/or services) is also likely, thus creating a complete customer solution over both the application and network layer, completely controlled and offered by a single business entity. 4.8.2 End- user-focused Scenario The scenario described in this section inherits properties from two scenarios, focusing on the end-user related aspects of the Global Service Mobility Scenario (GSM) (see Section 4.5) and the Social Awareness Scenario (SAW) (see Section 4.6). The aspects of the mobility of services and content on different layers of aggregation are combined with the ideas of socially-aware traffic management and energy efficiency. In the following we distill similarities and differences of the scenarios and discuss aspects to be considered in the merged scenario and aspects to be discarded. Both scenarios have similarities in their framework definition. Regarding the actors, both are focusing on the application provider, ISP and end user as main actors, while considering content distribution including a streaming service as applications running on top. The SAW scenario intends to optimize traffic management by allowing for prefetching, caching and offloading, three mechanisms also relevant to the GSM scenario. In the GSM scenario, there are two ways application providers can be helped to optimize their services. The first way is the optimization of service placement among Data Centers by the ISP using an ALTO-like approach, while the second is the offering of the NaDa infrastructure as IaaS for CDN-like content placement to Application providers. For the SAW scenario similar revenue models are possible. Moreover both scenarios have similarities in the technical infrastructure to be used, as both promote the usage of Nano Data Centers to implement the optimizations. Finally both scenarios propose the management of overlay traffic mainly generated by geographically dispersed end-points of communication by exploiting social information. The only relevant difference between the two scenarios is the fact that The SAW scenario lists a social information provider explicitly as a stakeholder, while the GSM scenario assumes social data to be owned by users, staying strictly local. In the SAW scenario, the social information provider might have to be paid for social information Energy efficiency aspects are addressed in both scenarios SAW and GSM with respect to the end-user. In the GSM scenario, energy is saved on the mobile end-user device by the SmartenIT mechanism vIncent [52]. The SmartenIT architecture defines another end user device: uNaDas. These uNaDas are geographically dispersed end-points similar to enduser devices; however, uNaDas are always powered and connected to the Internet. Thus, other energy efficiency mechanisms can be elaborated. In the SAW scenario, social information is used to predict where and which content will be accessed. This information can be used to optimize the distribution of the content also with respect to energy efficiency. Combining SAW with GSM, the social information can be used, to pre-fetch or cache content when a user is using the more energy efficient WiFi instead of 3G.
Page 64 of 95
Version 1.5

Public
Moreover, if both scenarios are combined a mobile user can connect to a uNaDa that shares its WiFi connection for data offloading. Thus, by combining the SAW and GSM scenario, new energy efficiency mechanisms can be investigated in an integrated manner. Merging into final scenario Having presented the similarities and differences of the scenario definitions, we found that there is a high similarity between the two initial scenarios which justifies the merging. Both deal with content placement and distribution for mobile users. Moreover, both consider actions inside clouds (which will be mainly shifted to the data center operator focused scenario) as well as the involvement of end-users devices (uNaDas). The only major difference is the presence of an external social information provider in SAW which will be adopted in the new end-user focused scenario. Moreover, energy efficiency aspects which were underrepresented so far should be emphasized. Thus, especially end user QoE and energy efficiency of both clouds and end users devices will be key performance indicators in the new scenario. Social data will be treated as an oracle available to all stakeholders in the beginning of the development, narrowing down the focus to the real world availability of social information from a social information provider during the course of the project. The overlapping of initial use cases, as showed in the preliminary work across WP2 activities, will be utilized to consolidate new use cases for the end-user focused scenario, but additionally taking into account energy considerations. This sets the focus of the new scenario to energy efficient content placement and distribution for mobile users from an end-user perspective.
Version 1.5
Page 65 of 95

Public
5 Traffic Trends and Analysis

For traffic analysis purposes it is necessary to refer to crucial concepts in networking that in recent years had a great impact over network architecture, involved stakeholders behavior and traffic patterns. Among many important concepts SmartenIT project can consider P2P networking, emerging OSN concept and currently ongoing works towards definition and practical implementations of SDN (Software-Defined Networks). The purpose of this section is to report on recent trends in traffic monitoring and analysis, to overview practical approaches implemented by industrial partners within SmartenIT project and also to propose traffic-oriented mechanisms that can be implemented in relevant modules defined within WP3 of the project. The purpose of the analysis and investigations done under the framework of Task T1.3 can be summarized as follows:
Permanent measurements give information about network and application activity and allow the searching for trends in traffic volumes sent and level of applications usage; Monitoring data is important for network administrators since they can be used for anomaly detection and user misbehavior Raw data is necessary for validation of theoretical models and when searching for new modeling methods.
The SmartenIT project is now in the period of detailed discussion and analysis of applicability of those scenarios defined above and the use cases to be derived from those, with the focus on analyzing relation of stakeholders, architecture of the system, and definition of modules designed and being implemented in next phase of system design. The specific goal of Task T1.3 in the current phase of the project is to define a set of functionality and to support the design of relevant modules for system architecture. Right now several groups around the world work on new ways to test and measure performance of telecommunication systems that involve emerging technologies. For SDNs Spirent proposed PASS (Performance, Availability, Security, and Scale) as critical testing methodology, stressing importance of software-based components, centralized control center, safety issues and scalability of networks [37]. Additional tests covering SDNs mixed architecture (hardware and software) might be required. Right now Working Group IP Performance Metrics is in process of developing of metrics that could be applied to the quality, performance, and reliability of Internet data delivery services and applications running over transport layer protocols over IP. Its work will span over 2013 and early 2014 [35]. This chapter begins with the description of current trends of network traffic (Section 5.1); measurement mechanisms, sources of traffic information and tools for its acquisition are described in Section 5.2, requirements towards this data are gathered in Section 5.3. This chapter is concluded with relation between traffic measurements and analysis and SmartenIT scenarios (Section 5.4) and architecture modules (Section 5.5).
Page 66 of 95
Version 1.5

Public
5.1 Current Trends of Network Traffic

Besides observation of growing volumes of traffic flows carried by networks in recent years one can observe also significant change in traffic characteristics due to growing importance of OSNs replacing previous dominant position of P2P applications. Simultaneously the emergence of virtualization and cloud computing have increased the usage of networking and facilitated introduction of new network-based applications. Over half a decade ago P2P traffic was rising swiftly, approaching and breaching in some cases 50% of overall traffic, without signs of slowing. This sparked expectations that this trend would not stop. However, while sources vary in opinion if file sharing is in decline or has stabilized, it certainly has reached its peak in terms of traffic share [44], [45], [46]. Decline of P2P dominance may be attributed to numerous factors. From file sharing perspective it is combination of following aspects anti-piracy pursuit of file sharing, easier and cheaper access to legal digital content, intentional hiding of P2P traffic in order to make tracing it harder and growing popularity of direct download sites (e.g., the late Mega Upload). Outside factor, contributing to this shift in traffic share is growing popularity of real-time entertainment (that in some cases is categorized as a part of OSNs) and of OSNs. Videoand audio-streaming is typically associated with heavy traffic, but social-networking isnt. Therefore 12% of aggregate traffic linked to OSNs (a quarter of real-time entertainment) is a sign of its huge importance. Moreover even if we separate these two types of traffic, social networks popularity contributes indirectly to demand for audio and video content (e.g. viral videos). The Sandvine report [46] projects that real-time entertainments share of traffic will continue to increase over next five years (Figure 5-1).
Figure 5-1: Projection of Mobile Access Network Traffic in the United States [46].
Version 1.5
Page 67 of 95

Public
This underlines potential of social information applications within SmartenIT project. From prediction of demand for content to large scale traffic events, for example surges of traffic during commercial breaks of Super Bowl [42] or doubling of traffic in response to iOS update [43]. Phenomenon of offloading mobile traffic onto Wi-Fi networks is described in Sandvines report, confirming demand for such solutions. This is of great interest to SmartenIT and will be covered by the end-user focused scenario. Cisco report [8]shows observable migration from traditional Data Centers to cloud-based centers in recent years. Moreover most of related traffic takes place inside Data Centers while less than 20% is between data center and end-users. Consumer applications, such as video and audio streaming are key factors in cloud traffic growth. Moreover, personal data center-based storage (e.g,. Google Drive or Dropbox) are gaining importance in data center traffic (argument that is in line with the consideration made across sec 3.2). Consumer data center traffic in the year 2011 constituted 80% and business 20%. Statistics on the continuous growth of IP traffic volume over the past decade has been collected and evaluated in more detail in section 3.6 of SmartenIT deliverable D1.1 based on annual reports by Cisco Systems and by several national Telecommunication bodies (from Australia, Germany, Hong Kong) [49]. They confirm a steep growth of global IP traffic with rates doubling within 1 - 2 years for mobile networks and within 2 - 3 years for fixed networks, where the growth tendency is expected to slightly decrease in forecasts until 2020. The statistics reveal that Data Centers, clouds and CDNs already have a dominant role in the delivery of IP traffic by supporting almost any popular web site for downloads and video streaming applications [8]. For traffic management, the breakdown of traffic into contributions from different applications is relevant. Such information on traffic classification and volumes per application is partly provided by [46], [48]. The reports by Sandvine [46] evaluate traffic volumes for many popular platforms during the daily peak hour in Europe and other continents as shown in Figure 5-2.
Figure 5-2: Composition of IP traffic in Europe in fixed (left) / mobile (right) networks [46]. Web browsing, real-time entertainment, i.e. video streaming and peer-to-peer downloads are prevalent categories, each of which contributes over 10% to the total traffic. A comparison of up- and downstream reveals that symmetrical traffic of peer-to-peer
Page 68 of 95
Version 1.5

Public
networks contributes 15% of the downstream but half of the upstream traffic. Among the most popular platforms producing a large traffic volume are YouTube, BitTorrent, Facebook and Skype. HTTP denotes other web browsing applications without concrete specification in [46]. On the other hand, measurement on Deutsche Telekoms broadband access [57] shows that currently 70 - 80% of IP traffic is transported via the HTTP protocol including the most popular platforms. A similar application mix is observed in comparison of fixed and mobile networks but with higher usage of social networks (Facebook) and VoIP (Skype) in mobile networks.
5.2 Measurement Mechanisms, Information Sources, and Tools

Modeling and analysis of network performance is a complex task. Traffic measurements are still the main focus of researchers and the only source of crucial information about network behavior. This section presents an overview of measurement mechanisms, necessary tools and look into sources of information and measurement-dedicated hardware. 5.2.1 Mechanisms Proprietary measurement methodologies and mechanisms are crucial to achieve consistent results. A reasonable framework of measurements in packet networks, with defined metrics and methodologies is provided in fundamental for these aspects RFC2330 [23]. According to RFC2330 measurements have to be well defined and repeatable. Regarding well known traffic measurement mechanisms, SmartenIT consortium should consider both active and passive mechanisms ([23] outlines also hybrid measurements). In case of active measurement injected test traffic should fulfill basic assumptions suited in IETFs Benchmarking Methodology Work Group drafts, e.g., RFC2544, RFC5180, RFC6815 [18], - [19]. In the second case passive measurements track performance and behavior of packet streams by monitoring proprietary measurement point. This approach is less invasive, but more challenging, since it requires analysis of network performance without known test sequences, but by analyzing actual data. However, this approach can be used to gather additional information on user behavior. Both approaches require care when planning places of measurement points so that hardware can handle additional tasks in order to gather relevant data. On the other hand traffic measurement mechanisms can be divided into packet-oriented and flow-oriented. The former, can provide very detailed information about network behavior but requires more computational and storage resources. Packet-oriented measurement mechanisms allow running so called Deep Packet Inspection (DPI) that can be used to perform very detailed analysis of traffic. DPI also may be controversial in terms of network neutrality. The best example of flow-oriented mechanism is NetFlow - an important concept that fits well into emerging concept of SDN (Software Defined Network). Specific impact of SDN on traffic measurements and analysis, in general case and also for SmartenIT settings and implementations is related to observed change in traffic patterns for SDN, in relation to traffic for classical client-server applications. For SDN, with additionally cloud networking employed, there exist three types of traffic [33], [34]: intensive machine-to-machine traffic before returning results to the end user flexible access of the user to corporate content from many devices, changed flexibly exchanging traffic employing private clouds, public clouds and as a result sending additional traffic using WAN links.
Version 1.5
Page 69 of 95

Public
Since the SDN concept is widely accepted and promoted we can expect that relevant traffic flows and mechanisms will increase their importance in near future. 5.2.2 Tools The goal of this subsection is to briefly describe important tools for processing traffic flows for different stages and accuracy, which were designed, developed and widely used for such purposes and are publicly available. There are many tools for traffic monitoring and analysis available. Below a few open source tools are described, with brief information about their usefulness and scope of extracted data. 5.2.2.1 MIB/SNMP Standards MIBs (Management Information Base) and SNMP (Simple Network Management Protocol) [20], [21] provide coarse grained statistics from network equipment. The MIB is a hierarchical (tree-structured) database containing data addressed with Object Identifier (OID). Second version, MIB-II is standardized and available on many networks elements. Collected information are highly aggregated - counter of packets and bytes transmitted and lost at interfaces. These statistics are polled commonly every 5 minutes using SNMP. Another standardized MIB is Remote Network Monitoring (RMON) [22] used for remote monitoring. However, complex algorithm imposes limitations on maximum supported throughput on the interface. 5.2.2.2 D-ITG Tool D-ITG (Distributed Internet Traffic Generator) is an active traffic generator with built-in measurement tool that can produce accurate IPv4 and IPv6 applications workloads [17]. D-ITG measures most common network performance metrics at a packet level, e.g. throughput, delay, jitter, packet loss. D-ITG traffic generator uses stochastic models (for packet size and inter departure time) to imitate real application behavior, e.g. Telnet, VoIP, DNS, or games. Using stochastic models for cloud applications from literature (or from own experiments) D-ITG can be also used during SmartenIT architecture tests. D-ITG architecture is shown in Figure 5-3. It consists of two most important modules: ITGSend and ITGRecv that can optionally produce log files (ITGLog module). ITGDec is the analyzer module providing results of the experiments. Using ITGManager ITGSend can be controlled remotely (ITGManager) by D-ITG API. Such feature provides complete control solution for large-scale experiments.
Page 70 of 95
Version 1.5

Public
Figure 5-3: D-ITG architecture. 5.2.2.3 Tstat Tool Tstat (TCP STatistic and Analysis Tool) is an open source passive sniffer designed and developed by the networking research group at Politecnico di Torino since 2000 [24]. After more than 10 years of development, Tstat has become an important and scalable tool for network monitoring used by several researchers and ISPs [26]. Tstat automatically correlates incoming and outgoing packets combining them into flows using both standard traffic measurement indices (e.g. flow dimensions, traffic distribution, etc.) and more sophisticated methods (like out-of-order probability and gap distribution in TCP (Transmission Control Protocol) connections) at L2-L7 layers level to provide traffic evaluation. Since Tstat is written in ANSI C, developers claim that their application can operate with multi-gigabit-per-second traffic analysis [25]. Tstat provides both live capturing and off-line file analysis for previously collected traces (for different file formats: pcap, erf, etherpeek, snoop). In fact, Tstat properly reads many popular formats of archived files. The proper place for Tstat probe installation set-up is at the access router of the monitored network. Monitored traffic is smartly slit into local, incoming and outgoing by provisioning information about the monitored network prefix. Tstat monitoring probe setup and analysis workflow is depicted in Figure 5-4. Output statistics are available at three different levels: per-packet, per-flow and aggregated. At the per-packet level, packet traces can be dumped into a trace file for further offline analysis. Also, recorded packets can be segregated by different applications and dumped to different output files. At the intermediate level (per-flow statistics) Tstat generates text output file with many columns containing information about given flow (e.g. log_tcp_complete has 111 columns, see http://tstat.tlc.polito.it/measure.shtml). At the aggregated flow level two formats are available: histograms and RRD database.
Version 1.5
Page 71 of 95

Public
Figure 5-4: Tstat: a) monitoring probe setup, b) analysis workflow [25]. Example outcome from internal AGH network analysis traces using Tstat tool is shown in the Fig. 5-4. These traces were captured inside AGH dormitories and data collection has started on June 5th, 2013 at 23:30. The trace consists of exactly 1 billion packets per dormitory. Due to privacy reasons these files containing traces consist only of L2-L4 information. It is worth mentioning that AGH students (inside students campus) cannot use typical P2P applications. P2P file sharing is allowed only between dorms. Others TCP (classified) protocols, marked with orange color are: RTSP, ICY, YMSG, XMPP, SMTP, POP3, IMAP4, ED2K (obfuscated), SSH 2.0/1.99, Bittorrent MSE/PE and others UDP (classified): RTP, RTCP, Skype End-to-End, SkypeOut, Skype signalling, eMule ED2K, eMule KAD (Kamdelia), Adunanza (eMule mod) KAD (Kamdelia), Gnutella, BitTorrent DHT (only), DirectConnect, KaZaa, PPLive IP-TV, SopCast IP-TV, TV-Ants IPTV, BitTorrent uTP (only),BitTorrent DHT and uTP s (mixed), MPEG2 PES Streaming over UDP, PPStream IP-TV, Teredo IPv6 tunneling over UDP (mostly BitTorrent).
Page 72 of 95
Version 1.5

Public
a) TCP statistics
b) UDP statistics Figure 5-5: Tstat: example results. 5.2.2.4 CoralReef Tool CoralReef is an open source network analyzer developed by CAIDA [27]. CoralReef originally has been designed as a ATM traffic monitor and then expanded to analyze also IP traffic. As shown in Figure 5-6 CoralReefs architecture is organized into two software components [28]. The Raw Traffic Stack is based on the libcoral C library and directly reads PDUs from network equipment. The Flow Stack analyzes traffic data organized into flows. Additionally, the Flow Stack includes advanced modules for storage and processing of collected data, e.g. data can be aggregated by AS number and identified by source country.
Version 1.5
Page 73 of 95

Public
Figure 5-6: CoralReef architecture [28]. CoralReef can read previously captured data (trace files) and analyze traffic offline (e.g. on other host than data was originally collected) or can use both, their own drivers and libpcap to read live traffic stream. Furthermore, CoralReef provides an API to generate flow data in well-known NetFlow [14] and NeTraMet [29] formats. CoralReef is constantly developed since 1999. The current version (coral-3.9.1) works on Linux and FreeBSD Intel-based workstations with ATM, POS and Ethernet devices at up to OC192 and 10GigE bandwidths. Since early versions, the CoralReef is continually supporting external researchers and CAIDAs traffic analysis [30]. Example realtime report from OC192 link between Chicago, IL and Seattle, WA, registered on September 17, 2011 is shown in Fig. 5-6 [31]. More examples are available online at http://www.caida.org/data/realtime/.
Figure 5-7: CoralReef example outcome (1 day analysis) [31].
Page 74 of 95
Version 1.5

Public
5.2.2.5 BLINC BLINC (BLINd Classification) is a novel traffic classification approach presented in [32]. The core functionality of BLINC is based on two features: observation of the host behavior at the transport level and the classification methodology operating at three different levels of the host behavior (social level, functional level and application level). BLINC can operate without usage of packets payload and information about well -known port numbers. BLINC analyzes data on flow level without considering individual packets. Moreover, BLINC is insensitive to dynamic changes observed in network that can affect statistical methodologies. Social level classification can be done thanks to detecting the social role of the host. BLINC uses complementary cumulative distribution function (CCDF) to classify traffic into different basic types: web, P2P, malware, mail [32]. For example, in P2P case a host communicates with large number of others in a short time period. Building the graph of communicating hosts can obtain additional information, e.g. possibly the neighbor IP addresses can offer the same service (e.g., in server farms). Moreover, identification of small number of server (services) can retrospectively show clients and then big portion of traffic can be identified. Classification at the functional role provides information whether a given host is a client, server or both. For example, if a host uses only one port for communications with others, then this host is web server. In P2P case both functionalities can be observed. In classification at the application level, a flexible combination of knowledge from two previously mentioned levels is used. At the beginning BLINC uses only IP addresses and port number information and then reclassifies flows using more detailed information (e.g., used protocol, average packet size). BLINCs authors proposed graphlets as a reflection of typical application behavior. Graphlets show relations between the usage of source and destination port sets. Example graphlet for FTP is shown in Figure 5-8. Authors have built library of graphlets that can be used to application level traffic classification.
Figure 5-8: Blinc FTP graphlet [32]. As authors shows in [32], BLINC classifies traffic with 80-90% accuracy. In addition, BLINC can identify malicious behavior of previously unknown application without priori possession of information about it (e.g. port number). 5.2.2.6 NetFlow NetFlow is a Cisco protocol dedicated to IP traffic information collection and analysis. It enables network traffic accounting, usage-based network billing, network planning,
Version 1.5
Page 75 of 95

Public
security, Denial of Service monitoring capabilities, and network monitoring. NetFlow provides valuable information about network users and applications, peak usage times, and traffic routing [14]. NetFlow is supported by Cisco hardware, Juniper routers, and Alcatel-Lucent routers. It consumes a lot of resources; therefore its activation on high traffic routers may decrease performance of those devices. In any case it allows to infer the traffic matrix, application types, temporal distribution of the traffic, traffic associated with particular ports/applications [14], [16]. Example outcome after AGH NetFlow statistics analysis is shown in Figure 5-9.
3.5 x 10
4
Flows dropbox facebook gmail twitter youtube
2.5
1.5
0.5
04:00
08:00
12:00
16:00
20:00
a) Area chart of number of observed flows

2.5 x 10
9
Bytes dropbox facebook gmail twitter youtube
1.5
0.5
04:00
08:00
12:00
16:00
20:00
b) Area chart of traffic volume Figure 5-9: Popular cloud applications

Page 76 of 95
Version 1.5

Public
NetFlow traces were collected inside AGH campus (without dormitories) on May 13, 2013 with five-minute reporting window period. Presented data were analyzed using Linux nfdump application and Bash scripts. As we can observe there is a very strong disparity between number of flows and traffic associated with each application. For example Facebook flows tend to include constant data transmission, while Dropbox flows may include mostly low volume synchronization messages. 5.2.3 Dedicated Measurement Devices In addition to software measurement tools, dedicated measurement devices have important role. Key aspect of dedicated hardware platforms is their ability to store singletons (individual measurements) and high accuracy of measurement [40]. Two examples of these solutions are presented below: Spirent TestCenter is a hybrid (hardware and software) device that provides wide variety of network test configurations for functions ranging from 2nd to 7th OSI-ISO layers [36]. Spirent TestCenter provides a highly scalable benchmarking platform with 1GbE, 10GbE, 40GbE and 100GbE interfaces. Using their dedicated software wide network configuration can be emulated and tested. Besides active measurements (with high performance traffic generation), Spirent TestCenter can capture live network traffic, targeted with triggers and filters that allow to precisely analyze collected data. Each measurement can be automated and saved (even each iteration results) for future analysis and troubleshooting. DAG Cards are PCI-based cards providing reliable packet capturing (without packets loss/drop) designed and provided by the University of Waikato and Endace society in New Zealand [38]. DAG cards use FPGA and DMA technology to satisfy high performance. Using dedicated DAG cards measuring/probing server can achieve better efficiency in data processing (CPU is not used to ensure correct packets capturing). DAG cards have been used in many research works during their availability on the market.
5.2.4 PERFAS: A Network-wide Performance Monitoring System For active measurements of delay, packet loss and for control of connectivity, the PERFAS monitoring system is installed on Deutsche Telekoms IP backbone, which has been developed including support from the EU IST Aquilla project [47]. PERFAS performs active measurements on IP level. The PERFAS client systems are periodically sending specific measurement packets due to configuration for the induced traffic profile. A flow of probing packets may be adapted to represent a specific traffic flow. PERFAS relies on measurement agents to be installed at specific points in the network which are attached via TCP/IP or Ethernet ports and observes transmission of packets between those points. In this way, measurement can be set up for end-to-end paths, between boundary routers of network platforms or between arbitrary pairs of IP routers. A master station enforces control of the measurement with the help of a system monitor as a near real-time display of the current status of measurement, which can handle a set of configured IP flows. The extent of the reports on measurement results is also governed via the master station. While PERFAS is focused on high speed broadband Internet platforms and is scalable in terms of data throughput and the number of parallel IP flows.
Version 1.5
Page 77 of 95

Public
Figure 5-10: PERFAS Measurement tool set with control station and distributed agents. PERFAS offers an elaborate support for time synchronization between the measurement points and agents by three different methods GPS System (Global Positioning System) The external reference clock of a GPS system achieves the highest precision in time synchronization between agents and works independent of the condition of the data network. Network Time Protocol (NTP) The network time protocol has been introduced by the Internet Engineering Task Force (IETF) to synchronize computer clocks on the Internet and is currently under fundamental revision by the NTP working group <www.ietf.org/dyn/wg/charter/ntpcharter.html> for the new NTP version 4. PERFAS has implemented the currently recommended functions which yield a precision in the time scale of tens of milliseconds. Round Trip Delay Synchronization (RTDS) A proprietary implementation uses round trip delay measurement for conclusions on the differences between the clocks on the agents, which allows for precision below 10ms, slightly better than NTP.
Page 78 of 95
Version 1.5

Public
Table 5-1: Accuracy of time synchronization methods between measurement agents.

Time scale for each method Synchronization accuracy Measurement accuracy GPS
< 1 s < 50 s
NTP
0.7 10 ms 1 - 20 ms
RTDS
0.1 4 ms 0.2 8 ms
Wherever applicable, PERFAS conforms to international standards, especially those introduced by the IP Performance Metrics (IPPM) working group of the IETF [35]. Classbased service differentiation and prioritization as demanded is fully supported by PERFAS. Protocol analysis is available for IPv4, TCP and UDP (User Datagram Protocol). IPv6 and RTP support is currently under development. In particular, the standard evaluations of PERFAS include the following parameters for one-way and round-trip measurement in unicast or multicast mode: Latency (Packet delay) Latency variation Continuity (Packet loss) Number of received packets Status of the time synchronization VLAN support E-model (R-scale, MOS-scale)
Performance measurement tools with this functionality are beneficial in the operational network for surveillance and in depth analysis of paths that encounter any problems which may lead to insufficient quality of service and violation of SLAs. 5.2.5 Information Sources The goal for this subsection is to figure out the sources of traffic information which can be used by the SmartenIT consortium. The Network Traffic Monitoring module should be flexible and scalable (see SmartenITs deliverable D3.1 [56]) and should be able to be deployed in a large range of different network architectures. There exists a wide range of observation points and sources from which SmartenIT Network Traffic Monitoring component can collects data. Most important seems to be ISPs network devices interfaces from which network traffic can be probed. This assumption however requires close collaboration with ISPs. On the other hand, ISPs can grant access only to core network devices or to the edge of the network (SmartenITs D3.1, Section 5.4.3). Since network devices can only provide information from network and transport layer, enduser applications can be new sources of crucial information about network behavior. Today traffic classification methods cannot provide satisfactory results because traffic complexity and growing popularity of http/https applications. User agreement for collection of some private information may be critical to achieve better network performance. In this case, additional application installed inside user mobile devices or uNaDas (user-owned Nano Data Centers) that export traffic characteristics may be necessary. Typical long term network behavior can be provided by commercial companies offering specialized reports. As an example, Net Market Share [39] is a statistics source providing reports on shares of browsers, operating systems and search engines, as well as few
Version 1.5
Page 79 of 95

Public
other statistics, like popularity of screen resolutions, or social media referrals. It gathers data from over 40 thousand websites from around the world, counting unique visitors daily. Reports and statistics are compiled using approximately 160 million page visits monthly, including referral sources to provide data on social networks and search engines shares. Referrals are divided into organic and sponsored. Since OSN applications are private, closed proposals, typically the access to the traffic information is not allowed and such monitoring or measurements can be done by agreements or by introducing special mechanisms, e.g., emulating behaviour of OSNs element.
5.3 Measurement Requirements

This section covers requirements toward measurement mechanisms, their applications and metrics and key performance indicators. To satisfy SmartenIT architecture modules and involved stakeholders interests the following requirements should be considere d [41]:
Observation point depending on collected data, access to network at very specific points may be required. This includes access to certain interfaces or entire routers, or user application (e.g., if there is interest to obtain social information from OSNs). For delay measurement, usually two points traversed by a traffic flow need to be observed with strict time synchronization between them. Metering, exporting and collecting process - in order to assure smooth performance of modules a precise policy regulating collection and exchange of traffic information must be provided and respected among involved devices. Time stamps it is important to provide timestamps for time-based measurements, so that correlation is assured, and that system can keep track of timeouts. Time resolution in order to capture traffic variability relevant for loss and delay characteristics, appropriate time resolution below the milliseconds time scale is usually required. Time synchronization some measurements, especially in case of active probing, will require strict synchronization to ensure correct results. Reliability infrastructure for acquisition of traffic information may include some redundancy, so that single point of failure problem can be avoided. Sampling restrictions use of sampling instead of wholesome measurement reduces strain on infrastructure, but can also distort results if not done properly. User data confidentiality data anonymization is crucial for legal reasons and to retain users trust. Mechanisms that perform Deep Packet Inspection and collect social information from OSNs must include proper anonymization procedures. Security considerations some, if not all, traffic information collected for SmartenIT mechanisms can be regarded as sensitive data. As such it should be handled with care, to prevent any unwanted outflow. One way or bidirectional measurement In order to capture the main traffic flow, downstream traffic measurement can be sufficient, but often the upstream traffic is relevant as well.
Page 80 of 95
Version 1.5

Public
Traffic measurement applications:

Billing business models assume traffic billing based on time or traffic volume. Traffic Engineering the main goal of TE is the optimization of network resources and traffic performance. As TE mechanisms require input from network to control traffic, measurement results provide such information. Typical metrics used for TE are: link utilization, traffic volume, traffic composition, load between particular/specific network nodes, information about traffic path (entry/exit points). Network planning is required for upgrading any existing network platforms because of a steady traffic growth. Statistics on link and resource usage as well as source-to-destination traffic matrices for edge routers are most important [50]. QoS monitoring allows to measure parameters required to calculate traffic quality (both, subjective and objective). Moreover, QoS monitoring provide information about parameters negotiated in a Service Level Agreement (SLA). Using existing QoS/QoE mapping methods Quality of Experience can be calculated, e.g., E-model [13]. Attack detection traffic monitoring provide information about any unusual situations inside monitored domain, alarming about any potential threats and malicious users.
Each of the previously mentioned aspects has different requirement for traffic measurement, e.g. for accounting/billing for each user service provider has to account time or traffic volume used to access to particular service. For traffic engineering, QoS/QoE performance statistics, SLA and failure control a set of key performance indicators is captured by monitoring systems within SmartenIT architecture. These KPI among others include (SmartenITs D3.1): One way, two way, round trip delay, Packet loss and error ratio, Data throughput, transmitted volume on links and paths, Connectivity, system availability, Thresholds evaluated from KPIs to trigger link upgrades, Metrics combined from several networked elements e.g. traffic matrices, Detailed statistics on IP packet and/or TCP/UDP flow level, QoE metrics on higher layer application level.
Further specification of functions, input data and results from modules dedicated to traffic monitoring and measurements (Network Analyzer, QoS monitor, QoE monitor) will be done within next phase of the design process carried out within SmartenITs WP3.
5.4 Relation of Traffic Measurements and Analysis to Scenarios

Table 5-2 presents the relations between traffic measurements and the SmartenIT scenarios including the main stakeholders. Also, the potential use of assigned measurements in the SmartenIT scenarios is proposed.
Version 1.5
Page 81 of 95

Public
Table 5-2: Traffic measurements related to scenario.

Scenario Operator focused scenario End-user focused scenario Measurements Types Passive (fetching statistics) and active (traffic injection) Passive (fetching statistics) Relation Explanation Measurements performed at ISP, Data Center devices Measurements performed at user premises (uNaDa, Mobile, PC) Potential Use in SmartenIT QoS calculations, indirect QoE calculation, Energy efficiency (ISP, Data Center) QoE direct calculation, energy measurements on user device,
In the operator-focused scenario the main source of traffic monitoring information for ISPs are MIBs inside the network equipment accessed via the SNMP protocol. The technology is well known and heavily used. Although this technology has not been changed from many years it is still considered as the basic one fulfilling the main requirements of ISPs. There are many proprietary and open tools which facilitate the use of SNMP and MIBs by ISPs Network Operator Centers (NOC). They allow to create the topolo gy picture of owned network, infrastructure and monitor its status. It is a common approach applied by ISPs to set up thresholds to identify defined events/behavior of the network (e.g., high link utilization). In order to protect operational network traffic the active measurements with artificial/testing traffic are executed with care. They usually run when the utilization of network is low (e.g., periodically at night) or during the troubleshooting procedures. Apart from ISPs, Data Centers also can use the measurement tools of both types. Data Centers can tests connections inside their local network, connection with distant resources of another Data Center or validate independently the connection parameters agreed in SLA with ISP. It is expected that measurements executed by operators (ISPs and Data Centers) will be crucial to optimize network traffic. The monitoring data will be one of the main inputs to the algorithm(s) implemented by SmartenIT. The use cases with inter-cloud communication configurations will be constructed with the assumption that the current and historical network monitoring data are available. In the end-user focused scenario it is proposed to use the passive measurements applying available software libraries, run by user friendly lightweight applications, which has direct access to the network interface. Active measurement tools are useful to test the network connection (last mile) but due to its lower parameters they should be executed with care. It is expected to monitor the connection of the end-user. Collected parameter values can be an input to the QoE estimation mechanism(s). Because SmartenIT focuses on end-user mobile devices the monitoring of WiFi access quality has to be analyzed. Both in uNaDas and end-user devices the measurement tools have to be lightweight not to violate the energy efficiency approach of SmartenIT solutions.
5.5 Relation of Measurements and Analysis to Architecture Modules

Based on the preliminary architecture, described in SmartenITs D3.1, traffic measurements and analysis components are mapped to SmartenITs architecture modules. The architecture consists of various monitors, which are deployed on network entities and end-user devices. Their measurements are transmitted to respective analyzers, which are part of the S-Box. The S-Box is a central component, operated by the network provider or Data Center operator, analyzing the collected measurements and
Page 82 of 95
Version 1.5

Public
deriving required actions to optimize the overall network performance. These decisions are then executed by the network manager, dynamically reconfiguring the network. Traffic measurements are collected by network monitors, QoS-, and QoE monitors. These are deployed on network devices within the ISPs domain. Network entities (routers, switches) within the ISP network run network monitors and QoS monitors or are monitored by specialized software to allow deriving respective parameter values. On end user devices network monitors and QoE monitors are deployed. Each of these monitors collects a distinct set of measurements, which are aggregated by the network analyzer and the QoS/QoE analyzer. This aggregated information is made available to the traffic manager in a condensed form, like a network usage map or QoS/QoE map. Based on this information, the traffic manager changes the network configuration and routing to improve the user experienced network quality. The network analyzer and QoS/QoE analyzer are components of the S-Box, running at the ISPs premises. The network monitor, deployed on all network devices within the ISPs domain, collects measurements of the current network throughput on all interfaces. It is also aware of the properties of the network interfaces like connections status and maximum bandwidth, and such can calculate the relative usage of different links. On mobile devices, also the signal quality, alternative networks and network interfaces are periodically scanned. Measurements conducted by the network monitor are purely passive measurements and need to be collected in a sufficiently small interval to also include short traffic peaks. The collected measurements are sent to the Network analyzer as soon as possible or in the case of intermittently connected devices as soon as connectivity is restored. The QoS and QoE monitor collect measurements on the Round-trip Time and loss rate of the currently active connections. This might be done by passively monitoring of the respective connections (i.e. TCP retransmissions and contention window size) or by actively probing the network. The passive approach is intrusive and might not be feasible on all devices within the domain due to access restrictions. The active probing approach is straightforward, but influences the network by actively generating flows to determine the characteristics to be measured. The QoE monitor extends the QoS monitor by also including user related parameters like the number of stalls in a video stream (i.e. buffer under runs) or in the case of real-time streaming connections the number of interruptions and the overall connection quality. The network analyzer collects the input from the network monitors within its own domain and makes it available to other domains via an Inter-ALTO (Application-Layer Traffic Optimization) like protocol via the S-Box. Such, it becomes possible to determine the detailed state of the network. From these measurements, the network analyzer generates a map with the current state of the network. This includes the capacity of links, their current usage, and the available bandwidth. The QoS/QoE analyzer, analog to the network analyzer, collects the QoS and QoE measurements from the respective monitors. From this, and in combination with the aggregated data from the network analyzer, a current state of the QoS parameters of the network is derived. As direct QoE measurements can only be conducted at the end-user devices, the influence of the network state can be correlated with the QoE measurements and such the network traffic might be redirected in an optimized way to improve the overall QoE within the ISPs premises. Another important metric for the optimization of the routing and caching decisions is the energy efficiency. To optimize this, the full energy consumption of the network must be
Version 1.5
Page 83 of 95

Public
known, including end-user devices and cloud instances. Therefore, energy monitors are deployed throughout the network, similar to the network and QoS/QoE monitors. The energy consumption of network entities can either be measured directly on the respective device by running energy monitors, or by deriving the estimated energy consumption from the processed network traffic. In the case of an ISP, this might be done by a central component, which also knows the current state of the network and derives the energy consumption for individual components. Energy measurements are only possible by deriving the energy consumption from the device usage, rather than physically measuring the power consumption. Different power measurement techniques are described in Section 3.7 of SmartenIT D1.1 Deliverable [55]). The measurements collected throughout the network are sent to the energy analyzer, which, similar to the network analyzer and QoS/QoE analyzer, derives the aggregate energy state of the network. This aggregated energy state is then used to optimize routing and caching decisions. The end-user devices pose a different challenge here, as these might be the most energy efficient devices in the network, but are strictly limited in their available capacity; hence a trade-off between these entities must be found. Relevant literature covering the analysis and improvement of the network energy efficiency is described in Deliverable 1.1. Based on the aggregated network information, generated by the network analyzer, QoS/QoE analyzer, and energy analyzer, the traffic manager, which also includes input from other component, decides about the optimal routing. Such, a direct feedback loop is implemented, which allows dynamically changing the routing and traffic control.
Page 84 of 95
Version 1.5

Public
6 Summary and Conclusions

In this deliverable D1.2 SmartenIT had three main targets to achieve, related to three different areas of relevance. The first target was to provide a classification of most common Cloud applications and services, and by proper investigation based on partners ranking, to evaluate their positioning and relevance within SmartenIT scenarios. The second target, the full description of SmartenIT scenarios, has been carried out in detail with a twofold focus: actors and their mutual relationships (mainly described from a business point of view) on one side and technical issues pertaining to the selected scenario on the other side had to be identified and analyzed. The third target was focused on traffic analysis. A review of most common approaches in terms of protocols, tools, hardware and software has been provided. In turn, general requirements for traffic measurement are given, SmartenIT interest in traffic measurements across the different scenarios is described, and SmartenIT Solutions main components, which are in charge of performing traffic analysis, are described. Thus, in this final section of Deliverable D1.2 a summary of the key outcomes and lessons learnt is presented, addressing those three targets mentioned above. Finally, next steps and open issues to be addressed in future steps within SmartenIT are outlined, mainly within WP2 (since WP1 concludes its work with this deliverable), but also when transferring results from WP1 to the architecture design and engineering done within WP3.
6.1 Key Outcomes and Lessons Learnt

The conduction of a survey of existing and emerging optimization approaches and their applicability to different types of cloud services had been based on cloud applications classifications according to their technical and non-technical characteristics, all of which are relevant to optimization. Based on this novel classification scheme, the optimization potential in terms of traffic reduction, energy savings, and improved user experience is estimated. SmartenIT determined a huge diversity of cloud services, which makes it impossible to find a one-fits-all optimization approach. Instead, flexible approaches, which can be customized to specific requirements of a service, will be taken into consideration by SmartenIT. It was outlined that service categories such as video/music on demand and file storage/file sharing still have a high optimization potential and can benefit from a collaborative optimization. The main outcome of this work is that the SmartenIT consortiums final agreement is to consider YouTube and Dropbox as primary applications, which represent the most relevant services Video-on-Demand and File Storage. If a modification of this service functionality is needed for a dedicated SmartenIT solution corresponding open source implementations will be used, updated (if needed), and evaluated respectively. SmartenIT produced the scenario definitions. The main outcome of this work was the creation, starting from initial SmartenIT scenarios as outlined in the DoW, of the two final scenarios. These final scenarios are intended to offer all relevant, but different foci on the cloud SmartenIT ecosystem, the first one focusing on an operators point of view (wholesale scenario) while the second one focusing on the end-user point of view (retail scenario). The two final scenarios are considered to be a precise and carefully crafted composition of those previously identified scenario key components. This mapping is shown in Table 6-1.
Version 1.5
Page 85 of 95

Public
Table 6-1: Mapping of key feature to the final SmartenIT scenarios.

Operator-focused scenario (wholesale scenario) Inter-cloud Communication (ICC) Global Service Mobility (GSM) Social Awareness (SAW) Energy Efficiency (EEF) X X(*) X(**) X X X X (***) End-user-focused scenario (retail scenario)
The following legend should be used across Table 6-1: 1. (*) the two final scenario have different focus, thus allowing to properly differentiate the mobility concept (mobility of user, of services, of resources). 2. (**) Social awareness is relevant in both scenario, with different aggregation level, metrics and scope. 3. (***) Tailored on two scenarios, different concept of energy efficiency can be explored (EE for DC, for ISP and for the end-user). The rationale used for the final scenario description suggests the following considerations: The operator-focused scenario inherits all features of the ICC and EEF scenario, but contains also selected key features from the GSM and SAW scenarios, both primarily addressing the operators point of view. The end user-focused scenario inherits all features from the GSM and SAW scenarios as well as major considerations taken from the EEF scenario, especially energy efficiency related to the end-user.
These two scenario types of the SmartenIT project, namely the operator-focused and the end-user-focused scenarios, reflect many conceptual differences and complementary segments of the value chain of Internet services. In particular, the end-user-focused scenario pertains to the session layer, where end-users demand is exhibited at fast time scales. Each individual demand pertains to the retail market and regards extremely small portions of those network resources available. Traffic streams of end users exhibit burstiness, volatility, and their inherent features are application (and service) dependent. On the contrary, the operator-focused scenario pertains to the back end of the Internet services value chain and captures business interactions of stakeholders at the wholesale market, which are not directly revealed to end users. Traffic management at this market is addressing higher levels and typically observes service-agnostic aggregates of both elastic and inelastic traffic, which are multiplexed and managed at the aggregate level. This market operates at slower time scales, i.e. business agreements and contracts, as well as the provisioning of resources are more long-lived and stable than those of the retail market, since stakeholders of this market optimize and act over a larger time window. Dealing with wholesale large traffic aggregates is the only feasible way to deal with scalability issues, which are inevitable in the Internet market due to the vast number of Autonomous Systems (order of magnitude of 10k). Overall, the two SmartenIT scenarios are characterized by those different foci on the Internet services
Page 86 of 95
Version 1.5

Public
value chain and inevitably have different granularity in terms of size, scope, and time scales. This is analogous to the fast small time scales control decisions versus the longerterm management decisions of the networks. Lastly, key elements of traffic monitoring (mechanisms, tools, measurements devices, and sources of information) have been identified and a certain number of measurement requirements that must be satisfied by a general system exploiting traffic analysis, addressing on-line social network information, too, have been described. The main outcome here is the statement of relevance of fine-grained, and online social networkoriented traffic analysis for SmartenIT systems as well as a brief description of related SmartenIT system deployment steps needed across those scenarios identified.
6.2 Next Steps

This deliverable finalizes all activities related to WP1. It is strongly recommended that all relevant outcomes and results achieved through this deliverable will be used across next WP2 and WP3 activities. It is expected that future WP2 work on use-case has to take into consideration the scenario development that has been carried out within this deliverable, and selected usecase will be tailored toward the two final scenarios as outlined in previous sections. Moreover, it is recommend that future WP3 activities will take into consideration main outcomes achieved in D1.2, too, specifically related to both scenarios and traffic measurements, to drive suitable progressive work on the SmartenIT architecture deployment and the related components development.
Version 1.5
Page 87 of 95

Public
7 SMART Objectives Addressed

This deliverable contains the main outcomes of the following activities: 1. Task T1.1 Cloud Service Classification (Chapter 3) 2. Task T1.4 Traffic Measurements and Analysis (Chapter 4) 3. Task T1.3 Scenario Development (Chapter 5) Moreover this deliverables main purpose is the completion of all activities related to WP1, and its main outcomes are fed into WP2 and WP3. In turn, throughout this document, two overall (Table 7-1) and four specific (Table 7-2) SmartenIT SMART objectives, as defined in SmartenIT Description of Work (DoW [51]), have been addressed. Table 7-1: Overall SmartenIT objectives addressed.
Objective No. O1 O1 Measurable Specific Energy efficiency Scenarios Deliverable Number D1.2 D1.2 Achievable Study, design Study, design Relevant Advanced Advanced Timely Mile Stone Number MS1.3, MS1.4 MS1.3, MS1.4
Table 7-2: Specific SmartenIT objectives addressed.

Objective No. Measurable Specific Deliverable Number Achievable Design, simulation T1.4, T2.1, T2.2, T2.5, T4.4 Design, prototyping T3.1, T3.2, T3.3 Relevant Timely Mile Stone Number
O1.1
O3.1
O3.3
O3.4
O4.1
Savings in inter-domain How to align real ISP traffic (in Mbit/s) and networks, while possible energy savings optimizing overlay of due to optimized service/cloud management requirements? mechanisms (1), (2) At which level to Number of considered integrate the proposed management solution with the platforms, number of existing network comparison studies to management existing solutions platforms? Which feedback loop Number of metrics and what kind of identified for the communication selection process, protocol should be number of possible used to retrieve and mechanisms to choose evaluate users from perceived QoE? Number of options identified to monitor energy How to monitor energy consumption on efficiency and take networking elements appropriate and end users coordinated actions? mobile devices, investigation on which options perform best (yes/no) Which scenario and Number of use cases related use cases will identified, number of
Major output of relevance for provider and in turn users
M36
Highly relevant output of relevance for providers Extremely relevant output of relevance for providers and users
M24
Design, simulation, prototyping T1.3
M12
Design, simulation, prototyping T1.3, T2.3, T4.1, T4.2, T4.4
Highly relevant output of relevance for users
M36
Design T1.4
Highly relevant output of
M12
Page 88 of 95
Version 1.5

Public
show tangible benefits to all involved parties?
evaluated use cases with respect to the benefits of the stakeholders
relevance for all providers and users
Regarding the completion of the overall objectives (O1 and O2), this deliverable fully achieves both objectives, since complete scenario specification (in terms of actors and their mutual relationships as well as in terms of technical issues, possible limitations and potential SmartenIT deployment) have been carried on. Energy efficiency topics are fully described across the deliverable and specified in terms of actors, requirements and triggers of actions within the SmartenIT ecosystem. This deliverable contributes in detail to answering the following three specific SMART objectives and their related questions: 1. Objective O1.1: How to align real ISP networks, while optimizing overlay service/cloud requirements? Across the description of the scenarios, of actors and their mutual relationships, SmartenIT has fully described all different needs of underlay and overlay infrastructure, highlighting an inherent asymmetry of information and contrasting interests, which can be recomposed by an incentive-based traffic management as provided by SmartenIT solutions. 2. Objective O3.1: Which techniques to be used to retrieve management information from cloud platforms and OSNs? This is actually explored across Section 5; further details will be developed in a) data center op. scenario focuses on cloud platforms; and b) end-user focused scenario where OSN data by means of sampling and via proper interfaces (as result of WP3 activities) will be retrieved. 3. Objective O3.3: Which feedback loop and what kind of communication protocol should be used to retrieve and evaluate users perceived QoE? Quality-of-Experience has been described as the one of the main performance indicators across all scenarios. It is foreseen that its measurement will be an indirect measure starting from real traffic information. Standard techniques and most common monitoring tools to perform traffic analysis have been described in this deliverable, as well as SmartenIT monitoring components potential deployment within the described scenarios. 4. Objective O3.4: How to monitor energy efficiency and take appropriate coordinated actions? Energy broker as additional actor is introduced within the fourth initial scenario (energy efficiency scenario). Concrete solutions will be considered in future WP2 and WP3 activities. 5. Objective 4.1: Which scenario and related use cases will show tangible benefits to all involved parties? All scenarios as described within the DoW have been fully described. Moreover a final refinement, which has produced two final macro-scenarios, has been provided in order to carry over to the next WP2 activities. One of the major drivers for the final scenario refinement has been the identification of a certain number of use-
Version 1.5
Page 89 of 95

Public
cases key features that have been recognized to overlap across the initial scenarios. According to the SMART objectives set within SmartenIT's DoW [50], those ones of relevance for Deliverable D1.2 and the respective tasks within WP1, i.e., T1.1, T1.3, and T1.4, the targeted objectives can be considered to have been met.
Page 90 of 95
Version 1.5

Public
8 References
[1] [2] [3] Dr. Peering international, http://drpeering.net/, Last visited October 2013 A Cloud Book for the Cloud, Kevin Kelly, www.kk.org/thetechnium/archives/2007/11/a_cloudbook_for.php, Last visited October 2013 Antonio Celesti, Francesco Tusa, Massimo Villari and Antonio Puliafito , How to Enhance Cloud Architectures to Enable Cross-Federation, 2010 IEEE 3rd International Conference on Cloud Computing (CLOUD), pp. 347, DOI 10.1109/CLOUD.2010.46 Global Inter-Cloud Technology forum, http://www.gictf.jp/index_e.html, Last visited October 2013 Nation Institute of Standards and Technology, http://www.nist.gov/index.html, Last visited on October 2013 The Green Grid (get connected to efficient IT), http://www.thegreengrid.org, Last visited October 2013 Vaquero L M, Rodero-Merino L, Caceres J and Lindner M, A Break in the Clouds, Towards a Cloud Definition, CCR January 13, pp. 55, DOI: http://doi.acm.org/10.1145/1496091.1496100 Cisco Global Cloud Index: Forecasting and methodology 2012-2017, CISCO, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns1175/Cloud_Index_White _Paper.html, Last visited October 2013 ALTO Status Pages, IETF, http://tools.ietf.org/wg/alto/, Accessed October 2013.
[4] [5] [6] [7] [8]
[9]
[10] Telecom Vendor Revenues Flatten, in line with SP Capex, OVUM 2013, http://ovum.com/research/telecom-vendor-revenues-flatten-in-line-with-sp-capex, Last visited October 2013 [11] Nano Data Center Project, http://www.nanoData Centers.eu/, Last visited 2013 [12] Kholia, Dhiru, and Przemysaw Wegrzyn. "Looking inside the (Drop) box.", 2013 [13] Recommendation ITU-T G.107: The E-model, a computational model for use in transmission planning, 2005 [14] Cisco IOS NetFlow Version 9 Flow-Record Format , CISCO, http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.p df, Last updated 2011 [15] Introduction to Cisco IOS Net Flow, CISCO, http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aec d80406232.pdf, Last updated 2012 [16] Configuring NetFlow, CISCO, http://www.cisco.com/en/US/docs/ios/12_2/switch/configuration/guide/xcfnfc.html, last visited October 2013 [17] A. Botta, A. Dainotti, A. Pescap, "A tool for the generation of realistic network workload for emerging networking scenarios", Computer Networks (Elsevier), 2012, Volume 56, Issue 15, pp 3531-3547 [18] RFC 2544, S. Bradner and J. McQuaid, Benchmarking Methodology for Network Interconnect Devices, 1999 [19] Benchmarking Methodology Working Group charter, IETF, Available at http://datatracker.ietf.org/wg/bmwg/charter/, last visited October 2013 [20] RFC1901, J. Case, K. McCloghrie, M. Rose, S. Waldbusser, Introduction to Community-based SNMPv2, 1996 [21] RFC1158, M. Rose, Management Information Base for Network Management of TCP/IP-based internets: MIB-II, 1990 [22] RFC2819, S. Waldbusser, Remote Network Monitoring Management Information Base, 2000 [23] RFC2330, V. Paxson, G. Almes, J. Mahdavi, M. Mathis, Framework for IP Performance Metrics, 1998 [24] TCP STatistic and Analysis Tool, TSTAT, http://tstat.tlc.polito.it/index.shtml, Last visited October 2013
Version 1.5
Page 91 of 95

Public
[25] Alessandro Finamore, Marco Mellia, Michela Meo, Maurizio M. Munaf, Dario Rossi, Experiences of Internet Traffic Monitoring with Tstat, IEEE Network "March/April 2011", Vol.25, No.3, pp.8-14, ISSN: 0890-8044, March/April 2011 [26] TSTAT Publications list, TSTAT, http://tstat.tlc.polito.it/publications.php, Last visited October 2013 [27] CoralReef Software Suite, CAIDA (Cooperative Association for Internet http://www.caida.org/tools/measurement/coralreef/, Last visited October 2013 Data Analysis),
[28] K. Keys, D. Moore, R. Koga, E. Lagache, M. Tesch, and k. claffy, The architecture of CoralReef: an Internet traffic monitoring software suite'', in Passive and Active Network Measurement Workshop (PAM), Amsterdam, Netherlands, Apr 2001, RIPE NCC [29] RFC 2123: Traffic flow measurement: Experiences with NeTraMet,", 1997 [30] CAIDA publications list, CAIDA (Cooperative Association http://www.caida.org/publications/papers/, Last visited October 2013 for Internet Data Analysis),
[31] Passive Networks Monitors, CAIDA (Cooperative Association for Internet Data Analysis), http://www.caida.org/data/realtime/passive/?monitor=equinix-chicago-dirA, Last visited October 2013 [32] Thomas Karagiannis, Konstantina Papagiannaki, and Michalis Faloutsos. 2005. BLINC: multilevel traffic classification in the dark. SIGCOMM Comput. Commun. Rev. 35, 4 (August 2005), 229-240. DOI=10.1145/1090191.1080119 [33] S. Sezer, S. Scot_hayward, P. Kaur Chouhan, B. Fraser, D. Lake, J. Finnegan, N. Viljonen, M. Miller, N. Rao, Are we ready for SDN? Implementation Challenges for Software-Defined Networks, IEEE Communication Magazine, July 2013, pp. 35-37, DOI 10.1109/MCOM.2013.6553676 [34] ONF. Software-Defined Networking. The New Norm for Networks. White Paper available at https://www.opennetworking.org/sdn-resources/sdn-library/whitepapers [35] IP Performance Metrics Working Group charter, IETF, http://datatracker.ietf.org/wg/ippm/charter/, Last visited October 2013 [36] Spirent Communications, http://www.spirent.com/, Last visited October 2013 [37] Testing Challenges for Modern Networks Built Using SDN and OpenFlow, Spirent Communications, http://www.spirent.com/WhitePapers/Broadband/PAB/Testing_Challenges_for_Modern_NWs_Built_Using_SDN_and_OpenFLow, Last visited October 2013 [38] Endace DAG Cards, EMULEX Spa, http://www.emulex.com/products/network-visibility-products/thegenius-of-dag/features/, Last visited October 2013. [39] Net Market Share frequently asked questions, Market Share Statistics for Internet Technologies http://marketshare.hitslink.com/faq.aspx, Last visited October 2013 [40] RFC5481, A. Morton, B. Claise, Packet Delay Variation Applicability Statement, 2009 [41] RFC3917, J. Quittek, T. Zseby, B. Claise, S. Zander, Requirements for IP Flow Information Export (IPFIX), 2004 [42] Yottas Site Performance & Optmization blog, YOTTA, http://www.yottaa.com/blog/bid/265815/CokeSodaStream-the-13-Websites-That-Crashed-During-Super-Bowl-2013, Last visited October 2013 [43] CBRONLINE, Business Review Ltd, http://www.cbronline.com/news/tech/software/operatingsystems/ios-7-update-sees-web-traffic-doubledin-uk-and-germany-200913, Last visited October 2013 [44] The Rise and the Fall of P2P, DeepField inc, http://www.deepfield.net/2012/04/the-rise-and-fall-andrise-of-p2p/, Last visited October 2013 [45] Peer to peer Passe, Bryan Singel, http://www.wired.com/business/2009/10/p2p-dying/, last visited October 2013 [46] Sandvine Intelligent Broadband networks, Sandvine inc, Global Internet Phenomena Report 1H 2013, Tech. Rep., 2013
Page 92 of 95
Version 1.5

Public
[47] F. Strohmeier, H. Drken and B. Hechenleitner, Aquila distributed QoS measurement, Report in EU IST Aquilla project (2001) <st.inf.tu-dresden.de/AQUILA/files/pub/comcon8-spu-dist_qos_measurementpaper.pdf> [48] Cisco Visutla Networking Index: Forecast and Methodology, 2012-2017, CISCO SYSTEMS, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11481360_ns827_Networking_Solutions_White_Paper.html, Last visited October 2013 [49] G. Hasslinger, Efficiency of caching and content delivery in broadband access networks, chapter in Advanced content delivery and streaming in the cloud <www.cloudbus.org/cdn/advanced-CDN-book>, J. Wiley, to appear, 2013 [50] S. Schnitter, F. Hartleb and M. Horneffer, Quality-of-service class specific traffic matrices in ip/mpls networks, Internet Measurement Conference IMC (2007), pp. 253-258, DOI 10.1145/1298306.1298341 [51] The SmartenIT project, "Grant Agreement for STREP: Annex I 'Description of Work (DoW)'." 2012. [52] M. Wichtlhuber D. Hausheer: vINCENT: An Incentive-Scheme for Peer-to Peer Content Distribution Supporting Virtual Nodes". Conference on Networked Systems (NetSys 2013), PhD Forum, Stuttgart, Germany, March 2013. [53] Dropbox QoE: Philipp Amrehn, Karel Vandenbroucke, Tobias Hofeld, Katrien de Moor, Matthias Hirth, Raimund Schatz, Pedro Casas Need for Speed? On Quality of Experience for File Storage Services. to be published at the 4th International Workshop on Perceptual Quality of Systems (PQS 2013), Vienna, Austria, September 2013. [54] Youtube QoE:Tobias Hofeld, Dominik Strohmeier, Alexander Raake, Raimund SchatzPippi Longstocking Calculus for Temporal Stimuli Pattern on YouTube QoE.5th ACM Workshop on Mobile Video (MoVid 2013), Oslo, Norway, February 2013 [55] The SmartenIT project: Deliverable D1.1 - Report on Stakeholders Characterization and Traffic Characteristics; April 2013. [56] The SmartenIT project: Deliverable D3.1 - Report on Initial System Architecture; April 2013. [57] G. Hasslinger, A. Schwahn and F. Hartleb, Traffic Profiles and Management for Support of Community Networks, Proc. Innovative Internet Community Systems, VDE Verlag, Hagen, Germany (2013)
9 Abbreviations
3GPP AAA ALTO AS BGP BLINC CAPEX CCDF CCP CDN CPU CSP DDoS D-ITG
Version 1.5
3rd Generation Partnership Project Authentication, Authorization, Accounting Application-Layer Traffic Optimization Autonomous System Border Gateway Protocol BLINd Classification Capital Expenditure Complementary Cumulative Distribution Function Critical Peak Pricing Content Delivery Network Central Processing Unit Cloud Service Provider Distributed Denial of Service Distributed Internet Traffic Generator
Page 93 of 95

Public
DoW EEF GPS GSM HTTP IaaS ICC IETF IPTV ISDN ISP IT IXP KPI MIB MOS NaDa NOC NTP OID OLA OPEX OSN OTT P2P PaaS PASS QoE QoS RMON RTDS SaaS SAW SDN
Description of Work Energy Efficiency scenario Global Positioning System Global Service Mobility scenario Hyper Text Transfer Protocol Infrastructure-as-a-Service Inter-cloud Communication scenario Internet Engineering Task Force Internet Protocol Television Integrated Services Digital Network Internet Service Provider Information Technology Internet Exchange Point Key Performance Indicator Management Information Base Mean Opinion Score Nano Data Center Network Operator Centers Network Time Protocol Object Identifier Operational Level Agreement Operational Expenditures Online Social Network over The Top Peer-to-peer Platform-as-a-Service Performance, Availability, Security, Scale Quality-of-Experience Quality-of-Service Remote Network Monitoring Round Trip Delay Synchronization Software-as-a-Service Social Awareness scenario Software Defined Network
Page 94 of 95
Version 1.5

Public
SHD SmoothIT SNMP SLA STREP TCP TE ToU UDP uNaDa VoD VoIP VPN xDSL Simple Economic Management Approaches of Overlay Traffic in Heterogeneous Internet Topologies Simple Network Management Protocol Service Level Agreement Specific Targeted Research Project Transmission Control Protocol Traffic Engineering Time-of-Use User Datagram Protocol User-owned Nano Data Center Video on-demand Voice Over IP Virtual Private Network x Digital Subscriber Line
10 Acknowledgements
This deliverable was made possible due to the large and open help of the WP1 team of the SmartenIT team within this STREP. And it had been project-internally reviewed by Burkhard Stiller and Gerhard Halinger. Many thanks to all of them.
Version 1.5
Page 95 of 95

Deliverable D1.2 Report On of Cloud Service Classifications and Scenarios

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deliverable D1.2 Report On of Cloud Service Classifications and Scenarios

Uploaded by

Copyright:

Available Formats

Seventh Framework STREP No.

D1.2 - Report on Cloud Service Classifications and Scenarios