Deliverable D4.3 - Prototype Evaluations and Overall Project Assessment

8/15/2019 Deliverable D4.3 - Prototype Evaluations and Overall Project Assessment

1/177

Seventh Framework STREP No. 317846 D4.3Public

Version 1.0 Page 1 of 177 © Copyright 2015, the Members of the SmartenIT Consortium

Socially-aware Management ofNew Overlay Application Traffic with

Energy Efficiency in the Internet

European Seventh Framework Project FP7-2012-ICT-317846-STREP

Deliverable D4.3Prototype Evaluations and Overall Project

Assessment

The SmartenIT Consortium

Universität Zürich, UZH, Switzerland Athens University of Economics and Business - Research Center, AUEB, GreeceJulius-Maximilians Universität Würzburg, UniWue, GermanyTechnische Universität Darmstadt, TUD, Germany Akademia Gorniczo-Hutnicza im. Stanislawa Staszica w Krakowie, AGH, PolandIntracom SA Telecom Solutions, ICOM, Greece Alcatel Lucent Bell Labs, ALBLF, FranceInstytut Chemii Bioorganicznej PAN, PSNC, PolandInteroute S.P.A, IRT, ItalyTelekom Deutschland GmbH, TDG, Germany

© Copyr ight 2015, the Members of the SmartenIT Consortium

For more information on this document or the SmartenIT project, please contact:

Prof. Dr. Burkhard StillerUniversität Zürich, CSG@IFIBinzmühlestrasse 14CH—8050 ZürichSwitzerland

Phone: +41 44 635 4331

Fax: +41 44 635 6809E-mail: [email protected]


2/177


3/177


4/177

D4.3 Seventh Framework STREP No. 317846Public

Page 4 of 177 Version 1.0 © Copyright 2015, the Members of the SmartenIT Consortium

Table of Contents

Amendment His tory 2

List of Figures 6

List of Tables 9

1 Executive summary 11

2 Introduction 13 2.1 Purpose of the Document D4.3 13 2.2 Document Outline 13

3 SmartenIT in the current Internet 15 3.1 Stakeholders’ roles 16 3.2 Mechanisms’ landscape 20 3.3 System architecture 24

3.3.1

Implementation process 26

3.4 Business perspective and applicability to main IP traffic categories 27

4 Assessment cr iter ia and methodology 31 4.1 Methodology for Parameters and Metrics 31 4.2 Traffic Management Mechanism Evaluation Criteria 32

4.2.1 OFS: ICC, DTM & DTM++ 32 4.2.2

EFS#1: RB-HORST Caching 35

4.2.3 EFS#2: RB-HORST Large Scale Study 37 4.2.4 EFS#3: MONA (including EEF) 39 4.2.5 EFS#4: MUCAPS 41

4.3 Metrics, Parameters, and Assessment Summary 42

5

Testbed experiments results and assessment 45 5.1 OFS experiments 47

5.1.1 OFS#1.1 (S-to-S Volume based charging rule) 49 5.1.2 OFS#1.2 (S-to-S 95% percentile based tariff) 57 5.1.3 OFS#1.3 (S-to-S 95% rule) 65 5.1.4 OFS#2.1 (M-to-M volume) 70 5.1.5 OFS#2.2 (M-to-M 95% rule) 77

5.2 EFS experiments 84 5.2.1 EFS#1: Evaluation of Caching Functionality in RB-HORST 84 5.2.2 EFS#2: Evaluation of RB-HORST large scale study 89 5.2.3 EFS#3: Energy consumption of RB-HORST 93 5.2.4

EFS#4: MUCAPS 103

6

Assessment of project outcomes 114

6.1 Assessment of stakeholders’ benefits and costs 114 6.1.1 Cost-benefit analysis of DTM/DTM++ 115 6.1.2 Cost-benefit analysis of RB-HORST 122 6.1.3 Cost-benefit analysis of MUCAPS 130

6.2 SWOT analysis 136 6.2.1 DTM/DTM++ 137 6.2.2 RB-HORST 138 6.2.3

MUCAPS 139

7 Overall assessment 140 7.1 Key design goals addressed 147

7.1.1 Incentive compatible network management mechanisms 147 7.1.2 QoE-awareness 153 7.1.3

Social awareness 154

7.1.4

Energy Efficiency 155


5/177



7.2 Assessment of SmartenIT outcomes from an industrial point of view 156 7.3 Project objectives addressed 157

8 Summary and conclusions 161

9 SMART Object ives 164

10 References 167

11 Abbreviations 170

12 Acknowledgements 173

13 Appendices 174 13.1 Testbed extension: Odroid-C1 174

13.1.1 Overview 174 13.1.2

OS and Extra Packages Installation 174

13.2 Testbed extension: Remote Access for Admins with OpenVPN 175 13.3 Testbed extension: Hardware testbed 176


6/177



List of Figures

Figure 1: The SmartenIT ecosystem and the involved architectural entities. ..................... 24

Figure 2: The DTM architecture (a) and deployment (b) diagrams .................................... 25

Figure 3: The RB-HORST architecture (a) and deployment (b) diagrams ......................... 25

Figure 4: SmartenIT Entities and components involved in MUCAPS ................................. 26

Figure 5: Variable and static parameters and type of experiments .................................... 44

Figure 6: Logical topology for S-to-S experiment ............................................................... 47

Figure 7: Logical topology for M-to-M experiment .............................................................. 48

