Deliverable D2.2 Report on Definitions of Traffic Management Mechanisms and Initial Evaluation Results

8/14/2019 Deliverable D2.2 Report on Definitions of Traffic Management Mechanisms and Initial Evaluation Results

1/174

Seventh Framework STREP No. 317846 D2.2 Definitions of Traffic Management MechanismsPublic

Version 1.3 Page 1 of 174 Copyright 2013, the Members of the SmartenIT Consortium

Socially-aware Management ofNew Overlay Application Traffic with

Energy Efficiency in the InternetEuropean Seventh Framework Project FP7-2012-ICT-317846-STEP

Deliverable D2.2

Report on Definitions of Traffic Management

Mechanisms and Initial Evaluation Results

The SmartenIT Consortium

Universitt Zrich, UZH, SwitzerlandAthens University of Economics and Business - Research Center, AUEB, GreeceJulius-Maximilians Universitt Wrzburg, UniWue, GermanyTechnische Universitt Darmstadt, TUD, GermanyAkademia Gorniczo-Hutnicza im. Stanislawa Staszica w Krakowie, AGH, PolandIntracom SA Telecom Solutions, ICOM, GreeceAlcatel Lucent Bell Labs, ALBLF, FranceInstytut Chemii Bioorganicznej PAN, PSNC, PolandInteroute 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 StillerUniversitt Zrich, CSG@IFIBinzmhlestrasse 14CH8050 ZrichSwitzerland

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


2/174

D2.2 Definitions of Traffic Management Mechanisms Seventh Framework STREP No. 317846Public

Page 2 of 174 Version 1.3 Copyright 2013, the Members of the SmartenIT Consortium

Document Control

Title: Report on Definitions of Traffic Management Mechanisms and InitialEvaluation Results

Type: PublicEditor(s): Valentin Burger

E-mail: [email protected]

Author(s): Thomas Bocek, Valentin Burger, Paolo Cruschelli, George Darzanos, ManosDramitinos, Zbigniew Dulinski, Jakub Gutkowski, Gerhard Halinger, DavidHausheer,Tobias Hofeld, Fabian Kaup, Sylvaine Kerboeuf, Roman Lapacz,Andri Lareida, Lukasz Lopatowski, Sergios Soursos, Guilherme SperbMachado, Ioanna Papafili, Patrick Poullie, Sabine Randriamasy, George D.Stamoulis, Rafal Stankiewicz, Michael Seufert, Corinna Schmitt, MatthiasWichtlhuber, Mateusz Wielgosz, Krzysztof Wajda, Piotr Wydrych

Doc ID: D2.2-v1.3

AMENDMENT HISTORY

Version Date Author Description/Comments

V0.1 November 1, 2012 Burkhard Stiller First version

V0.2 May 7, 2013 Valentin Burger, Michael Seufert,Tobias Hofeld

Draft for TOC

V0.3 May 31, 2013 Valentin Burger, Ioanna Papafili,Matthias Wichtlhuber

Addressed comments on TOC, included vINCENT

V0.4 June 7, 2013 Valentin Burger Responsibilities, List of TMSV0.5 June 17, 2013 Valentin, Paolo, Michael, Ioanna,

Patrick, PiotrIncluded Traffic Management Solutions with Bullet Points, Tables thatgive Overview of TM solutions and TM mechansims

V0.6 July 8, 2013 Corinna, Roman, Ioanna, George D.,George S., Manos

Included more Traffic Management Solutions

V0.7 July 22, 2013 Ioanna, Roman Included MPLS Solution, Sections for models,

V0.8 August2, 2013 Sabine, Sylvaine, Ioanna, Patrick,Andri, Matthias, Michael, Piotr, Valentin

Included sections 4.13 and 4.14, Provided Chapter 3 and Solutions inChapter 4 in text-form.

V0.9 September 9, 2013 Lukasz, Patrick, Ioanna, Paolo,Mateusz, Corinna, Thomas, Fabian,Andri

Completed missing solutions in chapter 4, Chapter 5 added, Gametheoretic model and energy models added

V1.0 October 7, 2013 Sergios, Krzysztof, Rafal, Lukasz,Valentin, Partick, Thomas, Guillherme,Andri, Ioanna, Michael, Fabian,

Matthias, David, Piotr, Gerhard, Sabine

Executive Summary added, Document format .docx, Sections inchapter 4 were revised, Section 5 added, Added Mappings toSmartenIT architecture, Two additional traffic management solutions

added, Revision of section 3, Introduction added, Conclusion added,References formatted

V1.1 October 21, 2013 Burkhard, Sprios, George, Chris,Valentin

Document reviewed and commented, Reviews merged

V.1.2 October 29, 2013 Valentin, all contributors Addressed reviewer comments, revised contributions, mergedrevisions, final formatting

V.1.3 October 31, 2013 George, Sergios, Chris, Fabian,Valentin

Addressed comments, revision of summary, finalization

Legal NoticesThe 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 thismaterial.


3/174



Table of Contents

1 Executive Summary ............................................................................................................ 12

2 Introduction ....................................................................................................................... 14

2.1 Purpose of this Document ..................................................................................................... 15

2.2 Document Outline ................................................................................................................. 16

3 Definition of Relevant Applications and Related Models..................................................... 1

3.1 Selection of Relevant Applications for SmartenIT ................................................................. 1

3.2 !o"els for A""resse" Applications ...................................................................................... 1#

3.2.1 Simulation Models ......................................................................................................... 18

3.2.2 Theoretical Models ........................................................................................................ 29

4 SmartenI! !raffic Mana"ement Solutions ........................................................................... 42

$.1 %ome Router Sharin& 'ase" on Trust ................................................................................... $2

4.1.1 Addressed Scenarios ...................................................................................................... 43

4.1.2 Definition of SmartenIT Traffic Management Mechanisms .......................................... 44

4.1.3 Identification of Ke Influence !actors .......................................................................... 4"

4.1.4 Ke #erformance Metrics ............................................................................................... 4"

4.1.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... 4"

4.1." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... 4+

4.1.+ %,am)le Instantiation of Mechanism ............................................................................ 4+

$.2 Sociall()a*are T! for +fficient ,ontent Deliver( ................................................................. $#


4.2.2 Definition of SmartenIT Traffic Management Mechanism ............................................ $-

4.2.3 Identification of Ke Influence !actors .......................................................................... $1

4.2.4 Ke #erformance Metrics ............................................................................................... $2

4.2.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... $2

4.2." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... $$

4.2.+ %,am)le Instantiation of Mechanism ............................................................................ $$

$.3 !echanism for Inter),lou" ,ommunication ........................................................................ 55

4.3.1 Addressed Scenarios ...................................................................................................... $"

4.3.2 Definition of SmartenIT Traffic Management Mechanisms .......................................... $+

4.3.3 Identification of Ke Influence !actors .......................................................................... "-

4.3.4 Ke #erformance Metrics ............................................................................................... "1

4.3.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... "1

4.3." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... "2

4.3.+ %,am)le Instantiation of Mechanism ............................................................................ "2

$.$ D(namic Traffic !ana&ement .............................................................................................. 63

4.4.1 Addressed Scenarios ...................................................................................................... "44.4.2 Definition of SmartenIT Traffic Management Mechanisms .......................................... ""


4/174



4.4.3 Identification of Ke Influence !actors .......................................................................... "8

4.4.4 Ke #erformance Metrics ............................................................................................... "8

4.4.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... "8

4.4." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... "9

4.4.+ %,am)le Instantiation of Mechanism ............................................................................ "9

$.5 R-)Tracer/ 0ser Traffic !ana&ement .................................................................................

4.$.1 Addressed Scenarios ...................................................................................................... +-

4.$.2 Definition of SmartenIT Traffic Management Mechanisms .......................................... +1

4.$.3 Identification of Ke Influence !actors .......................................................................... +1

4.$.4 Ke #erformance Metrics ............................................................................................... +1

4.$.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... +2

4.$." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... +2

4.$.+ %,am)le Instantiation of Mechanism ............................................................................ +3

$.6 Selection !echanism for Stora&e Provi"ers ......................................................................... $

4.".1 Addressed Scenarios ...................................................................................................... +4

4.".2 Definition of SmartenIT Traffic Management Mechanisms .......................................... +4

4.".3 Identification of Ke Influence !actors .......................................................................... ++

4.".4 Ke #erformance Metrics ............................................................................................... +8

4.".$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... +8

4."." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... +8

4.".+ %,am)le Instantiation of Mechanism ............................................................................ +8

$. Static Resource Allocation in the IaaS e"eration ................................................................

4.+.1 Addressed Scenarios ...................................................................................................... 8-

4.+.2 Definition of SmartenIT Traffic Management Mechanisms .......................................... 8-

4.+.3 Identification of Ke Influence !actors .......................................................................... 8-

4.+.4 Ke #erformance Metrics ............................................................................................... 81

4.+.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... 81

4.+." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... 81

4.+.+ %,am)le Instantiation of Mechanism ............................................................................ 82

$.# Optimi4e" 0p&ra"e an" Plannin& Processes in oa" -alancin& et*ors .......................... #3

4.8.1 Addressed Scenarios ...................................................................................................... 8$

4.8.2 Definition of SmartenIT Traffic Management Mechanisms .......................................... 8"

4.8.3 Identification of Ke Influence !actors .......................................................................... 8"4.8.4 Ke #erformance Metrics ............................................................................................... 8+

4.8.$ Initial %&aluation for Ste)ise /)grades in !ull Mesh 0ore etors ......................... 8+

4.8." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... 89

4.8.+ %,am)le Instantiation of Mechanism ............................................................................ 9-

$. vI,+T ................................................................................................................................


4.9.2 Definition of SmartenIT Traffic Management Mechanisms .......................................... 91

4.9.3 Identification of Ke Influence !actors .......................................................................... 92

4.9.4 Ke #erformance Metrics ............................................................................................... 934.9.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................... 93


5/174



4.9." Ma))ing of Mechanism to SmartenIT Architecture ...................................................... 9$

4.9.+ %,am)le Instantiation of Mechanism ............................................................................ 9$

$.1 ATO)"riven Application 7ualit( A&&re&ation S(stem ...................................................... 5

4.1-.1 Addressed Scenarios ................................................................................................... 9"

4.1-.2 Definition of SmartenIT Traffic Management Mechanisms ....................................... 9"4.1-.3 Identification of Ke Influence !actors ....................................................................... 98

4.1-.4 Ke #erformance Metrics ........................................................................................... 99

4.1-.$ Initial %&aluation 'esults and ()timi*ation #otential ................................................ 99

4.1-." Ma))ing of AAS to SmartenIT Architecture ............................................................ 99

4.1-.+ %,am)le Instantiation of AAS ................................................................................... 99

$.11 !ulti),riteria Application +n")Point Selection ................................................................ 1

4.11.1 Addressed Scenarios ................................................................................................. 1-1

4.11.2 Definition of SmartenIT Traffic Management Mechanisms ..................................... 1-1

4.11.3 Identification of Ke Influence !actors ..................................................................... 1-44.11.4 Ke #erformance Metrics ......................................................................................... 1-4

4.11.$ Initial %&aluation 'esults and ()timi*ation #otential .............................................. 1-"

4.11." Ma))ing of Mechanism to SmartenIT Architecture ................................................. 1-$

4.11.+ %,am)le Instantiation of Mechanism ....................................................................... 1-$

$.12 7o+ an" +ner&( A*are !o'ile Traffic !ana&ement ..................................................... 16

4.12.1 Addressed Scenarios ................................................................................................. 1-"

4.12.2 Definition of SmartenIT Traffic Management Mechanisms ..................................... 1-+

4.12.3 Identification of Ke Influence !actors ..................................................................... 1-9

4.12.4 Ke #erformance Metrics ......................................................................................... 11-

4.12.$ Initial %&aluation 'esults and ()timi*ation #otential .............................................. 11-

4.12." Ma))ing of Mechanism to SmartenIT Architecture ................................................. 11-

4.12.+ %,am)le Instantiation of Mechanism ....................................................................... 111

# $onfi"uration and $ommunication %rame&or's ............................................................... 112

5.1 Inter)ATO ,ommunication rame*or ............................................................................. 112

$.1.1 S)ecification of the !rameor ................................................................................... 11$

$.1.2 A))lication to Traffic Management Solutions ............................................................. 11"

$.1.3 %&aluation %n&ironment and Initial 'esults ................................................................. 11+

5.2 Openlo*)'ase" et*or ,onfi&uration rame*or ........................................................ 11

$.2.1 S)ecification of the !rameor ................................................................................... 119

$.2.2 A))lication to Traffic Management Solutions ............................................................. 121

$.2.3 %&aluation %n&ironment and Initial 'esults ................................................................. 122

5.3 !PS)'ase" et*or ,onfi&uration rame*or ............................................................... 123

$.3.1 S)ecification of the !rameor ................................................................................... 123

$.3.2 A))lication to Traffic Management Solutions ............................................................. 124

$.3.3 %&aluation %n&ironment and Initial 'esults ................................................................. 124

( Syner"ies )et&een Mec*anisms ....................................................................................... 12(


6/174



6.1 A"herence to the Scenarios ................................................................................................ 126

6.2 Properties of !echanisms .................................................................................................. 13

6.3 O'servation an" Decision !etrics ...................................................................................... 136

6.$ Discussion of S(ner&ies 'et*een !echanisms ................................................................... 1$1

Summary and $onclusions ............................................................................................... 142

.1 8e( Outcomes an" essons earnt ...................................................................................... 1$2

.2 e9t Steps ........................................................................................................................... 1$$

+ Smart ,)-ectives .............................................................................................................. 14#

References ....................................................................................................................... 14

1/ A))reviations ............................................................................................................... 1#4

11 Ac'no&led"ements ...................................................................................................... 1#(

12 Appendices ................................................................................................................... 1#

12.1 Openlo* Test ,onfi&uration Details .............................................................................. 15

12.2 !PS Test ,onfi&uration Details ..................................................................................... 16

12.3 !appin& of !echanism to SmartenIT Architecture ........................................................ 16#


7/174



List of Figures

Figure 1: Interaction of users on Facebook during a day [90]. ............................................. 19

Figure 2: Buffered playtime while streaming a YouTube video. ........................................... 23

Figure 3: Finite state machine for a video streaming source traffic model. .......................... 24Figure 4: Cumulative distribution of measured YouTube video bit-rates and video sizes. ... 24

Figure 5: Cumulative distribution of measured block sizes. ................................................. 25

Figure 6: Cumulative distribution of pre-buffered playtime. .................................................. 25

Figure 7: Video buffer while streaming a video with limited network data rate [58]. ............. 26

Figure 8: Most important use cases for Dropbox [1]. ........................................................... 28

Figure 9: MOS as function of waiting times for four difference task scenarios: initialization,storage, retrieval, and multidevice sync. Figures are taken from [1]. ........................ 30