Figure 8: Traffic growth during the billing period and a cost map. SDN controllermode: "reactive with reference". (OFS#1.1) ....................................................... 54

Figure 9: Traffic patterns on link 1 and 2 during the billing period. SDN controllermode: "reactive with reference". (OFS#1.1) ....................................................... 55

Figure 10: Compensation vector values received by remote SBox (AS3 domain). SDNcontroller mode: "reactive with reference". (OFS#1.1) ...................................... 56

Figure 11: Compensation vector values received by remote SBox (AS3 domain). SDNcontroller mode: "reactive without reference". (OFS#1.1) ................................. 56

Figure 12: 5-min samples observed on inter-domain links during a single 7-day longbilling period (OFS#1.2) .................................................................................... 60

Figure 13: Distributions of 5-min samples collected during a single 7-day long billingperiod (OFS#1.2) .............................................................................................. 61

Figure 14: The distribution of 5-min sample pairs on a cost map. (OFS#1.2) .................... 62

Figure 15: The distribution of 5-min sample pairs - long flows, reactive mode................... 64

Figure 16: The distribution of 5-min sample pairs - long flows, proactive mode................. 64

Figure 17: Traffic patterns on link 1 and 2 during the billing period. (OFS#1.3) ................. 67

Figure 18: 5-min samples observed on inter-domain links during a single 1-day longbilling period (OFS#1.3) .................................................................................... 68

Figure 19: 5-min samples observed on inter-domain links during a single 1-day longbilling period when hierarchical policer is inactive; only DTM operates(OFS#1.3) ......................................................................................................... 69

Figure 20: Traffic growth during the billing period and a cost map. Domain AS1.(OFS#2.1) ......................................................................................................... 74

Figure 21: Traffic growth during the billing period and a cost map. Domain AS4.(OFS#2.1) ......................................................................................................... 75

Figure 22: The distribution of 5-min sample pairs on a cost map in domain AS1(OFS#2.2) ......................................................................................................... 80

Figure 23: The distribution of 5-min sample pairs on a cost map in domain AS4(OFS#2.2) ......................................................................................................... 81


7/177



Figure 24: 5-min samples observed on inter-domain links LA1 and LA2 (AS1) at theend of billing period (OFS#2.2) ......................................................................... 83

Figure 25: Testbed setting for evaluation of caching functionality ...................................... 86

Figure 26: Cache hit rate with varying number of devices ................................................. 86

Figure 27: Transferred data with varying number of devices ............................................. 87

Figure 28: Cache hit rate with varying request time interval .............................................. 87

Figure 29: Transferred data with varying request time interval .......................................... 88

Figure 30: Cache efficiency in large scale study trace ....................................................... 88

Figure 31: Overlay of uNaDas after large scale study ....................................................... 90

Figure 32: Number of video views ..................................................................................... 90

Figure 33: Cache efficiency ............................................................................................... 91

Figure 34: Location of request processing ......................................................................... 91

Figure 35: Prefetching overhead ........................................................................................ 92

Figure 36: Quality of Experience for videos served by uNaDas ......................................... 92

Figure 37: Activity patterns of the participating smartphones ............................................. 95

Figure 38: RTTs as measured from the smartphones ....................................................... 96

Figure 39: Network uplink as measured from the smartphones ......................................... 97

Figure 40: Network downlink as measured from the smartphones .................................... 98

Figure 41: Measured CDF of the power consumption of the smartphones using 3Gand WiFi ............................................................................................................ 98

Figure 42: CDF of the power consumption using identical traffic traces and the powermodel of the Nexus 5 for the individual interfaces............................................. 99

Figure 43: Activity patterns of the participating uNaDas .................................................. 101

Figure 44: CDF of the power consumption over the uNaDas participating in the study ... 102

Figure 45: MUCAPS prototype set-up ............................................................................. 105

Figure 46: Screenshot with MUCAPS OFF for all types of UEP access .......................... 106

Figure 47: Screenshot for MUCAPS ON + (RC, BWS) when the UEP has a LAN/FTTXaccess ............................................................................................................. 107

Figure 48: Screenshot for MUCAPS ON + (RC, BWS) when the UEP has a WiFiaccess ............................................................................................................. 107

Figure 49: Screenshot for MUCAPS ON + (RC, BWS) when the UEP has a 3G access . 108

Figure 50: GÉANT network topology in Europe ............................................................... 117

Figure 51: CAPEX and OPEX for a medium-sized ISP on an 8-year basis forDTM/DTM++. .................................................................................................. 119

Figure 52: DC traffic evolution and estimated traffic savings due to DTM/DTM++ on an

8-year basis. ................................................................................................... 120 Figure 53: Forecasted values of the price of transit for the next 8 years [39]. .................. 120


8/177



Figure 54: Total costs vs. total benefits for DTM/DTM++ (benefits are calculated bothfor 8% and 15% traffic savings). ..................................................................... 121

Figure 55: Overall economic gains assessment of DTM/DTM++. .................................... 121

Figure 56: Tiered caching scenario. ................................................................................. 124

Figure 57: Expected adoption rate of RB-HORST. .......................................................... 127

Figure 58: CAPEX and OPEX for a medium-sized ISP on an 8-year basis forRB-HORST. .................................................................................................... 128

Figure 59: Video traffic evolution and estimated traffic savings due to RB-HORST onan 8-year basis. .............................................................................................. 128

Figure 60: Total costs vs. total benefits (benefits are calculated both for 50% and 75%traffic savings). ................................................................................................ 129

Figure 61: Overall economic gains assessment for RB-HORST. ..................................... 130

Figure 62: MUCAPS employed for transparent in-network optimization. ......................... 133

Figure 63: Evolution of SmartenIT solutions .................................................................... 143

Figure 64: Sequences of incentives for DTM and DTM++ in the context ofstakeholders relations ..................................................................................... 150

Figure 65: General overview of hardware testbed extension ........................................... 176


9/177



List of Tables

Table 1: SmartenIT mechanisms mapping ........................................................................ 30

Table 2: Performance metrics for ICC ............................................................................... 32

Table 3: ICC parameters.................................................................................................... 32

Table 4: Performance metrics for DTM .............................................................................. 33

Table 5: DTM parameters .................................................................................................. 34

Table 6: Caching functionality metrics in RB-HORST ........................................................ 35

Table 7: Caching functionality parameters in RB-HORST ................................................. 36

Table 8: Large scale RB-HORST study metrics ................................................................. 37

Table 9: Large scale RB-HORST study parameters .......................................................... 38

Table 10: MONA performance metrics............................................................................... 39

Table 11: MONA parameters (selected configuration underlined) ..................................... 40

Table 12: MUCAPS performance metrics .......................................................................... 41

Table 13: MUCAPS parameters ........................................................................................ 42

Table 14: SmartenIT metric categories mapping ............................................................... 43

Table 15: Experiment summary ......................................................................................... 45

Table 16: Experiment Report Card Template .................................................................... 46

Table 17: Total traffic costs achieved with DTM and expected without DTM obtainedfor various SDN controller modes (OFS#1.1) ..................................................... 53

Table 18: KPI values for DTM run with various SDN controller modes (OFS#1.1) ............ 53

Table 19: The number of vector updates exchanged by SBox-es during the billingperiod ................................................................................................................. 57

Table 20: Inter-domain traffic costs and KPI values for DTM (OFS#1.2) ........................... 59

Table 21: Manageable traffic generator setting for generation of long flows ...................... 63

Table 22: Inter-domain traffic costs in domains AS1 and AS4. (OFS#2.1) ........................ 76

Table 23: KPI for AS1 and AS4 (OFS#2.1) ........................................................................ 76

Table 24: Inter-domain traffic costs in domains AS1 and AS4. (OFS#2.2) ........................ 82

Table 25: KPI for AS1 and AS4 (OFS#2.2) ........................................................................ 82

Table 26: Analysis of the device activity ............................................................................ 95

Table 27: Comparison of the power measurements for 3G and WiFi while active ............. 99

Table 28: Results of the simulation using different interfaces .......................................... 100

Table 29: Measured power consumption of the uNaDas ................................................. 102

Table 30: ISP-specific ALTO values for RC and BWS chosen for the 3 AEP classes ..... 105

Table 31: Metric weights chosen for the 3 tested access types ....................................... 105


10/177



Table 32: IP addresses of the 3 video servers ................................................................. 106

Table 33: AEP performances in CLU for all 4 MUCAPS modalities for LAN access ........ 108

Table 34: AEP performances in CLU for all 4 MUCAPS modalities for WiFi access ....... 109

Table 35: AEP performances in CLU for all 4 MUCAPS modalities for 3G access .......... 109

Table 36: Name, resolution and bitrate of the six videos used for the prototypevalidation .......................................................................................................... 109

Table 37: QoE analysis results when streaming the test videos, for all access types ...... 110

Table 38: Impact of MUCAPS on video streaming QoE for LAN/FTTX UEP access ....... 111

Table 39: Impact of MUCAPS on video streaming QoE for WiFi/ADSL UEP access ...... 112

Table 40: Impact of MUCAPS on QoE for video streaming for 3G UEP access .............. 112

Table 41: Traffic management mechanisms developed by SmartenIT ............................ 141

Table 42: Overall SmartenIT SMART objective addressed. (Source: [1]) ........................ 164

Table 43: Practical SmartenIT SMART objective addressed. (Source: [11]).................... 164


11/177



1 Executive summary

This document is Deliverable D4.3 of SmartenIT project. It is entitled “PrototypeEvaluations and Overall Project Assessment” and documents the results of validation and

performance evaluations of the mechanisms implemented within the SmartenIT project.All measurable results, including traffic measurements, metrics on performance,robustness, energy efficiency, and QoE, and results obtained by means of experiments,simulations, and theoretical investigations are provided in the first part of this deliverable.The second part of the deliverable is devoted to the overall assessment of the solutionsand mechanisms proposed by the SmartenIT project. It contains the broad picture fromvarious points of view (such as perspectives of different stakeholders, single layer andcross-layer views, incentives of stakeholders, various business models and scenarios, andnew technologies implemented within SmartenIT), based on all methods applied (theory,modeling, experiments) and evaluation techniques utilized (simulations, testbed). Finalproject conclusions as well as implementation guidelines and usability assessment arealso provided in this document. The deliverable also outlines the major achievements ofthe SmartenIT project as a whole with respect to its general approach and its specificnetwork management mechanisms.

To this end, this deliverable first positions SmartenIT solutions and traffic managementmechanisms in the current Internet taking into account the perspective of stakeholders andcurrent challenges. SmartenIT has conducted a deep analysis of the current Internet, intwo main complementary and synergetic directions, which thus led to the development oftwo scenario categories, namely OFS (Operator Focused Scenario) and EFS (End-userFocused Scenario), OFS is dedicated to the interaction among stakeholders acting asCloud and particularly as Internet Service Providers, while EFS is centered on the end-

user and its interaction with other users as well as the Cloud. The main SmartenITmechanisms pertaining to OFS (namely ICC, DTM and their superposition DTM++)constitute powerful tools for service differentiation and OPEX reduction for ISPs, thuscontributing both to cost reduction and value generation aspects of ISPs’ business. Thesemechanisms have consciously been designed for the Best Effort Internet, but can also beadapted under a Differentiated Services model and/or under Beyond Best Effort Internet.Also, MRA ensures a fair resource allocation among federated Cloud Service Providers.

Regarding EFS, all relevant SmartenIT mechanisms are suitable for certain businesscontexts. The business context that is most relevant for RB-HORST (which is thecombination of several mechanisms) is the Terminal and Service business model. Also,

the SmartenIT EFS mechanisms, namely RB-HORST, SEConD, vINCENT, MONA, andMUCAPS that can deliver energy efficiency, advanced services and resourcemanagement, increased agility and performance, can be very useful means for newdifferentiated services and terminal operations, such as cloudlets.

Furthermore, the deliverable summarizes evaluation criteria, methodologies and metricsused for assessment of traffic management mechanisms selected for testbed experimentsand reports about the testbed experiments results and assessment achieved duringSmartenIT validation activities. It should be noted that all runs in the testbeds includedboth a functional test assessment and a performance test. For the OFS experiments ofDTM and DTM++, a virtualized testbed environment was employed, with four testbedinstances launched in three SmartenIT partners’ premises, and covering both Single-to-Single and Multi-to-Multi domain topologies with a tariff based on both volume and 95thpercentile. The EFS experiments evaluate caching and energy consumption in RB-HORST


12/177



as well as Quality of Service of videos for MUCAPS. In fact, the large-scale study for RB-HORST involved the provision of videos to users in the premises of five different partners.

Additionally, other dimensions of assessment of SmartenIT solutions and finallyimplemented traffic management mechanisms are introduced and a deep analysis of costs

and benefits for the deployment of SmartenIT solutions expected over next couple of yearsis provided together with a SWOT analysis.

Finally, an overall assessment of all SmartenIT solutions and mechanisms is done, whichserves as a summary for all project activities and outcomes. A map of solutions and stageof development and achieved maturity is presented and a summary is given about howkey design goals and objectives defined at the project beginning were achieved andaddressed. In particular, the main conclusions of this final assessment are as follows:

For the OFS scenario, DTM/DTM++ proves to be an excellent solution to be casted overthe ISP domain, mainly because: a) it is based on incentive collaboration among differentadministrative domains by providing a technical framework allowing traffic management

between Cloud and ISP in a win-to-win situation, b) it resolves the problem of informationasymmetry by providing partial information exchange between cloud layer and networklayer, thus providing cross-layer aware traffic management, c) it boosts the CloudFederation business models, thus demonstrating that SmartenIT solutions for the OFSscenario are well deployable both for large scale Cloud and Internet Service Providers andfor smaller ones that together widen their geographical footprint, d) it optimizes inter-cloudtraffic by providing an excellent tool to optimally route the selected inter-domain traffic, e) itis a non-disruptive solution, meaning that they can be deployed over provider domainswithout changing the entire infrastructure, with a high deployability potential.

For the EFS scenario, the SmartenIT prototype and the related artifacts have proved to be

a stable solution capable to achieve good and measurable performances, and to be castedin real-world large scale deployments over a wide geographical area with an accordinglyhigh number of end-users. Selected EFS traffic management mechanisms proved to be anexcellent solution, mainly because: a) They provide a technical framework that allowstraffic management between the Cloud provider and the end-user in a win-to-win fashion,b) they entail incentive-based collaborations among end-users based on a novel trustschema that leverages on social awareness information, c) they achieve energy efficiencyfor end-user mobile devices and significant enhancement of Quality of Experience asperceived by the end-user, d) they provide novel content caching and prefetching schemesfor content downloading, thus indirectly attaining savings of inter-domain traffic and energyefficiency in the provider’s domain due to traffic localization, and e) they are easily

deployable over end-user's and ISP's premises with negligible impact on the existinginfrastructure.

Overall, the SmartenIT solutions evaluated with the elaborated methodology reported inthis deliverable constitute a stable technical framework with measurable performance thatensures concrete benefits for the involved stakeholders (including traffic and energysavings), high deployability capabilities over both the ISP's infrastructure and the end-user's premises, high configurability in terms of functionalities and capabilities, and goodpositioning in the actual cloud landscape, thus fulfilling all major objectives of theSmartenIT project.


13/177



2 Introduction

Deliverable D4.3 reports the outcome of task T4.3 (Evaluation of Prototype) and task T4.4(Overall Assessment). The goal of task T4.3 was to conduct the validation and

performance evaluation of the SmartenIT prototype based on the application use casesand experiments identified in task T4.2. Specifically, the prototype developed in WP3 hadto be parameterized and deployed on top of the mobile and wired testbed defined in taskT4.1 and had to be evaluated with respect to scenarios, metrics, and characteristicdimensions defined in task T4.2. This includes the efficiency, scalability, and energy-awareness of the developed network management mechanisms. The aim of theseevaluations was to reveal the positive impact of the mechanisms of SmartenIT on networktraffic load and on performance parameters, the potential for cost savings, and trade-offsbetween energy efficient computation in the cloud and energy consumption on mobile end-user devices, ultimately measurable in overall energy savings and cost efficiency.

In parallel to task T4.3, the goal of task T4.4 was to assess all results achieved withrespect to the performance evaluations of task T4.3 as well as the overall projectoutcomes, including model and simulation based evaluations carried out within WP2. AlsoQoE assessment based on theoretical models and subjective tests had to be performed,interpreted, and summarized within task T4.4. Benefits from the deployment of SmartenITsolutions for respective stakeholders were also evaluated and documented. Thisassessment provides valuable interpretations of the results, to outline the majorachievements of the SmartenIT project as a whole with respect to both its specific networkmanagement mechanisms (and the circumstances under which they are efficient) and itsgeneral approach. This approach also enables the provision of feedback to the theoreticalwork carried out by WP2 (theory) and to the engineering work carried out by WP3

(engineering) as well as the final system-related and research-related public messages tothe interested stakeholders.

2.1 Purpose of the Document D4.3

The purpose of Deliverable D4.3 is to document the results of validation and performanceevaluations of the mechanisms implemented within the SmartenIT project. To this end, allmeasurable results including traffic measurements, performance metrics, robustness,energy efficiency, and QoE are provided here. Moreover, this deliverable aims to providean overall assessment of those solutions and mechanisms proposed by the SmartenITproject and to derive the final project conclusions as well as give implementation

guidelines and usability assessment. Finally, the deliverable also aims to outline the majorachievements of the SmartenIT project as a whole with respect to its specific networkmanagement mechanisms and the general approach.

2.2 Document Outline

The remainder of this deliverable is organized as follows. An overview on SmartenIT in thecurrent Internet is given in Section 3. The goal of this section is to position SmartenITsolutions and traffic management mechanisms in the current Internet taking into accountperspective of stakeholders and current challenges. It also serves as introduction to othersections by reminding main project outcomes. SmartenIT system architecture is also

summarized. Moreover, Section 4 provides a description of the assessment criteria andmethodology. This section summarizes evaluation criteria, methodologies and metrics


14/177



used for assessment of traffic management mechanisms selected for testbed experimentsas presented later in Section 5. The metrics are categorized as economic, performance,and user experience metrics. Moreover this section provides a business perspective onassessment of project outcomes. Additionally, testbed experiments results and

assessment achieved during SmartenIT validation activities are given in Section 5. Resultsof several experiments are presented and discussed. Evaluations are done with usingmethodologies and metric presented in Section 4. Furthermore, Section 6 provides theassessment of the main project’s outcomes. This section introduces other dimensions ofassessment of SmartenIT solutions and finally implemented traffic managementmechanisms. It provides a deep analysis of costs and benefits of deployment of SmartenITsolutions expected over next couple of years. Additionally, a SWOT analysis is presented.Finally, an overall assessment of all SmartenIT solutions and mechanisms proposed isgiven in Section 7. This section serves as summary for all project activities and outcomes.It presents a map of solutions and stage of development and maturity they achieved. Italso summarizes how key design goal and objectives defined at the project beginning

were achieved and addressed. Section 8 summarizes and concludes this deliverable.


15/177



3 SmartenIT in the current Internet

In recent years the emerging Cloud paradigm has caused a great impact on the Internetlandscape, where Cloud can be intended, at least from a very general point of view, as a

new way to offer products and services to the end-users. Superimposed to the impact ofCloud paradigm (and correlated to it from both direct and indirect perspective), otherimportant shifts/trends should be considered, like the exponential growth of end/usermobile access capabilities, the increase request to enhance the capabilities foruser/service mobility, the increasing focus of energy efficiency topics (intended as bothimpacting over service provider and end-user domain), the emerging importance of socialnetwork frameworks and its exploitation potentialities.

All the abovementioned key topics have caused a certain number of broad effects onInternet landscape which can be summarized in the following main points:

A great traffic increase driven by the new applications has a tremendous impact

over actual global network built over ISP infrastructure. Cloud traffic, which can beseen in the majority of cases as overlay traffic, is not directly managed by ISPorganizations and these results in poor end to end traffic management capabilities.

The emergence of new requirements from end-user point of view and the metrics toevaluate them. In the Cloud era, the QoE metric (an aggregate metric whichmeasures end-user experience with a purchased service) is gaining importance.

A new landscape of interactions between different parties. Typically a Cloud serviceto be offered to end-user is composed by a combination of technology which spanacross multiple domain of service providers resulting in an end to end vertical andhorizontal macro-composition. Moreover it should be noted that Cloud service

should be perceived in a transparent way from end-user, which means that end-users must not be aware of the underlying framework used to provide the service.In this multisided and complex landscape. All these topics foresee a new framework(from both technical and business point of view) which could encompass cross-layer and cross-domain interaction among service providers in order to satisfy theend-to-end SLA increasing requirements.

The role of end-user is continuously becoming more central and is also shifting froma passive role (where he just receives a service), to a more active role with thepossibility to interact with other users (social networks) and to interact with serviceproviders itself (in the form of Nano Datacenters) by allowing the provider to utilize

the equipment at customer premises as additional computing/storage resources.SmartenIT project has conducted deep analysis which has been oriented in two maincomplementary and synergetic directions.

The first direction is the analysis of Cloud landscape from the point of view of stakeholdersand their relationships, in order to understand their requirements and their conflictingneeds and trying to form/devise/develop a rationale which can convert those conflictinginterests into synergetic/collaborative ones. This analysis has led to the development oftwo scenario categories, namely OFS (Operator Focused Scenario) and EFS (End-userFocused Scenario), which summarize two complementary perspectives of the Cloudlandscape. The first is dedicated to the interaction among stakeholders acting as service

providers while the second is centered on end-user and its interaction with the other usersas well as the Cloud.


16/177



The second direction is the analysis of suitable Traffic Management mechanisms (andtheir composition) to be casted over the two reference scenarios and which are intended tomitigate the drawbacks of the Cloud landscape by mitigating inter-cloud traffic impact overproviders domain, by providing new schemas for efficient content caching and pre/fetching

and by providing a framework which forecast collaboration among multiple independentdomains. Traffic management mechanisms have been designed to span across a certainnumber of SmartenIT entities (SBox implementing the SmartenIT logic, the SDNController , the Network Entity, the uNaDa, i.e., an enhanced home gateway and theEnd User Entity) that constitute the SmartenIT architecture. The overall SmartenITarchitecture has been designed to be modular in order to be deployable over differentscenarios according to the actual needs.

In the next subsection, the main results of SmartenIT analysis will be reported with focuson:

SmartenIT stakeholders descriptions (roles, need, interests and conflicts)

SmartenIT traffic management mechanisms (divided on a per scenario basis, withproper focus on their features and the enhancements they are able to produce)

SmartenIT architecture (high level description with focus on SmartenIT entities andits deployment capabilities on different scenarios)

3.1 Stakeholders’ roles

Five actors can be identified within the SmartenIT ecosystem, namely Cloud ServiceProviders, Data Center Operators, Internet Service Providers, End Users, and the SocialInformation Provider. Their interactions will be described in this section.

The main interest of the Cloud Service Provider (CSP) is the monetization of servicespurchased by the end users. Satisfaction of end users is a crucial issue. To ensure thisgoal, the QoS as well as the energy requirements should be met. Collecting and utilizingsocial information, new services may be offered. The CSP attempts to attract demand anddifferentiate its product offerings so as to serve various market segments with differentprices/packages and consequently extract as much of its customers surplus as possible.The monetization can also be achieved by either making the end-user accept a certainlevel of advertisement or by introducing systems that prevent users from accessingwebpage content without a paid subscription to the service. On the other hand, there ispressure to keep the costs for ISP infrastructure and Cloud resource consumption low, i.e.,

for renting resources from Data Center Operators. Its main concern is also to respect theSLAs with its customers and properly dimension its infrastructure to cover the respectivedemand and redundancy requirements. The CSP also needs to interact with the ISP tomake sure that the provided network meets the requirements of the provided cloudservice. Interconnection with other CSPs can reduce the transit fees a CSP pays to theISP.

The Data Center Operator (DCO) is primarily concerned with the efficient use of itsinfrastructure, i.e., make the best use of its resources while minimizing energyconsumption for the completion of the maximum possible amounts of task. It is possiblethat a part of its infrastructure is purchased from some CSP under an IaaS or PaaS model.Monetization of infrastructure is done by guaranteeing satisfactory QoS/QoE parameters

for end users. Its main concern is to respect the SLAs it has with its customers, which mayalso be CSPs, and properly dimension its infrastructure to cover the respective demand


17/177



and reduce its costs. Reduction of costs, in this case, focuses on best possible utilizationof hardware – both resource-wise and energy-wise. In particular, it aims to improve theutilization of its servers, to avoid or limit congestion on its links and platform; as well as tolimit the energy consumption by its data centers. An important factor for its costs besides

energy is transit costs for the data transfers. An emerging trend is datacenterinterconnection, similarly to the donut peering model of ISPs [44]: Datacenters aregradually interconnecting with other datacenters via exchange points so as to reducetransit costs. Another interesting emerging prospect is that of federations [44]: since in thedata center business multi-location presence and locality in execution of tasks is crucial soas to be competitive, small data center operators may team up and build a federation bycombining their resources and aligning their business processes so as to appear as alarge “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 definingwhat are the rights and obligations of each federation member.

The Internet Service Provider (ISP) aims at maintaining good quality in his network,which will give him a competitive edge in the market and ultimately a good RoI (Return onInvestment). This means that ISPs are interested in optimizing the network bandwidthutilization, while avoiding congestion, and preserving low latency. The ISP interacts withother ISPs via peering and possibly transit agreements for the management of the traffic ofhis customers, both upstream and downstream. Providing guarantees for the delivery ofportions 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 revenuefor the ISP. This can be increased by high quality of network services that lead to highersatisfaction of DCOs and also of end users. Supporting new services, possibly byemploying additional information (with the main example here being social information),

may be attractive and simultaneously make ISPs more competitive towards end users andcloud providers. Offering new services to CSPs would open new market opportunities forISPs. The main goal of the ISP is manage the incoming traffic that is possibly delivered tohim via multiple interconnection points. An additional goal for Tier-1 and Tier-2 ISPs is tosell transit interconnection agreements to other ISPs, DCOs and CSPs. At the same timeown charged transit link traffic has to be kept as low as possible. Applying Traffic Engineersolutions to prioritize the traffic of his customers according to the respective value/costtradeoff are used in parallel with the management of inter-domain business agreementsand establishment of presence in Internet exchange points and areas that can attractdemand from customers.

End users are to a large extent unaware of the business agreements and interactions

among the other stakeholders being primarily a client of ISP and CSP. The only thing theyare aware of is the description and cost of the services they purchase, mainly Internetaccess from an ISP, file hosting from a CSP. The end users are sensitive to the reliabilityand availability of the service, the support they receive when needed, as well as theperformance of the service and the resulting QoE attained. All those features are typicallydefined in the contract/SLA of the service between the end user and the respective serviceprovider. In case multiple providers are needed for the provisioning of a certain service,the respective interactions are hidden to the end user due to the nesting of the internalSLA, who solely interacts with a single point of service, i.e., the provider from which he haspurchased the end-to-end service. The end user’s main concerns are its own QoE,network access cost, and energy consumption. The energy efficiency of services andnetwork access are factors 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


18/177



lifetime when using a mobile device). It is noteworthy, that costs in case of end user oftencan be expressed by being exposed to advertisements instead of being involved inmonetary flow. Typically, the end user will not be interested in disclosing social informationdirectly; however, it may be willing to give it up for some profit or improved QoS/QoE.

The Social Information Provider wants to monetize the social information he owns.Therefore, it can sell the social information to CSPs, DCOs, or ISPs. If the information canbe used to improve a service, this creates incentives for end users to provide informationto the Social Information Provider. If the Social Information Provider offers a service itselflike an Online Social Network (OSN), these incentives lead to a higher number of usersOSN, which can further increase revenue (e.g., advertisement) of its service.

Having presented the main stakeholders and their roles, we now provide some insight ontheir business relationships and interactions, as well as tussles amongst them in thecontext of Best Effort Internet and beyond.

Asymmetric information between the ISP and the buyer of connectivity service is a major

issue, since ISP networks are black boxes to other ISPs and cloud/application serviceproviders, rendering inter-domain monitoring impossible. Networks do not allow otherparties to monitor their network performance and do not provide to their customers anyguarantees besides uptime. Furthermore, ISPs do not exchange any quality or controlinformation and there is lack of reward schemes for ISPs that would be willing to provideassured quality to inter-domain traffic since networks solely exchange data and BGPinformation, lacking standardized service-aware inter-provider service coordination in bothbusiness and technical layer. This is also due to the fact that interconnection contractspertain to large traffic aggregates, thus there is no service-specific overlay foroptimizations, and provide only uptime guarantees and absolutely no guarantees onquality.

This lack of end-to-end inter-provider SLAs and respective multi-provider service-awareconnectivity products drives high quality out of the market according to Akerlof’s theory onmarket of lemons [45] : since there are no quality guarantees, it is impossible for buyers topredict the quality of inter-domain flows Thus they expect – and bias their willingness topay on – the average quality observed in the market Average quality is by definition lowerthan that of high-quality connectivity thus essentially driving any higher-quality connectivityproduct out of the market and resulting in a market of lemons. This is also evident in thecontext of mobile networks where content delivery is highly monetized and thus any qualitydegradation is unacceptable: extranet solutions such as IPX are increasingly popular thuscreating an alternative to Internet and a potential threat to the applicability of the latter for

sustaining the business of content delivery especially due to the increasing number ofmobile users and sophisticated mobile terminals.

ISPs’ possible opportunistic routing and/or prioritizing own flows over inter-domain trafficfurther mitigate quality of service. Overall, these inefficiencies are due to the lack ofservice-aware coordination and cooperation among ISPs, clouds as well as between ISPsand clouds, further rendering inter-provider cloud and content service provisioningproblematic and greatly affecting the end-users’ QoE. This issue is also of particularinterest to Europe and similar areas, where there are typically multiple geographically-limited ISPs, data centers and cloud service providers without global Information andCommunication Technology infrastructure, rendering intra-provider traffic management

and cross-layer network-cloud layer optimization solutions inadequate


19/177



To this end, data centers, CDNs and proxy servers attempt to mitigate these well-knowninefficiencies to some extent and improve service performance by bringing data andservices closer to the users. Therefore, it is interesting that the inefficiencies of the existingInternet and the resulting degradation in the service quality actually constitute a business

opportunity and sustain a market of considerable size, that of CDNs. Similarly, theseinefficiencies lead to opportunities for SmartenIT too!

This complex business landscape gives rise to interesting tussles among the stakeholders,which have been also analysed in D2.5 [8]. These tussles are greatly affected by both theexisting business relationships and practices among the operators and by the technicalInternet protocols deployed. Regarding the tussles among the operators in the OFS, theoptimal traffic destination when multiple candidate destinations exist comprises aninteresting tussle. The selection of the optimal destination would be then performed by thesending entity, CSP/DC or uNaDa, without any knowledge on the underlying network load,which may affect both the time within which the data transfer will be completed as well asthe underlying network load. Also the BGP aggregation function further mitigates thechoices for optimizing the traffic routing. The net neutrality tussle pertains to the scope ofreasonable traffic management. The information asymmetry, already explained earlier inthis section and the potential inter-domain traffic changes resulting from edge storagedevices and the support of video content dissemination may have significant impact on anISP’s inter-connection costs, peering ratios and thus on the sustainability of itsinterconnection agreements. Last but not least, the pricing tussle over traffic is also closelyrelated to the net neutrality tussle and partly resolved via competition, business modelsand regulation. However, the existing status quo in pricing, as well as the introduction ofnew schemes, may create interesting spill-over effects and new tussles, since more or lesscontrol and options is provided to some of the stakeholders in the Internet services value

chain: to this end, pricing is both the cause of tussles and a way to resolve them as acontrol mechanism, but also serve as the outcome of tussles and business modeling in theInternet.

Similar tussles also appear in the context of federations among clouds and datacenters.The degree of cooperation and information and control delegation among the federationmembers comprises an interesting tussle. This is largely due to the fact that the federationmembers, are also competing directly in the market for customers and also try to maximizetheir profits and customers obtained from the federation. This is closely related to theinformation asymmetry and quality discrimination tussles already explained in the previousparagraph for the operators’ case. The definition of the Federation policies, rules andinformation model is also a highly important tussle for the cloud service providers since

this determines customer ownership, intermediation, revenue flows and revenue sharingschemes, i.e., crucial aspects of the CSPs’ business.

Tussles also appear in the context of EFS, including the reduction of cloud provider traffictraversing ISPs and the traceability of user behavior, which are directly related to theintermediation of CDNs or alternative caching entities, such as uNaDas. These tussles, thecaching mechanisms that attempt to mitigate those, as well as performance issues arealso related to the pricing and inter-domain traffic changes, and to the respective impacton hardware and network upgrades needed.

All these tussles and their correlation with the business and technology status quo of theInternet indicate the highly disruptive impact of technology in the Internet ecosystem andthe resulting distribution of power among its stakeholders. The complexity of these tusslesalso indicates that a holistic approach, encompassing both the business and technology


20/177



aspects of Internet services delivery, is needed to mitigate them. This is well in line withthe SmartenIT approach and the mechanisms developed, which are specified so as torespect neutrality, fair competition and design-for-tussle principles. The respectivemechanisms, their scope and goal, as well as their relation with the business landscape

are presented in the next subsection.

3.2 Mechanisms’ landscape

This section provides an overview of the landscape of SmartenIT mechanisms and therespective cloud business models under which these can be utilized. Regarding theOperator Focused Scenario (OFS), the main mechanisms and their respectiveachievements are:

Dynamic Traffic Management (DTM), which minimizes the inter-domain trafficcost in multi-homed AS by influencing the distribution of the traffic among links.DTM is designed and implemented to work volume based tariffs and 95th percent

based tariffs. Inter-Cloud Communication (ICC), which attains a reduced 95th percentile transit

charge by controlling the rate of delay-tolerant traffic, marked a priori accordingly bythe ISP’s business customer (e.g. cloud/datacenter), and shifting its transmission atoff-peak intervals.

Multi-Resource Allocation (MRA), which ensures a fair resource allocation amongfederated Cloud Service Providers.

DTM++ employing features of DTM and ICC to further improve load balancing and95-th percentile inter-connection charge compared to the individual mechanisms.

All SmartenIT OFS mechanisms can be of high value to certain business contexts related

to the Internet and Cloud Services landscape. A high level overview can be found inChapter 5 of the D2.5 [8]. Next, we focus on ICC, DTM and their combination DTM++,since DTM++ has been fully implemented and constitutes one of the two major tangibleoutputs, i.e., the software products of the project, as well as MRA.

ICC, DTM and their superposition DTM++ constitute powerful tools for servicedifferentiation and OPEX reduction for Internet Service Providers, thus contributing both tocost reduction and value generation aspects of ISPs’ business. ICC, DTM and DTM++have consciously been designed for the Best Effort Internet so as to maximize the OFSmechanisms’ impact and applicability. However, the mechanisms’ design can also beadapted under a Differentiated Services model – by extending the number of traffic

classes and the respective differentiated treatment of the traffic – and/or under BeyondBest Effort Internet. Regarding the latter, DTM and DTM++ tunnels can utilize assuredquality inter-domain paths so as to further optimize the distribution of traffic on a per-service level by using separate tunnels per service and per destination and optimizing thecost distribution over them. ICC can comprise multiple classes of service with differentprioritization of the traffic taking into account the respective services requirements. In thiscase, statistical guarantees per service type can be assured.

MRA is an attractive solution for cloud federations. This is also the case for all the otherOFS mechanisms which, additionally to the aforementioned powerful features, comprisepowerful tools for providing customizable Network as a Service (NaaS) connectivity. Inparticular, this may apply over the entire ISP infrastructure or over network slices,potentially configured and managed according to the Software Defined Networking


21/177



paradigm. Therefore, service differentiation and customization at network layer can besupported for both legacy and cutting-edge IP network SDN technologies.

This is an additional means of the ISPs to differentiate themselves from being dump pipeproviders and is in line with the shift towards Value Added Services. Thus, the OFS

mechanisms can serve as means for the ISPs to extend beyond the low-margincommodity market for dump connectivity to the high-value customizable and differentiatedservices market. Furthermore, they can be bundled with additional services that ISPsalready provide, such as IPTV or any other Value Added Services targeted by TM Forumin [21], in order to materialize the Repeatable Digital Services Provisioning model.

Therefore, ICC, DTM and DTM++ can be beneficial for the declared TM Forum attempt toadapt the Amazon repeatable retail business model to cloud and Internet services basedon an Ecosystem Enablement Platform (EEP); details are provided in D2.4 [8]. This canbe accomplished by providing rich functionality to digital services where Over The Top(OTT) providers are extremely active either cooperating with or competing against ISPs.

The traffic management functionality of these mechanisms and also the cloud layerfunctionality of ICC - for optimal destination (i.e. cloud, data center) selection in inter-cloudcommunication cases where this is possible, such as bulk data transfers for datareplication - could comprise a core module of the EEP platform, offering a substantialcompetitive advantage for such Value Added Services provisioned on the applicationlayer. Note that this is also well aligned with the increasing importance of the network incloud services and its substantial impact on the users’ perceived quality. Thus the potentialfor monetizing the end user flows of the service via subscription or per use fees (e.g. forvideo on demand).

Therefore, ICC, DTM and DTM++ could serve as a means for the ISPs to capture portionsof the high-value market segments of private, hybrid and public cloud markets, including –through bundling with other services – Dynamic Business Processes and BusinessProcesses as a Service segments (refer to Figure 3-1 of Deliverable D2.4 [7]). Integratingthese OFS mechanisms over the ISP infrastructure could enable the ISP to acquire aportion of those highly profitable markets by increasing the competitive advantages of thebundled services. In particular, ICC and DTM could be used as stand-alone or combinedas DTM++ an advanced network management mechanisms efficiently meeting complexbusiness processes needs through smart quality of class differentiation and tunneling ofthe respective traffic. To this end, ISPs could bundle and provision such services under aManaged Services approach to their business customers or offer this advancedfunctionality under IaaS/PaaS to third party Over-The-Top providers such as Application

Service Providers.The Federation model (additional details are provided in subsection 3.4.2 of DeliverableD2.4 [7]) is also a business landscape where MRA, ICC, DTM and DTM++ are applicable,since these mechanisms’ design and deployment are facilitated by a federation of datacenters/clouds. The roll out of all the OFS mechanisms in this context would greatlycontribute to reducing the OPEX of both the cloud federation members and their host ISPsdue to the respective transit cost reduction.

As also stated previously, the ISP Managed Services model is also a suitable businesscontext for ICC, DTM and DTM++. The respective functionality could be an integral part ofthis paradigm as a whole and also for particular managed services such as Virtual Private

Cloud (VPC) and Managed Storage and Backup (additional details are provided in section3.4 of Deliverable D2.4 [7]).


22/177



Furthermore, the brokering business context is another one where MRA, ICC, DTM andDTM++ could be of value (additional details in Section 3.2 of Deliverable D2.4 [7]). Brokersmust be extremely efficient in meeting the needs for aggregation, integration andcustomization of services and resources and delivering to their customers a unified service

that meets the customized needs of the specific customer.Last but not least, DTM can also apply in the emerging 5G and Internet of Things (IoT)contexts, where virtualization will lead to the conception and deployment of network sliceand resource/traffic aggregates. The DTM can offer virtual routers serving as points ofpresence for data centers. They can be deployed in separate slices belonging to differentvirtual operators so as to provision 5G or IoT services. Since multi-provider servicedelivery, including cloud and IoT resources, over software-defined networks is part of the5G vision, DTM++ constitutes a candidate for this market as well.

Regarding the End user Focused Scenario (EFS), the main mechanisms and theirrespective achievements are:

Replicating Balanced Tracker and Home Router Sharing based on Trust (RB-HORST), which provides WiFi access to trusted users to offload their mobile trafficfrom 3/4G to WiFi. RB-HORST also enables home routers of trusted users identifiedthrough a social network to be organized in a content-centric overlay networksupporting content prefetching and caching.

Socially-aware Efficient Content Delivery (SEConD), which employs socialinformation, AS-locality awareness, chunk-based P2P content delivery andprefetching. A centralized node is acting as cache and as P2P tracker with a proxyto improve the Quality of Experience of video streaming for users of OSNs toreduce inter-AS traffic.

Virtual Incentives (vINCENT), which aims to leverage unused wireless resourcesamong users, while it ensures security by employing tunneling among trusted users.vINCENT exploits social relationships derived by the OSN, as well as interestsimilarities and locality of exchange of OSN content.

Mobile Network Assistant (MONA), which schedules wireless data transmissionsto reduce the energy expenses on the air-interfaces exploiting changes of themobile network performance depending on location and time patterns.

Multi-Criteria Application Endpoint Selection (MUCAPS), which improves users’Quality of Experience by performing selection of communication endpoints with anawareness on the underlying network topology provided by ALTO protocolextensions and the end-user access.

All the SmartenIT EFS mechanisms are suitable for certain business contexts. Next, weprimarily focus on the RB-HORST mechanism, which is the superposition of various EFSmechanisms and one of the software products of the project and discuss its fitness to thebusiness landscape.

The business context that is most relevant is the Terminal and Service business model. Inparticular, the “terminal+service” trends and respective business models also indicate anincreasing interest on innovation at the end user devices side. Thus, the SmartenIT EFSmechanisms, namely RB-HORST, SEConD, vINCENT, MONA and MUCAPS that candeliver energy efficiency, advanced services and resource management, increased agilityand performance, can be very useful means for new differentiated services and terminal

operations. A prominent example is the cloudlets business case: cloudlets aredecentralized and widely-dispersed Internet infrastructures whose compute cycles and


23/177



storage resources can be leveraged by nearby mobile computers, i.e. a “data center in abox”. The aforementioned SmartenIT EFS mechanisms are well positioned within thisemerging business context.

This is also evident in the latest developments regarding Windows 10. In particular, mobile

terminals running Windows 10 let its users exchange Wi-Fi network access with theirFacebook friends, Outlook.com contacts, or Skype contacts to give and get Internetaccess without seeing each other's Wi-Fi network passwords [22].

Furthermore, 5G is an emerging business landscape were EFS mechanisms are ofprominent importance. The large emphasis on Quality of Experience (QoE), energyefficiency and ubiquitous connectivity, as opposed to mobility, render RB-HORSTfunctionality well placed in this context, since its logic could be utilized for the efficientcoordination of horizontal and vertical “hand-offs” in an opaque to the user manner.

The novel features that RB-HORST brings to the end user devices and the respectiveservices can be of high value over specific services whose monetization is greatly affected

by QoE: the video streaming services delivery comprises a primary market segmentwhose size and dynamics justify the investment on RB-HORST and similar solutions. Inthis context, MUCAPS is also applicable since it could be used for smart end-pointselection for the content or service delivery points: this is of high value in the video market,as well as in that of CDNs. Furthermore, the MUCAPS functionality could also be extendedso as to perform smart content delivery in the context of 5G networks and mobile edgecomputing: User devices would use the MUCAPS service so as to associate end usersflows to the less costly interface and service/content delivery point available.

RB-HORST's mechanisms for caching, prefetching, and offloading are especiallyinteresting for businesses that lack their own 3G/4G network with a wide Internet

coverage. Such a business, e.g., ISP, that has set-top boxes or routers at the premises ofits customers, can quickly gain a high WLAN coverage and compete with 3G/LTEproviders with respect to data transmission. Furthermore, making the set-top box or routermore intelligent that would allow users to install various router apps could boost softwaredevelopment on those devices when providing an open API such as with Android or iOS.

With MUCAPS, end-users get a better QoE due to the ISP-assisted application trafficoptimization. ISP can optimize routing costs and resources usage by means of either adirect usage of MUCAPS or applications and end-users accepting to use the MUCAPSoption. As a result CSPs get an increased satisfaction rating from their customers. If CSPsbuy services from CDNs, the CDNs will easily keep them as customers. Besides, ISPssave inter-domain traffic costs due to content delivery from sources hosted locally or in apeering network. ISPs may buy MUCAPS from a vendor to optimize their routing costs andresources usage by optimizing application traffic. ISPs may also buy an ALTO Server ifthey don’t have one. As MUCAPS is transparent to them, ISP customers (CSPs, CDNs)and end users do not need to buy or employ some additional service, but may benefit ofimproved resources allocation offered by the ISP thanks to MUCAPS. Besides, end usersmay also agree to have their connection type unveiled to the ISP.


24/177



3.3 System architecture

As already mentioned, SmartenIT envisions two approaches for the efficient managementof Internet traffic. These are:

a) the Operator Focused approach, which manages of traffic between Cloud-basedservices, large content providers, or data centers , typically residing in Tier-2domains and involving traffic crossing Tier-1 domains as well,

b) the End-user Focused approach, which manages traffic destined to end users (inTier 3 domains) from Cloud-based infrastructure with multiple Points of Presence(PoPs), i.e. caches, mirrors, surrogates, CDNs.

In deliverable D3.3 – “Final Report on System Architecture” [11], the final systemarchitecture was presented and documented in details. The entities which constitute theSmartenIT architecture are the SBox (implementing the SmartenIT logic), the SDNController , the Network Entity (i.e., the router), the uNaDa (i.e., an enhanced home

gateway) and the End User Entity (i.e., smartphone, laptop). The first three entities referto the Operator Focused approach while the last two refer to the End-user Focusedapproach. Figure 1 provides a visual representation of the aforementioned entities andtheir envisioned deployment.

Figure 1: The SmartenIT ecosystem and the involved architectural entities.

The SmartenIT architecture has been designed in such a way to be able to host any of theinitially described mechanisms. However, as certain mechanisms became more maturethan others, two of them were selected for implementation. This fact however does notlimit the applicability of the SmartenIT architecture for the rest of the envisionedmechanisms. In the following paragraphs, the architectural diagrams of these twomechanisms, namely the DTM and RB-HORST ones, are described.


25/177



(a)

SDN Controller (Server)SBox (Server)

sbox.jar

sqlite sdn.jar HTTP(JSON)

Jetty Container

DB

Economic Analyzer

Network Device

Inter-SBoxCommunicationService

QoS Analyzer

Traffic Manager

OpenFlow

sbox.war jdbc

SNMP

NETCONF

HTTP

TCP

Floodlight0.90

(b)

Figure 2: The DTM architecture (a) and deployment (b) diagrams

Figure 2(a) presents the SmartenIT architecture instantiated for the DTM mechanism. Thevarious components have been grouped in the respective entities and the interfaces

between components and entities have been identified. The color-coding of thecomponents defines whether a component was implemented by SmartenIT (blue) or athird-party implementation was used (white). Figure 2(b) shows which specifictechnologies and containers where used to deploy the implemented components.

(a) (b)

Figure 3: The RB-HORST architecture (a) and deployment (b) diagrams

Figure 3(a) presents the SmartenIT architecture instantiated for the RB-HORSTmechanism. The various components have been grouped in the respective entities and theinterfaces between components and entities have been identified. The same color-coding

rule applies here as well. Figure 3(b) shows which specific technologies and containerswhere used to deploy the implemented components. For more details on the genericSmartenIT architecture and its specific instantiations for the DTM and RB-HORSTmechanisms, please refer to D3.3 [11].

Figure 4 presents the mapping between the SmartenIT architecture and MUCAPS.MUCAPS was not part of the project team implementations as its purpose is to add ISP-defined awareness on the transport network topology and costs to existing mechanisms.MUCAPS was developed as a standalone add-on that can be easily patched on theSmartenIT architecture. The MUCAPS components are pictured in yellow.


26/177



Figure 4: SmartenIT Entities and components involved in MUCAPS

3.3.1 Implementation process

In the first year of work, the SmartenIT partners had chosen mechanisms which were to beimplemented in following years. The main candidates for implementation were RB-HORSTand DTM. Implementation process has been preceded by system design. From thatmoment the project team responsible for implementation started working on systemarchitecture. In the first stage of design the core functionalities were identified. The systemcomponents, internal and external interfaces were defined for each selected mechanism.The authors of other mechanisms added necessary elements required for futureextensions, specific for particular mechanism. Each mechanism was specified on twolevels: mechanism description level (WP2 perspective) and implementation level (WP3perspective). The architecture was frozen and implementation started. The implementationwent smoothly. During project new functionalities were added to the system and they were

presented in the form of a few releases. The key SmartenIT system releases werepublished on github.

The last release contains functionalities related to a few mechanisms (RB-HORST, DTMand ICC). Generally SmartenIT work on software followed agile programming paradigm.The whole process of producing consecutive releases of SmartenIT system evolved during3 years.

The work on last releases proved that the cooperation between partners got mature level:two levels of specification took a form of single containing WP2 and WP3 perspective, thecommunication between partners responsible for selected components were improved, theappropriate form of specification were worked out which accelerated programming

process. The interface between components were properly defined enabling


27/177



implementation of new features. The last releases also proved that architecture were welldesigned, it was enough flexible to incorporate more management mechanisms.

3.4 Business perspective and applicabili ty to main IP traffic categories

The business aspects of traffic management mechanisms depend on the goals andincentives of all involved parties in service provisioning over the Internet, which differ fromthe perspective of popular Internet platforms and from the users' perspective as well as forcontent delivery networks and network providers (ISPs) on the transport path.

Four main categories can be distinguished of Internet traffic to be optimized by differenttraffic management mechanisms in SmartenIT:

traffic distributed via over-the-top (OTT) content platforms being supported by a largeglobal CDN, i.e. CDN-to-user traffic,

traffic via smaller web platforms without support by large global CDNs, i.e.

cloud/server-to-user traffic, user-to-user traffic, e.g. conversational voice or video, P2P file sharing etc., transit traffic between data centers (DC-to-DC traffic).

The impact of each category on the Internet traffic mix is varying and developing over time.In a phase from 2001 - 2005, user-to-user traffic was dominant based on high volume filesharing applications [25] (since 2004 P2P traffic is declining). Since then, client-serverbased traffic is increasing mainly on video and IP-TV platforms, e.g., YouTube or Netflixtogether with other cloud servers of different size, which generate CDN/server/cloud-to-user type traffic. A major portion of this traffic is distributed over only a few CDNs (Google,

Akamai etc.) with a dense global footprint, but traffic from smaller clouds and fromspontaneously popular web sites without global CDN support is also summing up to aconsiderable fraction of IP traffic. The volume of file sharing traffic in Europe is constant orslightly decreasing according to Cisco [24] and its share decreased below 10% of the totaldownstream traffic in recent Internet traffic reports by Sandvine [30] because other traffictypes are growing much faster (for detailed graphs and figure, refer to D2.1 [4]). Thecurrent composition of those traffic types has significant influence on the options for trafficengineering and control mechanisms. In the following discussion of appropriatemanagement measures for each traffic type, a reduction of the traffic load always meanslower cost and energy consumption because upgrades of capacity may be delayed orresources may be switched off due to better resource usage. Over the last decade, energy

consumption increased to a major component of operational network costs (OPEX)especially in high speed core networks and in the radio access of wireless/mobilenetworks. Energy consumption is becoming a limiting factor of bandwidth growth in futureIP networks. Therefore studies on energy saving options as provided e.g. by the MONAmechanism in Section 4.2.4 or ICC mechanism in Section 4.2.1 are an important focus ofSmartenIT.

For OTT cloud services and web sites with support by a global CDN, i.e. CDN-to-usertraffic, the CDN often has control over most of the transport path from the original site ofthe web server to caching and content distribution servers, which are available at mainInternet exchange points (IPX) [38] around the world and have peering connections with

most ISPs. Based on a large server infrastructure in the Internet, CDNs with globalfootprint can apply load balancing under control of their own servers, regarding the load in


28/177



the distributed server architecture, the connection network load between the distributionservers and the sites providing the original content. For this purpose, the dynamic trafficmanagement (DTM) mechanism as described in Section 4.2.1 can be applied. Moreover,global CDNs also maintain and optimize the connections from their servers to the user

including fast switching procedures to another server offering better performance, whenQoS degradation in terms of low bandwidth or long delays is observed by QoS monitoring[31].

Moreover, CDN-to-user traffic is also supported by caching within the platform of theCDN provider. On the other hand, caching options beyond the CDN are often prohibitedbecause they only partly conform to the business interests of global CDNs. Additionalcaching in user controlled nano data centers (uNaDas) as proposed by the RB-HORSTapproach in sections 0 - 4.2.3 or in home gateways under control of an ISP can furtherimprove throughput and delays of services. This may be less relevant for small ISPnetworks whose peering with global CDN servers is already close to the users. For largeISPs, which still have a number of hops between a peering CDN server and their usersand for mobile and wireless network providers, where the access link via air interface isthe bottleneck, caching in global CDN servers is often far from an optimum transportsolution. Nonetheless, global CDNs usually have a higher business interest in keepingcomplete control over the connections to the users in order to get full information aboutuser activity, because usage statistics are essential for the revenues of content andservice providers.

Therefore cooperative approaches between large CDN providers and ISPs seem to be theonly viable way. In fact, such approaches have already been developed. For example,SmartenIT partners TDG and TUD have studied an approach, where the CDN providermaintains full control on application layer. At the same time, the network provider can

optimize the network layer independently, with an SDN controller interface for exchange ofinformation about requests from users and corresponding selection of an appropriateserver and QoS support within the ISP network. Moreover, the MUCAPS mechanism anddevelopments proposed by BENOCS [43] investigate similar cooperative trafficmanagement approaches.

The situation is different for the second type of cloud/server-to-user traffic withoutsupport by a global CDN, which allows for transparent caching in uNaDas as part of theRB-HORST mechanism and/or home gateways of an ISP or similar caching facilities inlocal networks. Small clouds and other web services without background CDN would facea considerable performance handicap as compared to OTT services and therefore can

benefit a lot in terms of improved throughput and shortened delays from transparentcaches in ISP networks and user premises. ISPs have a benefit from a transparentcaching architecture that reduces load on expensive interconnection and peering links andimproves throughput for his subscribers. The RB-HORST caching approach still canexploit some incentive for the users who get improved performance, but naturally it is morechallenging to set up an efficient cooperative service with limited shared storageresources.

In principle, DTM is also applicable to inter-domain traffic of the cloud/server-to-user typebetween clouds and ISP domains. However, on both sides many connections have to bemaintained with different small to medium size clouds or ISP domains, respectively,whereas DTM assumes established links between one cloud provider and an ISP. Theoptions for monitoring and for influencing the traffic flows also have to be adapted to sucha scenario.


29/177



The user-to-user traffic type is also appropriate for caching options, if a small set ofpopular web objects are requested by a large user population as a general precondition forcaching efficiency. Moreover, approaches based on application layer traffic optimization asdiscussed in the ALTO working group at the IETF are relevant [27]. Such approaches are

included in the MUCAPS mechanism in section 4.2.5 as an advanced ALTOimplementation. The basic concept of an ALTO server that provides network layerinformation, especially distance metrics between users, in order to optimize transportefficiency and costs, is also considered as part of the DTM concept and of the overallSmartenIT architecture. However, the concept relies on ISPs to deploy and operate ALTOservers, although their incentive is not entirely clear. Indeed, enabling higher throughputfor e.g. file sharing data may end up in even higher P2P traffic demand rather thanreduced network load [25]. On the other hand, an ALTO server has to adapt torequirements of different applications and it is not sure whether an application is willing totrust the servers' recommendations based on unknown ISP preferences, which may leadto unexpected and hardly controllable side effects. However, the most relevant data for the

ALTO service is information about the autonomous system to which a user belongs, whichis available in public data about the IP address ranges of ISPs and other organizationswithout the need to rely on special ISP involvement. A more detailed picture about regionaluser locations often does not help because even a transport path between users in thesame region usually has to pass through a core PoP and transport in the core of an ISPhas lowest per Mb/s costs on high speed backbone links.

Last not least, traffic between data centers (DC-to-DC) amounts to a considerable portionof about one third of the Internet traffic according to reports by Cisco Systems [24]. Most ofthis traffic is again flowing between data centers of the largest global CDN providers. Inother cases, when data centers in different domains are connected, DTM can be applied if

several paths are prepared for the data center exchange. The characteristics of inter datacenter traffic is expected to be much more variable than for CDN/cloud-to-user traffic,because there is no comparable statistical multiplexing gain as is exploitable fordistributing data over a large user population.

DC-to-DC traffic should be deferred to low traffic load periods, e.g., overnight rather thanin busy hours wherever possible such as in the ICC mechanism in Section 4.2.1. The dailyDC-to-user traffic profiles usually follow a sinus-like curve with a peak in the evening hoursand less than half of the traffic rate in early morning hours, as shown in traffic statistics e.g.of the world's currently largest Internet exchange point (DE-CIX) [32]. Then prefetching ofcontent at night time that is expected to become popular at the next day can reduce thedaily peak rate. In general, the caching strategy can be modified e.g. from least recently

used (LRU) with a steady cache input flow to a strategy that defers any cache updatetowards off-peak periods.

User demands are the original source of traffic of any type. In principle, the users decidewhich applications and traffic types they generate. However, the mass of Internet usersprefers low rates for Internet access and IP services for free or again at low prices. As aconsequence, OTT business models are partly based on advertisement or on smallmonthly fees and access network providers mainly offer best effort services, whereasspecial QoS support is reserved for a small traffic portion devoted to business customers.Nonetheless, the users can expect a basic quality level, which is more and more denselycontrolled by the European regulators in recent quality initiatives based on a development

towards large scale performance measurements in the IETF LMAP standardization (cf.[23], [29]). Finally, the relationships between users in social networks have been studied in


30/177



the RB-HORST mechanism in order to predict data requests for improving cachingstrategies to hold the most popular data close to the u

Date post:	05-Jul-2018
Category:	Documents
Upload:	smartenit
View:	219 times
Download:	0 times

Deliverable D4.3 - Prototype Evaluations and Overall Project Assessment

Documents