Figure 10: Mapping functions of stalling parameters to MOS. Video duration is fixed at 30s. No initial delay is introduced. Parameters are givenin Table 7 ............................. 32

Figure 11: Simple QoE model maps a number N of stalling events of average length L to aMOS value,, = 3.50 0.15 + 0.19 + 1.50. [58] ........................................... 33

Figure 12: N = 4000 traffic traces and the estimated 95-th percentile. ................................. 35

Figure 13: Difference of the 95-th percentile minus actual traffic traces. ............................. 35

Figure 14: Throughput under a specific transit charge, with and without the schedulingmechanism operating ideally and with perfect information. ....................................... 36

Figure 15: Basic HORST functionality.................................................................................. 43Figure 16: Potential of caching on the end-user device for response-time and energy

consumption .............................................................................................................. 47

Figure 17: Video hosted on Facebook video server. ............................................................ 49

Figure 18: Video hosted on YouTube video server. ............................................................. 49

Figure 19: Prefetching accuracy vs. number of watched videos. ......................................... 53

Figure 20: Prefetching accuracy vs. number of pre-fetched videos. .................................... 53

Figure 21: Inter-AS traffic generated due to prefetching. ..................................................... 53

Figure 22: Total inter-AS traffic generated. .......................................................................... 54Figure 23: Total inter-AS traffic during one simulation day. ................................................. 54

Figure 24: Cloud federation. ................................................................................................ 57

Figure 25: Instantiation of the ICC mechanism in the case of a cloud federation. ............... 63

Figure 26: Sample network model for the use-cases description ......................................... 65

Figure 27: Cost functions used for accounting cost of inter-domain traffic ........................... 66

Figure 28: A cost map as a function of traffic volume on both inter-domain links and costoptimization potential ................................................................................................ 67

Figure 29: Illustration of a traffic compensation mechanism ................................................ 68


8/174



Figure 30: Comparison of traffic growth on links during the accounting period with (greencurve) and without (red) DTM ................................................................................... 69

Figure 31: Traffic pattern in link 2 with and without DTM mechanism .................................. 70

Figure 32: Initial experiments show no traffic peak reduction in a random preference

scenario.[11] ............................................................................................................. 72Figure 33: Deployment example of RB-Tracker. .................................................................. 73

Figure 34: Optimized load balancing often includes NP-complete problems, e.g., Bin-Packing [47]. ............................................................................................................. 86

Figure 35: Options for algorithms and graphical views provided by the TE-Scout tool ........ 87

Figure 36: Cost and energy optimization by stepwise upgrades in an 8-node full mesh ...... 88

Figure 37: Timing and Cost Decrease for Stepwise Upgrades ............................................ 89

Figure 38: vINCENT Infrastructure ................................................................................... 91

Figure 39: Virtual Node concept of vINCENT ...................................................................... 92Figure 40: Measurement of existing P2P streaming system. ............................................... 94

Figure 41: Energy Efficiency of end-devices. ....................................................................... 94

Figure 42: Application quality aggregation system for an ALTO guided population of ALTOEndpoint QoE Cost values. ....................................................................................... 97

Figure 43: example deployment of MUCAPS: Multi-Cost ALTO Client block integrated inan ISP DNS resolver and coupled with (i) an automated Application Metric Mappingfunction (ii) an automated metric weight tuning function. ........................................ 103

Figure 44: Prototype and example scenario for MUCAPS-based AEP selection. .............. 104

Figure 45: video streaming application with 3 candidate AEPs and 2 metrics. .................. 105

Figure 46 Architecture of the Network Optimizer from [67] ................................................ 108

Figure 47: Inter-ALTO communication framework architecture. ......................................... 115

Figure 48: Example instantiation of the inter-ALTO framework topology. ....................... 116

Figure 49: Example instantiation of the inter-ALTO framework communication schemes.117

Figure 50: Example instantiation of the inter-ALTO framework resulting data flows. ...... 117

Figure 51: Topology used during simulations. N means that there are N links of a

indicated category between given ASes. ................................................................ 118Figure 52: Average traffic on the link between AS5 and AS6. ........................................... 119

Figure 53: An OpenFlow communication between OpenFlow-enabled switch andController (ONF, OpenFlow Switch Specification 1.0.0, Dec. 31, 2009). ................ 120

Figure 54: OpenFlow evolution [25] ................................................................................... 120

Figure 55: OpenFlow switch 1.3.0 (ONF, OpenFlow Switch Specification 1.3.0, June 25,2012). ...................................................................................................................... 121

Figure 56: OpenFlow test domain topology ....................................................................... 122

Figure 57: Multi-domain network for MPLS tests ............................................................... 125


9/174



Figure 58: Topological view of architecture with added scenario overlay (based oncomponent map taken from D3.1). .......................................................................... 127

Figure 59: Detailed MPLS test topology............................................................................. 160

Figure 60: Mapping of HORST to SmartenIT architecture. ................................................ 168

Figure 61: Mapping of SECD to SmartenIT architecture. ................................................... 169

Figure 62: Mapping of ICC to SmartenIT architecture. ...................................................... 169

Figure 63: Mapping of DTM to SmartenIT architecture. ..................................................... 170

Figure 64: Mapping of RB-Tracker to SmartenIT architecture. .......................................... 170

Figure 65: Mapping of SMSP to SmartenIT architecture.................................................... 171

Figure 66: Mapping of MRA to SmartenIT architecture. ..................................................... 171

Figure67: Mapping of OptiPlan to SmartenIT architecture. ................................................ 172

Figure 68: Mapping of vINCENT to SmartenIT architecture. .............................................. 172

Figure 69: Mapping of AQAS to SmartenIT architecture. ................................................... 173

Figure 70: Mapping of MUCAPS to SmartenIT architecture. ............................................. 173

Figure 71: Mapping of QoEnA to the SmartenIT architecture ............................................ 174


10/174



List of TablesTable 1: Results of the service relevance survey. Sum over all criteria. Green: very

relevant, red: not relevant at all. .............................................................................. 18

Table 2: Extended distribution of video categories in YouTube to include 19 categories.

Assignment of popularity values to the 2 new categories (i.e. 18 and 19) andnormalization of the 10 most popular categories so that popularities of all 19categories sum up to 100%. .................................................................................... 20

Table 3: Bandwidth statistics [23]. ..................................................................................... 22

Table 4: State transition matrix for the state transition function:Sx S..................... 23

Table 5: Characteristics of Dropbox accounts from the 49 volunteers [1] .......................... 27

Table 6: Characteristics of User Profiles (B=Beginners [22% of users], S=SynchronizationUsers [30%], P=Power Users [48%]) [1] ................................................................. 28

Table 7: Parameters of mapping functions (seeFigure 10) of stalling parameters to MOStogether with coefficient of determination R2 as goodness-of-fit measure. [59] ...... 32

Table 8: Users and its Cloud services preference ranking ................................................ 76

Table 9: The steps to combine Cloud services preference ranking of each users ............ 77

Table 10: Probabilistic Values for the Preference Ranking. ............................................... 77

Table 11: Local application scenario before shaping ......................................................... 82

Table 12: Local application scenario after shaping ............................................................ 83

Table 13: Savings in stepwise link upgrade cycles ............................................................ 89

Table 14: Adherence of mechanisms to scenarios. ......................................................... 128Table 15: Overview of proposed TMS w.r.t. scenarios. Absolute values. 3 (dark green):

TMS mainly addresses scenario, 0 (white): TMS does not address scenario. ...... 129

Table 16: Summary of mechanisms properties ............................................................... 133

Table 17: Overview of mechanisms decision-taking process and envisioned innovation 138

Table 18: Overall SmartenIT SMART objective addressed. (Source: [110]) .................... 146

Table 19: Theoretical SmartenIT SMART objectives addressed. (Source: [110]) ............ 146


11/174


12/174



1 Executive Summary

This document is the deliverable D2.2 Report on Definitions of Traffic ManagementMechanisms and Initial Evaluation Results of Work Package 2 Theory and Modellingwithin the ICT SmartenIT Project 317846. The main objectives of Deliverable D2.2 are as

follows:Objective 1: Propose and justify traffic management mechanisms, which overcomecurrent limitations of existing services in communication networks. In particular differentviewpoints of the involved stakeholders are not taken into account. In SmartenIT the viewpoints of the stakeholders, specifically Internet Service Providers (ISPs), Cloud Providers,and End-Users, are addressed, to avoid unnecessary costs, e.g., by saving energy orexpensive inter domain traffic while providing good service quality in terms of Quality-of-Experience to end users. More details on the addressed stakeholders and scenarios canbe found in D1.1 and D1.2 respectively. Further on, current traffic management solutionsdo not take into account social awareness which can be utilized to predict demand of

content and analyze user interaction.In order to collect propositions for a subsequent SmartenIT traffic management solution, aset of potential mechanisms with innovative features have to be defined, together withinitial evaluation results and assessment of its positioning against the SmartenIT scenariosand architecture, thus providing evidence whether the traffic management mechanismshould be further pursued and assessed.

Objective 2: Provide models for the evaluation of the proposed mechanisms. Forsubsequent performance evaluation of the proposed mechanisms, theoretical models andsimulation models are necessary. The models need to take into account the differentstakeholders and their goals which are involved in service delivery chain. In particular

models need to be developed for mechanisms that specifically address applicationsselected by SmartenIT.

Addressing objective 1, a broad set of traffic management solutions were proposed, on thebasis of both the scope of the project and of the overview of existing overlay trafficmanagement solutions given in D2.1 [109]. For each solution proposed, the scenariosdefined in D1.2 [108] were addressed, namely inter-cloud communication, global servicemobility, social awareness and energy efficiency.

Since considerable overlaps in the four scenarios defined initially were identified, it wasdecided to merge these scenarios in the recent progress of the project. This established a)the operator focused scenario, which covers the perspective of ISPs and cloud operators

and solutions with decision metrics at data centers or the backbone-network and b) theend user focused scenario, which covers traffic management solutions that address theperspective of the end user and deploy decision metrics at end devices or access-networks, as documented in D1.2, which evolved in parallel with the present deliverable.

Therefore, the traffic management solutions introduced and studied in this deliverablewere also mapped to the operator focused and the end user focused scenarios. Themapping shows that the traffic management solutions mainly addressing inter-cloudcommunication constitute the operator focused scenario, whereas solutions addressingmainly global service mobility and social awareness are covered by the end user focusedscenario.

For subsequent performance evaluation of traffic management solutions, the factors thathave a key influence on the associated mechanism were identified, as well as key


13/174



performance metrics. An initial evaluation for each proposed traffic managementmechanism was provided, as far as possible in this stage of the project. The evaluationswere based on initial estimations and argumentation, and/or were taken from literature andaddress whether the relevant solution is worth detailed examination.

Addressing objective 2, relevant applications for a SmartenIT solution were identified in thepresent deliverable. For this purpose, a service relevance survey and an applicationrelevance survey of services and applications considered for a SmartenIT trafficmanagement solution were conducted. The results of the surveys show that video-on-demand and file-storage are the most relevant services for SmartenIT, as well as thatYouTube and Dropbox are the most relevant applications for the respective services. Forevaluation purposes, we use existing theoretical and simulation models from the literature,but also develop new models, to cope with proposed modifications in the protocols andalgorithms. Since applications like Dropbox came up just recently, appropriate models forsuch applications barely exist and may have to be developed.

Furthermore models for the Quality-of-Experience perceived by end-users for each

specific application were defined, in order to assess the performance of the mechanismsfrom the end-user perspective. To get one step further towards a complete evaluationframework, for each simulation and theoretic model, it was shown how it is deployed in abroader environment to evaluate traffic management solutions. This was done byidentifying models that should complement them in a complete evaluation framework forthe proposed traffic management solutions and addressed scenarios, which will bedeveloped in task T2.4.

The synergies of the proposed mechanisms were studied extensively to find possibleoverlaps and complementarities. The mechanisms were grouped into 5 differentcategories reflecting the main characteristics of the mechanisms, namely Content

Placement, Delivery Scheduling, Ranking, Communication Protocols andConfiguration Frameworks. The categories show traffic management mechanisms thatshare the same characteristics. The main outcome of the deliverable is that certainproposed solutions share the same goal. The identified synergies allow grouping trafficmanagement solutions that can be combined to fit a particular use-case. Thus, a basis fordeliverable D2.3 is provided where the use-cases and their parameters will be defined.

Finally, this deliverable also provides a basis for the decision on which traffic managementsolutions will be further evaluated by analysis and simulation in WP2. The analysis of themechanisms as well as that of their synergies will also serve as the basis for limiting theset of mechanisms whose implementations will be integrated in the system architecturedeveloped in WP3.


14/174



2 Introduction

SmartenIT targets an incentive-compatible cross-layer network management scheme fornetwork and cloud operators, cloud service providers, and end-users, as denoted in [110].Specifically, SmartenIT aims to address accordingly load and traffic patterns or special

application requirements, to employ Quality-of-Experience (QoE)-awareness. Additionally,one of the key targets of SmartenIT is the exploitation of social awareness (in terms ofuser social relationships and interests as an extra channel of information to characterizethe end-users of the cloud services, and thus, predict demand. As a result, efficientcontent placement and pre-fetching can be supported, as well as migration of workloadand Virtual Machines (VMs), etc.

Moreover, one of the key objectives of SmartenIT is energy efficiency both in the Provider-and the End-User-side. Therefore, SmartenIT aims to design Traffic Management (TM)mechanisms that will achieve energy efficiency, i.e. keep energy consumption low for datacenters, networks or in end-users mobile devices. Thus, the energy efficiency with respect

to both end-user devices and underlying networking and application provisioninginfrastructure is tackled to ensure an operationally efficient management. Nonetheless,incentive-compatibility of network management mechanisms for improving metrics in alllayers and among all players will serve as the major mechanism to deal with real-lifescenarios. Furthermore, major overlay applications, whose traffic is to be tackled bySmartenIT, as selected by WP1, include video streaming and online storage applications;major representatives of which are YouTube and Dropbox, respectively.

Regarding the design of appropriate TM mechanisms that inevitably deal with TM of inter-domain flows at the Internet scale, a major challenge has been how to assure that thedata/content transfers will indeed elicit the desired Quality-of-Service (QoS) properties;thus, attaining the relevant QoE goals for the end user. To this end, three alternativesappear:

a. Pure IP and the current EGP (e.g., BGP) / IGP (e.g., OSPF) set-up.

b. IP networks management/control plane enhancements allowing inter-domain QoS-related prioritization mechanisms or novel TE products, so as to have some controlon the per-AS statistical performance of the routes selected.

c. Sub-IP layer routing and/or internal and external routing protocols configuration.

Regarding the first option, this is the most general approach, ensuring the applicability ofthe proposed mechanisms at Internet scale; this is, thus, a worst case scenario but alsothe most generic approach. The network topology and routing are taken as given androuting decisions cannot be affected in inter-domain scale. In particular, the respectivemechanisms rely on overlay decisions regarding the placement of caches, load balancingtechniques relying on DNS or overlay information, deciding on the scheduling of datatransfers, and their respective sending rates along with shaping.

Regarding the second option, on the IP layer, the softest approach is the DifferentiatedServices (DiffServ) mechanism, if applied in different interconnected domains. However,the involved network operators have to agree on similar DiffServ classes, accept markingat the Points of Interest (PoIs) and respect commonly defined QoS policies andclassification schemes. Technically, this is supported with the use of DiffServ brokers.However, network operators dont seem to have enough incentives to deploy such

brokers, and therefore, we can conclude that DiffServ is currently not supported in theinter-domain context.


15/174



The third and final option is complementary to the first one. Mechanisms defined to workon top of the Internet could be further enhanced with TE allowing for better routes forcontent delivery that are engineered: i) in sub-IP layer, i.e. properly configured andprovisioned MPLS tunnels, or ii) to alter IGP/EGP configurations using Intelligent RouteControl techniques [40]. Such solutions are applicable only for multi-homed networks and

result in significant gains only for large networks with multiple neighboring networks.The SmartenIT proposed mechanisms in this deliverable have been mostly designed tofunction over pure IP. This means that no additional functionality is required so that theproposed TM solutions can work and improve any considered service. This decision is dueto the fact that the large-scale IP network is the dominant paradigm today, i.e. networksacross multiple administrative domains simply exchange BGP information and data, whichdo not implement inter-domain QoS.

Finally, another interesting issue that affects the design of the SmartenIT mechanismspresented in this deliverable is the awareness regarding the type of traffic for which themechanisms are applicable. A major constraint here is that inter-domain traffic over

peering and transit links is by definition a service-agnostic aggregation of both elastic andinelastic traffic. Although DPI is deployed in certain cases, its existence cannot be takenfor granted. In general, it is inherently too costly for networks to examine the compositionof those traffic aggregates and try to treat differently the various constituent traffic streams.Thus, this is a major constraint that also complicates the mechanism design as well as theactual potential of intervention of the SmartenIT mechanisms on the inter-domain networklayer. Concluding, the deployment of smart overlays or cross-layer mechanisms thatcombine information from both the network and the cloud layer at the network edges arepromising in this context.

2.1 Purpose of this DocumentThe main goals of this deliverable are as follows:

Proposal and specification of incentive-based TM mechanisms and their intelligencefor the efficient handling of traffic generated by overlay applications in an energyefficient manner.

Definition of related scenarios and use-cases for each proposed TM mechanismand identification of key influence factors and evaluation metrics.

Development of theoretical and simulation models for the evaluation of the specifiedTM mechanisms, as well as models employing game-theoretic aspects to

investigate behaviors of different stakeholders when adopting such TMmechanisms,

Description of preliminary results of the evaluation of the various TM mechanisms(where applicable).

Deliverable D2.2 is the 2nddeliverable of WP2 and sets the basis for the development ofintelligence, mechanisms and models that will constitute the heart of the SmartenITsolutions. The work presented in Deliverable D2.2 will be further evolved in the nextphases of the project, and it will be finalized and concluded in Deliverable D2.4 Report onDefinitions of Traffic Management Mechanisms and Initial Evaluation Results (FinalVersion) which will be delivered at the end of Year 2 of the project.


16/174



2.2 Document Outline

This document is organized as follows:

Chapter 3 initially summarizes work performed in WP1 on the selection of overlayapplications whose traffic is to be tackled by SmartenIT. Then, appropriate models

developed within SmartenIT for the assessment of QoE/QoS as well as other metricsrelated to the selected application categories are provided.

Chapter 4 provides the main contribution of this document, which is the specification of thevarious TM mechanisms proposed by SmartenIT, the main scenarios that they address,the key influence factors, i.e. parameters that have significant impact on their performance,key performance metrics that should be monitored and are aimed to be improved by eachmechanisms, and finally, some preliminary evaluation results, where available already.

Chapter 5 provides communication and configuration frameworks that might be useful for aSmartenIT solution. For each framework, its specification, its potential applicability to TMSand initial theoretical or functional evaluation results are provided.

Chapter 6 addresses the potential synergies among the specified mechanisms and aims toqualitatively assess the impact of their operation when combined, so as to address morecomplex use cases, or use cases that are not sufficiently addressed by each ofmechanisms alone.

Chapter 7 summarizes the deliverable and draws the major conclusions on the specifiedTM mechanisms and next steps of the investigations of SmartenIT WP2.

Chapter 8 reports which SMART objectives, as described in SmartenITs Description ofWork (DoW) [110], have been addressed by the work performed in WP2 and reported inD2.2.


17/174



3 Definition of Relevant Applications and RelatedModels

In this chapter we define relevant applications considered for a SmartenIT solution.Relevant applications were identified in a two stage survey among partners. For moredetails on the application selection survey, please refer to deliverable D1.2 [108].

For the selected applications we define simulation models and theoretical models for theevaluation of the traffic management solution proposed in Chapter 4. To be able toevaluate the solutions with respect to the scope of the project we further define models forenergy efficiency, Quality-of-Experience and game theory.

3.1 Selection of Relevant Applications for 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 ofthe survey was to identify the applications most relevant for SmartenIT, based on carefullyselected criteria.

The cloud application survey was performed among the partners in two steps. The firststep was a service relevance survey. Its goal was to identify the most relevant services forSmartenIT. In the second step most relevant applications were selected out of the mostrelevant service categories.

For each service the relevance of 13 criteria was rated with a value from 1 to 5, for notrelevant at all to very relevant for SmartenIT. Table 1 shows the service with highestsum 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 DataCenters are rated most relevant for SmartenIT.

Based on the most relevant services File Storage and Video on Demand a subsequentsurvey on applications relevant for SmartenIT was conducted. The criteria were limited to8 to cover only the criteria which differ for the considered applications.

The Video / Music on Demand application most relevant for SmartenIT is YouTube sinceit has the highest mean scores, is very popular and produces a high traffic volume. Theproblem with applications like YouTube is the limited intervention potential. The clients arebased on html5 / flash player and are proprietary.

The File Storage application most relevant for SmartenIT is Dropbox since it has thehighest mean scores, is very popular and produces a high traffic volume. The interventionpotential of Dropbox is not expected to be high, but has still to be investigated. Zettabox isan application similar to Dropbox which was developed by a project partner and thereforehas a high intervention potential. OwnCloud is an open source Dropbox clone and alsogives the opportunity to modify a Dropbox like file storage application.


18/174



Table 1: Results of the service relevance survey. Sum over all criteria.Green: very relevant, red: not relevant at all.

It was agreed within the project to have YouTube and Dropbox as primary applications thatrepresent respectively the services Video on Demand and File Storage. If amodification of the client/server functionality is needed for a solution the correspondingOpen Source implementations Zeta-Box, PiCsMu, Owncloud for File Storage and VLCfor Video on Demand will be used.

3.2 Models for Addressed Applications

In order to evaluate the performance of existing applications and newly proposed trafficmanagement solutions, models of the addressed applications and their key metrics are

needed. Thereby, the foundations are laid for analytical and simulative evaluations.However, all models have to cope with a trade-off between accuracy and complexity. Themore accurately a model represents the application behavior, the more complex it is to getresults, and vice versa.

By modifying the application models, insights into possible optimization approaches areprovided. Moreover, these modified models can be used to predict the expected gain withrespect to a certain metric. In this section initial models for the simulation of the addressedapplications are presented, and theoretical models which are relevant for optimization aredescribed.

3.2.1 Simulation ModelsIn this subsection, we present models developed to serve the need of simulating andevaluating some of the traffic management mechanisms proposed in Chapter 4.

3.2.1.1 Model for Video Dissemination among the Users of an OSN

The model for video dissemination among the users of an OSN was developed in order toevaluate a Socially-aware mechanism for Efficient Content Delivery (SECD) (presented inSection 4.2), which employs a P2P overlay and a Social Proxy Server (SPS) to assistvideo delivery among the users of an OSN, and compare it with an existing approach inliterature, i.e. SocialTube [76]. Therefore, we designed and implemented a complete

evaluation framework to simulate an OSN, whose users are consumers of a video serviceoffered either by the servers of the OSN, or by the server of a third-party-owned


19/174


20/174



Table 2: Extended distribution of video categories in YouTube to include 19 categories.Assignment of popularity values to the 2 new categories (i.e. 18 and 19) and normalizationof the 10 most popular categories so that popularities of all 19 categories sum up to 100%.

Category Percentage of videos

Entertainment 25.3 % (-0,1)Music

24.7 % (-0,1)Comedy

8.6% (-0,1)People & Blogs

8.6 % (-0,1)Films & Animation

8.5 % (-0,1)Sports

7.5 % (-0,1)News & Politics

3.5 % (-0,1)Autos & Vehicles

3.3 % (-0,1)

How-to & Style 2.3 % (-0,1)Pets & Animals

1.6 % (-0,1)Travel & Events 1.6 %

Education 1.1 %Science & Technology 1.0 %

Unavailable 0.8 %Nonprofits & Activism 0.3 %

Gaming 0.2 %Removed 0.2 %

Added Category 18 0.5%

Added Category 19 0,5%

Additionally, we assume that each user is located in one specific AS by assigning him anAS id. We have assigned to each AS a rank that denotes the popularity of the AS,assuming that ASes with higher popularity have more users. Then, in order to distributethe OSN users among the ASes, we used the Zipf distribution.

3.2.1.1.3 Categorization of viewers

We categorize the viewers of an uploader in three categories, as follows:

Followers: are considered to be the 1-hop or 2-hops friends, who watch over 80%

of the videos uploaded by the uploader. Non-followers: are assumed to be the 1-hop or 2-hops friends who watch less than

80% but more than 30% of the videos uploaded by the uploader.

Other viewers: are assumed to be the 1-hop or 2-hops friends who watch less than30% but more than 20% of the videos uploaded by the uploader, since every viewerof an uploader is assumed to watch at least 20% of videos uploaded by the latter.

Based on the aforementioned categorization of users and the observations in [31] for thenumber of users watching specific percentages of uploaders videos, we assume for eachviewers category in 1 and 2 social hops that it holds: 90% of viewers are at most within two

social hops, while the remaining 10% are in three or more hops; while viewers having atleast one common interest with the users that they follow is a prerequisite. Thus, according


21/174



to these percentages, the assignment of users in 1 and 2 hops (i.e. 90% of viewers) is arandom choice from users with at least one common interest, as follows:

Followers

33% of viewers are characterized as Followers at 1-hop.

2%of viewers are characterized as Followers at 2-hops. Non-followers

37%of viewers are characterized as Non-followers at 1-hop.

12%of viewers are characterized as Non-followers at 2-hops.

Other viewers

2%of viewers are characterized as other viewers at 1-hop.

6%of viewers are characterized as other viewers at 2-hops.

3.2.1.1.4Video viewing and related parametersWe consider a pool of videos in order to simulate a video platform like YouTube. Sinceeach user is active in Facebook for 20 minutes on the average per day and taking intoaccount that the average length of a video is 4 minutes [24], we assume that a user maywatch 1 to 5 videos in this 20-minutes interval, where the number of videos watchedfollows the uniform distribution. Each user can have access to the videos published fromhis 1-hops friends because of the privacy settings of Facebook, however we assume thathe watches videos only related to his interests. As expected, videos of top interest forusers, as well as videos with highest popularity are more likely to be watched.

Moreover, we assume that the number of videos uploaded daily in our system is equal to

1/20 of the total number of user in our system. In each day we decide who users will beuploaders, i.e., they upload and share videos. For this choice we use Bernoulli distribution,where the users are chosen with uniformly random way. Additionally, each user canupload none, one or more videos, but only within the 20-minute slot that he is active inFacebook. Finally, the probability for a user to re-share a video that he has alreadywatched from a friend, i.e. stored in Facebooks server, is 11.8%, while the probability toupload a video watched from the video server of a third-party is 88.2% [76].

Finally, each user is considered to be able to push only one video prefix through hismessaging overlays in any given day. We make this assumption because a user hardlyuploads a video per day, so there is no point trying to push more video prefixes. In thecase where a user uploads more than one video, say two, then he is considered to pushonly one video prefix within that day, while he pushes the video prefix of the remaining un-pushed video in the next day.

3.2.1.1.5 Implementation details

We assume that each user is available to serve the local P2P overlay, i.e., a P2P overlaynetwork, which is built per video and AS to support the dissemination of that specific video,as a leecher during a 4-minutes slot is active in Facebook, while each user is available toserve the local P2P overlay as a seeder during a 20-minute slot is online more generally inInternet. Then, the estimation of the intra-AS traffic generated by a user watching a videois based on the percentage of seeders and leechers that are active during that 4-minutesslot and additionally, are located within the same AS. On the other hand, the estimation ofinter-AS traffic generated by a user watching a video is based on the percentage of


22/174



seeders and leechers that are active during this 4-minutes slot but are located in otherASes, plus the contribution of the external server where the video is hosted.

Furthermore, we use the upload bandwidth available to each user from the other users inthe swarm as well as from the SPS (or the external server in case of SocialTube) as aproxy for users QoE. Our main objective is to keep this available bandwidth for each userhigher than the (average) bit rate of the video being watched in order to assure high (or atleast adequate) QoE. In order to estimate both traffic and QoE, we assign an UL and a DLbandwidth to every user in our system; the assignment is based on statistics presented inTable 3.

Table 3: Bandwidth statistics [23].

Next, we will describe the framework setup for our evaluation: First, we created 3963nodes and defined their social relationships based on the SNAP dataset [80]. Second, wedistribute users (nodes) in 4 different ASes of varying sizes using the Zipf distribution;specifically, we assume that the AS with id 1 has rank 1 and thus, the highest number ofusers is assigned to it, while the AS with id 4 has rank 4 and thus, the least users of all 4ASes.

Moreover, we created a pool of 9000 videos and we assigned to each video an interestcategory and a popularity value following the methodology described in Section 4.2.4.Additionally, each video has been considered to have a random size from 20 to 30 MB(uniform selection), and the bit rate of each video has been set equal to 330 Kbps.

Furthermore, we set the cache size of each user equal to 300 MB, which can beconsidered as a rather low value taking into account the TBs of storage available (at lowcost) in users premises, and the cache size on each one of the four SPSs, one SPS perAS, to be proportional to the number of users assigned to the respective AS. For eachuser connected to the SPS, the SPS increase the size his cache for one prefix and onevideo, i.e., 33 MB in total for a prefix and a video. Finally, the simulation lasted 30 cyclescorresponding to 30 days. Finally, we implemented our evaluation framework in MATLAB.

3.2.1.2 Simulation Model for HTTP Video Streaming

In February 2012 YouTube introduced the Range Algorithm to control the data flow for http

video streaming. In contrary to the previously used Throttling Algorithm, the RangedAlgorithm only requests a block of data when the pre-buffered playtime drops below acertain threshold. Therefore network bandwidth is consumed only when needed.Especially when users dont watch a video until the end or if they jump through the videothis saves bandwidth compared to the Throttling Algorithm. The requests of the ThrottlingAlgorithm only depend on the bitrate of the video and do not consider the pre-bufferedplayback time.

In this subsection we present our results from experiments with the YouTube videoplayback buffer to investigate the Range Algorithm. The goal of the experiments is toreverse engineer the range algorithm to develop a model for HTTP video streaming. For

the study measurements for 100 randomly chosen popular videos were conducted. Eachvideo was replayed at least 12 times in different resolutions, so that more than 2400


23/174



samples were obtained. Samples with measurement errors were omitted for the analysis.The YouTube monitoring tool YoMo was used to monitor and record the buffered playtimewhile the videos were played back in the measurements.

Figure 2: Buffered playtime while streaming a YouTube video.

Figure 2 shows the pre-buffered playtime of a YouTube video dependent of the playtime.The buffered playtime increases sharply at the beginning of the playback to pre-bufferplaytime. Hence, blocks are requested immediately after completing the previous block.After exceeding a threshold of 50 seconds pre-buffered playtime blocks are only requested

when the playtime drops below that threshold. When the last block is downloaded the restof the video is downloaded and can be played back.

This behavior can be modeled by a finite state machine. Figure 3 shows a simple finitestate machine which models the YouTube player requests and hence the YouTube sourcetraffic. A finite state machine is defined by a quintuple (, S, s_0, , F).

Table 4: State transition matrix for the state transition function:Sx S

Input\Current State pb == 0 pb += s/ pb -= c

a, pb> pb += s/ pb -= c pb -= c

a, pb pb == 0 pb == 0 pb -= c

!a, pb


24/174



Figure 3: Finite state machine for a video streaming source traffic model.

The input alphabet is ={a,!a}x{pb>,pb


25/174



Figure 4 shows the cumulative distribution of measured YouTube video bitrates and videosizes for three different resolutions 240p, 360p and 480p. As expected the video bit-rateincreases with the resolution of the video. Videos of the same resolution can have differentbit-rates, since for recent codecs the video-bitrate highly depends on the amount of self-information in the video. E.g., videos with frequently changing scenes need a higher bit-

rate than still images, because more information has to be encoded. For these initialmeasurements a uniform distribution of the video bit-rates can be assumed. Additionalmeasurements are required to get a better assessment of the video bit-rate distribution formore videos. Furthermore, the distribution of block bit-rates has to be measured, which isneeded as parameter for the model.

Corresponding to higher bit-rates video sizes tend to be larger for higher video resolutions.The video size distribution has a decent tail, e.g., for resolution 480p more than 95% of themeasured videos are smaller than 50MB and few videos are larger than 90 MB. Thisproposes to use an Erlang-k distribution to model the video size distribution of YouTubevideos. The parameters of the Erlang-k distribution to fit YouTube video sizes still have to

be determined.

Figure 5: Cumulative distribution ofmeasured block sizes.

Figure 6: Cumulative distribution of pre-buffered playtime.

Figure 5 shows the cumulative distribution of block sizes of YouTube video streams inthree different resolutions. The block size distributions are depicted separately for middleblocks and the last block of a video. A YouTube video can consist of zero or more middleblocks and one last block. The middle blocks have constant size and the size of the last

block is simply the size of the rest of the video. For resolutions 240p and 360p a middleblock of a YouTube video stream is about 1.78 MB. For 480p resolution the middle blockof a YouTube video stream is about 2.46 MB. The last blocks containing the rest of thevideo are assumed to be distributed uniformly with lower bound 0 and upper bound 1.78MB for resolutions 240p/360p or upper bound 2.46 MB or resolution 480p.Hence, forYouTube video streaming we can define the block size parameter s for a video with size S:

= 1! " #, " $

, %.

C is a constant which is 1.78 MB for 240p/360p and 2.46 MB for 480p resolution forYouTube video streaming. Hence a video with size S has &/' 1blocks. The videoduration D can be determined by dividing the block sizes with the block bitrates (:


26/174



) = * (

-

Figure 6 shows the buffered playtime at the time of a block request for different videoresolutions. The buffered playtime is 50 seconds on average when a new block isrequested. The playtime when a block is requested varies and can be fit with a normaldistribution. Hence, in a detailed model for YouTube the thresholdcan be modeled as arandom variable that follows a normal distribution with mean 50 seconds.

This basic model does not consider the available bandwidth and download speed of theblocks. The key influence factor on http video streaming QoE is stalling. Stalling occurs ifthe video buffer drops below a certain threshold, such that a fluent playback is no morepossible. The buffer of a video that is stalling while playback is depicted in Figure 7. Thevideo is initially pre-buffered until the video buffer hits a certain threshold. Then the videoplayback starts. In this case the network data rate is slower than the video bit-rate, due toa bottleneck which could be limited bandwidth. The video buffer decreases until it dropsbelow a threshold and the video stalls. The video stops playing until the buffer exceeds the

playing threshold and starts running again.

Figure 7: Video buffer while streaming a video with limited network data rate [59].

The basic model could be adopted by including the network data rate such that the statepb==0 is reached if the data rate is too slow, which means that the video is stalling. Amore detailed model for http video streaming should also consider dynamic adaptivechanges of the video resolution, which could be modeled by adding a dimension in thestate machine, having one state machine for each resolution that are connected to eachother.

The simulation model for HTTP video streaming can be used as a source traffic model for

video traffic. Such it can be implemented in any flow- or packet-level simulationenvironment including video sources, which could be servers in data centers of a CDN or


27/174



peers in a P2P video streaming system. For a complete evaluation model of a HTTP videostreaming system we need QoE models for HTTP streaming which are described in3.2.2.2. To evaluate video streaming in the context of the whole service infrastructurewhich consists of several servers, and to take into account social awareness, we furtherneed models for the video-CDN infrastructure and the propagation and requests of videos

in online social networks. There have been various measurement studies which analyzethe CDN infrastructure of YouTube [3][116][4].A model for video requests and the videopopularity in online social networks is provided in Section 3.2.1.1 and in [77].

3.2.1.3 Simulation Model for Dropbox

To derive typical usage scenarios and QoE influence factors of cloud storage services fora subsequent simulation model, we conducted a Dropbox survey. For this survey, adedicated application was installed on the participants Dropbox account in order to gatherinformation on available and used storage capacity. Depending on users goals andspecific purposes for using Dropbox, their personal characteristics and the usage situation,the impact of influence factors on Dropbox QoE may differ. Therefore, the informationcollected in this second survey is used to define user profiles and groups of QoE influencefactors by using the Expectation Maximization (EM) cluster algorithm. For modelingDropbox QoE depending on the actual usage context and situation, we analyse theconnection between these clusters to map user groups to sets of QoE influence factors.

For the Dropbox survey 49 volunteers were recruited. Table 5 depicts the percentage ofworkers and volunteers with different Dropbox account sizes and amounts of stored data(i.e. used space). The table shows that 17% of the workers only have the initial amount ofdata stored (example files and folders with a total size of 1.4 MB) in their Dropbox folder.For 71.15%, the available account size is between 3GB and 10GB Dropbox space.

Table 5: Characteristics of Dropbox accounts from the 49 volunteers [1]

Used Space Percentage of volunteers

Initial amount 17.31%

100MB 67.31%

1GB 40.38%

Account Size Percentage of volunteers

2GB 17.31%

3GB 71.15%

10GB 57.69%

We defined a user profile by taking into account: (a) the usage duration of Dropbox (for afew days, up to one year, more than a year), (b) the number of linked devices (1,, 5,more than 5), (c) experience with in-conflict files, and (d) especially their main use case /reason to use Dropbox (backup, synchronization, collaboration, file sharing and versioncontrol). We used the Expectation Maximization (EM) cluster algorithm of the machinelearning software WEKA to determine different user groups. This approach resulted in sixclusters containing two empty clusters and one with only three respondents who did notanswer some of the questions. These three clusters were excluded from further analysis.In the following we will refer to the three remaining clusters as beginners, synchronizationusers and power users.


28/174



Table 6: Characteristics of User Profiles (B=Beginners [22% of users], S=SynchronizationUsers [30%], P=Power Users [48%]) [1]

Characteristic Beginners B Sync. Users S Power Users P

Ratio 22% 30% 48%

Usage Time Up to 1 Year > 1 Year > 1 Year

Avg. Number of Devices 1.4 3.8 2.6

OS (Main Device) Windows Windows, MacOS Windows, MacOS

In-conflict Files 10.0% 0.0% 68.2%

In Table 6 some characteristics of the different user profiles are shown. The beginnerscluster contains 10 respondents using Dropbox up to one year. The synchronization users

cluster consists of 14 users and is characterized by a common Dropbox usage time ofmore than a year (78.6%). 22 users are part of the power users cluster. In this cluster allthe respondents use Dropbox for more than a year. Further, the table depicts thatsynchronization users push to many linked devices (mean=3.8) while power users onaverage use 2.6 devices for using Dropbox.

Figure 8depicts the main usage for the different clusters. The beginners use Dropboxmainly for collaboration (50.0%) and file sharing (40.0%) while the synchronization usersmake a greater use of it for synchronization (64.3%) and backup (14.3%). For the powerusers synchronization is still dominating (40.9%) but the use purposes are more balancedthan in the other clusters. Moreover, Table 6 shows, that 10.0% of the beginners and68.2% of the long-term users have experienced in conflict files. This can be explained bythe use of Dropbox for collaboration of the beginners and power users and the overallusage duration of the power users. [1]

Figure 8: Most important use cases for Dropbox [1].

For a complete evaluation model of a cloud storage system we need the QoE modelspecified in the next section 3.2.2.1. Furthermore we need models for the number of filesstored on the file storage systems and their file-sizes. Finally we need to study and modelthe propagation of files in collaboration networks and the file-sharing behavior of cloud


29/174



storage users. This includes the formation of groups which share a set of files dependenton file-size and file-type.

To simulate Dropbox traffic at flow-level we need to further investigate the Dropbox-P2Pprotocol and its dissemination strategy.

3.2.2 Theoretical Models

For evaluating the user perceived quality of the selected applications in SmartenIT, QoEmodels are required which allow mapping objectively measurable parameters likedownload time onto QoE. In this section, theoretical models will be described which can beused for further evaluations and studies.

3.2.2.1 Quality-of-Experience Models for Dropbox

The cloud-based file storage service QoE Model was described in detail in [1] from whichthe following material is taken:

A subjective lab study was conducted at the premises of Telecommunications ResearchCenter Vienna (FTW) in order to quantify the impact of waiting times on QoE for cloudstorage and file synchronization services like Dropbox considering the following tasks:initialization, storage, retrieval, multi-device sync. Figure 9 depicts the obtained results interms of overall quality. The study results do not only show that perception (and rating) ishighly non-linear and exhibits only limited saturation effects (similar to file downloads), butalso that end-user sensitivity is dependent on the task context. For example, users tend tobe more tolerant with slow storage operations as compared to retrieve ones, as observedin Figure 9b and Figure 9c, and are even more patient with multi-device filesynchronization, as depicted in Figure 9d. In addition, saturation effects are different forboth storage/retrieval scenarios: a slight saturation effect occurs for file retrieval after 2

seconds, which is not observed in the case of storage. For more details on this studyplease refer to [19].

According to the actual situation S including the actual task and conditions like number offiles, different shapes of curves are observed in Figure 9. Thus, the QoE model functionfS(t) provides the MOS for this situation depending on the short-term influence factorwaiting time t; an appropriate such function is fS(t) = a log(t) + b. However, the overall QoEQ(S, t, F) also needs to take into account the long-term influence factors F which providean upper bound for Q. Additional degradations during the usage of the service, i.e. throughwaiting times, may occur. For example, security is not affected during the usage ofDropbox, but it may define an upper bound for QoE. In contrast, during the usage ofDropbox mainly waiting times, but also the appearance of in-conflict files shape the userperception, and thus should be taken into account. For the sake of simplicity, we focus onwaiting times only as short-term influence factor. Thus,

/, ,!=

!

and for t = 0 it is

/,0,!= * 2

Thus, the importance of an annoyance factor i is reflected by the weight wi. For theexample fS(t) = a log(t)+b, we arrive at /, , ! = 4 67! + 8 2 with =8 2 .


30/174


31/174



User perceived quality of video streaming applications in the Internet is influenced by avariety of factors. As a common denominator, four different categories of influence factors[56], [101] are distinguished, which are influence factors on context, user, system, andcontent level.

- The context level considers aspects like the environment where the user isconsuming the service, the social and cultural background, or the purpose of usingthe service like time killing or information retrieval.

- The user level includes psychological factors like expectations of the user, memoryand recency effects, or the usage history of the application.

- The technical influence factors are abstracted on the system level. They coverinfluences of the transmission network, the devices and screens, but also of theimplementation of the application itself like video buffering strategies.

- For video delivery, the content level addresses the video codec, format, resolution,but also duration, contents of the video, type of video and its motion patterns.

In this section, a simple QoE model for YouTube is presented whose primary focus is itsapplication for QoE monitoring (within the network or at the edge of the network).

Therefore, we take a closer look at objectively measurable influence factors, especially onthe system and content level. For this purpose, subjective user studies are designed thattake into account these influence factors; for more details refer to [59].

The identification of key influence factors has shown that YouTube QoE is mainlydetermined by stalling frequency and stalling length. To quantify YouTube QoE and derivean appropriate model for QoE monitoring, we first provide mapping functions from stallingparameters to MOS values. Then, we provide a simple model for YouTube QoE monitoringunder certain assumptions. Finally, we highlight the limitations of the model.

3.2.2.2.1 QoE Mapping Functions

As fundamental relationship between the stalling parameters and QoE, we utilize the IQXhypothesis [37] which relates QoE and QoS impairments x with an exponential function:!= 4;?@A:!= B + (and >?@C:!= (, respectively. In case of no stalling, i.e. x=0, thevideo perception is not disturbed and the user perceives no stalling. As we asked the userDid you experience these stops as annoying?, the maximum MOS value is obtained, i.e.+=5. In case of strong impairments, however, i.e. : @ D, a well-known rating scaleeffect in subjective studies occurs. Some users tend to not completely utilize the entire

scale, i.e. avoiding ratings at the edges leading to minimum MOS values around 1.5 [115].Hence, we assume =3, =5 and derive the unknown parameter from the subjective user


32/174

D2.2 Definitions of Traf

Documents

Deliverable D2.2 Report on Definitions of Traffic Management Mechanisms and Initial Evaluation Results