Deliverable D2.1 Report On Overview of Overlay Traffic Management Solutions

Seventh Framework STREP No.
317846
Public
D2.1 - Overlay Traffic Management Solutions
Socially-aware Management of New Overlay Application Traffic with Energy Efficiency in the Internet
European Seventh Framework Project FP7-2012-ICT- 317846-STREP
Deliverable D2.1 Report on Overview of Overlay Traffic Management Solutions
The SmartenIT Consortium

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

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

Public
Seventh Framework STREP No. 317846
Document Control
Title: Type: Editor(s): E-mail: Author(s): Report on Overview of Overlay Traffic Management Solutions Public Piotr Wydrych piotr.wydrych@agh.edu.pl Matteo Biancani, Thomas Bocek, Valentin Burger, George Darzanos, Daniel Dnni, Manos Dramitinos, Gerhard Halinger, Fabian Kaup, Andri Lareida, Roman apacz, Ioanna Papafili, Patrick Poullie, Alessandro Predieri, Corinna Schmitt, Michael Seufert, Sergios Soursos, George D. Stamoulis, Rafa Stankiewicz, Krzysztof Wajda, Matthias Wichtlhuber, Piotr Wydrych D2.1-v1.1.doc
Doc ID:
AMENDMENT HISTORY
Version V0.1 Date January 31, 2013 Author Piotr Wydrych, Krzysztof Wajda, Thomas Bocek Piotr Wydrych, Thomas Bocek, Krzysztof Wajda, Martin Waldburger Thomas Bocek, Ioanna Papafili, George D. Stamoulis, Krzysztof Wajda, Matthias Wichtlhuber, Piotr Wydrych All authors All authors Roman apacz All authors Piotr Wydrych All authors Piotr Wydrych Description/Comments First version
V0.1.1
February 8, 2013
Revised ToC
V0.1.2
March 1, 2013
Revised ToC, sketch of input
V0.2 V0.3 V0.3.1 V0.4 V0.4.1 V0.5 V0.5.1
March 18, 2013 March 22, 2013 March 22, 2013 March 28, 2013 March 29, 2013 April 3, 2013 April 4, 2013
Chapters 4 & 5 input Chapter 3 input, minor chapters 4 & 5 input Section 3.1 input Refining text, providing sections introductions Minor after-telco changes Minor changes, abbreviations, author list Minor changes, comments
Page 2 of 87
Version 1.1

Public
Version V0.6 V0.6.1 V0.6.2
Date April 5, 2013 April 6, 2013 April 8, 2013
Author All authors Thomas Bocek Manos Dramitinos, Krzysztof Wajda, Piotr Wydrych Thomas Bocek, Ioanna Papafili, Piotr Wydrych Gerhard Halinger, Sergios Soursos, George D. Stamoulis, Piotr Wydrych All authors Roman apacz Thomas Bocek All authors Rafa Stankiewicz, Piotr Wydrych, Krzysztof Wajda
Description/Comments Editorial changes, text cleanup Minor changes Editorial changes
V0.6.3
April 9, 2013
Version ready for internal review
V0.7
April 22, 2013
Internal review, SMART section Adapting the text according to reviewers comments Adapting the text according to reviewers comments Section 3.1 Fixed minor issues Resolving comments, adding chapters 1 and 6 Final text clean-up, extending Chapter 1
V0.8 V0.8.1 V0.8.2 V1.0 V1.1
April 25, 2013 April 25, 2013 April 25, 2013 April 29, 2013 April 30, 2013
Legal Notices The information in this document is subject to change without notice. The Members of the SmartenIT Consortium make no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of the SmartenIT Consortium shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Version 1.1
Page 3 of 87

Public
Table of Contents
1 Executive Summary 2 Introduction
2.1 2.2 2.3 3.1 3.2 3.3 Purpose of the Document D2.1 Methodology Document Outline Stakeholders Requirements Incentive Schemes Requirements Technical Requirements 3.3.1 Quality of Service 3.3.2 Energy Efficiency Summary Internet Interconnection Agreements Link, Internet, and Transport Layers 4.2.1 Integrated Services (IntServ) 4.2.2 Differentiated Services (DiffServ) 4.2.3 Multi Protocol Label Switching 4.2.4 Multi Protocol Label Switching - Traffic Engineering 4.2.5 BGP-TE 4.2.6 Overprovisioning and link capacity upgrades in ISP networks 4.2.7 Mobile/LTE-related methods: Self-Organizing Networks (SON) 4.2.8 OpenFlow and SDN 4.2.9 Summary Inter-Layer and Application Layer 4.3.1 SmoothIT 4.3.2 P4P 4.3.3 ALTO 4.3.4 Inter-ALTO 4.3.5 CDNI 4.3.6 ABNO 4.3.7 BitTorrent-based TE Mechanisms 4.3.8 BitTorrent with social relations 4.3.9 RB-Tracker 4.3.10 vIncent 4.3.11 NetStitcher 4.3.12 TailGate 4.3.13 Angels in the Cloud 4.3.14 SocialTube 4.3.15 Webcloud 4.3.16 Microblog-based Predictions 4.3.17 CDN and Geo-information from Online Social Networks 4.3.18 Cloud Caching Strategies 4.3.19 Nano Data Centers 4.3.20 Summary Categorization 5.1.1 Inter-/Intra-domain Solutions 5.1.2 Collaborative Solutions 5.1.3 Solutions/Mechanisms pursuing Energy Efficiency 5.1.4 Social Aware Solutions 5.1.5 Resource and Capacity Enhancing
7 9
9 10 10
3 Requirements for SmartenIT Traffic Management Solutions
12
12 16 18 20 22 25
3.4 4.1 4.2
4 Traffic Management Solutions Relevant to SmartenIT
26
26 29 29 30 31 31 32 33 33 34 35 35 35 37 38 39 40 42 42 43 44 45 46 48 49 51 53 55 56 57 58 61
4.3
5 Assessment of Traffic Management Solutions

5.1
63
63 63 64 65 67 68
Page 4 of 87
Version 1.1

Public
5.2 6.1 6.2
5.1.6 Time Scale 5.1.7 Incentive-Based/Compulsory Mechanisms 5.1.8 End-User Related Findings and Summary Key Outcomes and Lessons Learnt Next steps
68 69 69 70
6 Summary and Conclusions
73
73 75
7 SMART Objectives Addressed 8 References 9 Abbreviations 10 Acknowledgements
76 78 84 87
Version 1.1
Page 5 of 87

Public
Page 6 of 87
Version 1.1

Public
1 Executive Summary
This document is the deliverable D2.1 Report on Overview of Overlay Traffic Management Solutions of Work Package 2 Theory and Modeling within the ICT SmartenIT Project 317846. It documents current and prospective traffic management solutions for existing and emerging applications. They are described and analyzed with a main focus on suitability for SmartenIT traffic management mechanisms. Special attention is devoted to traffic generated or served in the application layer complemented by energy efficiency and social awareness aspects. The deliverable summarizes partners efforts in task T2.1 and provides a summary of the work with conclusions and directions for SmartenIT. The document achieves its planned goals by providing: a set of requirements for SmartenIT traffic management solutions, an overview of existing and emerging traffic management mechanisms relevant for SmartenIT, and a precise and easy-to-read characterization of the overviewed solutions.
To address SmartenIT design objectives properly and drive further mechanisms specification in WP2 and their development in WP3 precisely, requirements for SmartenIT traffic management solutions are determined and presented. They are divided into three classes: stakeholders requirements, incentive schemes requirements, and technical requirements. For each scenario, respective stakeholders requirements are enumerated in a detailed way. It is shown that there are some common requirements for all scenarios (e.g., connectivity and infrastructure providers are always interested in minimization of their total operating costs, while users always expect highest Quality of Experience possible). However, the requirements generally differ significantly between scenarios. Therefore, the process of development of new mechanisms has to carefully match them onto the requirements. As shown in both deliverable D1.1 and this document, a number of stakeholders may participate in the SmartenIT scenarios and their incentives may be contradictory. Therefore, an overview of incentive scheme models is presented. It is required for prospective SmartenIT traffic management solutions to be investigated not only from the technical point of view, but also from the stakeholders ones. For completeness, a number of technical requirements for SmartenIT traffic management are determined, each of them being declared as mandatory or optional. The must to have requirements include such as: re-usage of actual network infrastructure, social awareness, cross-layer interactions, or optimization strategies for Quality of Experience improvement. There are also nice to have requirements, which do not have to be always implemented, e.g., capability to handle different type of traffic, traffic manager dynamics, optimization strategies for Quality of Service improvement, or optimization strategies for energy efficiency on the user side. To provide a valuable input to tasks in which SmartenIT traffic management mechanisms will be developed, an extensive state-of-the-art overview of both well-established and recently developed lower-layer and application-level traffic management
Version 1.1
Page 7 of 87

Public
mechanisms is presented together with their relevant properties and applicability to SmartenIT. All solutions are overviewed in a context of t he Internet operators interconnection agreements. As a result of basic business and traffic needs, Internet service providers establish transit (paid) and peering (non-paid) relationships between them what results in different routing policies influencing traffic and application behavior. The overview of lower-layer traffic management solutions used mainly in the operators cores proves that the well-established ones still give providers possibilities to manage Quality of Service (using IntServ), prioritize distinguished traffic (using DiffServ), and configure paths (using MPLS and MPLS-TE). Moreover, emerging mechanisms like SelfOrganizing Networks and Software Defined Networks provide the core with new valuable functionalities. The lower-layer traffic management mechanisms are generic and may work in both centralized and decentralized way. However, to address problems and challenges of the current Internet, the lower-layer solutions have to interoperate with (generic or application-specific) application-layer traffic management solutions. The overview of application-level traffic management mechanisms shows that while there are a number of mechanisms that address various aspects of the SmartenIT objectives, there is no one such a solution that would cover all important topics. Based on their main goal, the solutions can be dived into few groups. The ones like SmoothIT, ALTO, and Inter-ALTO are designed to expose aggregated information about underlay network topology to the overlay applications. While developed for reducing the peer-to-peer traffic costs, they can be also very useful within the SmartenIT traffic management mechanisms. Others like TailGate and Angels in the Cloud use caching to place the content closer to the user and, thus, reduce the core network load. Similarly, Nano Data Centers employ caching to store the content on the users devices in order to reduce the energy consumption in the data centers. There are also solutions that go one step further by trying to be proactive, predict users interests, and download the content before a user requests it (e.g., outside the traffic peaks). This situation gives further tasks in which the traffic management mechanisms will be specified an opportunity to derive from the existing ones and extract valuable ideas or components. In order to support the process of traffic management solutions development, a precise characterization of the overviewed solutions is presented. Each solution has been mapped onto a concise set of key characteristics covering all aspects of the traffic management issues related to SmartenIT objectives. The characteristics vary from the ones traditionally associated with the traffic management topics (like layer in the protocol stack or inter-domain applicability) to the ones selected to address SmartenIT objectives directly (like energy efficiency or social awareness). The summary of the characteristics description is represented in a table format in order to easily direct traffic management mechanisms developers focus towards most important, already implemented, practical solutions. This deep analysis and comparison will guide the development and prototyping of novel traffic management mechanisms on the basis of existing and emerging solutions capabilities. By looking at the traffic management solutions from the three perspectives, i.e., their requirements, state-of-the-art description, and characterization, this work proves that there is a potential for further SmartenIT investigations and experimentations. It is expected that the development of new mechanisms during the project will be considerably supported by this document.
Page 8 of 87
Version 1.1

Public
2 Introduction
With quantitative (when concerning number of users, traffic volumes) and qualitative (when considering new services, applications, etc.) evolution of Internet stimulated by more dynamic behavior and higher expectations of Internet users with regard to service offer and QoE level, we are witnessing rapid development of several new concepts and their implementations, such as overlay applications, online social networks, active networks, Internet of Things, etc. Those novel ideas and proposals impose new requirements on management concepts, introducing the necessity to support flexibility in networks by using traffic monitoring, traffic characterization and then reaction regarding abnormal situations, in order to deal with them or even to prevent them. Proposals and fundamental solutions elaborated for traditional network management are probably not adequate for the evolving Future Internet concept and for contemporary overlay applications, unless they are properly evolved. However, when analyzing such classic approaches, we can profit from those concepts formally organized as FCAPS functional model giving fundamental framework of required functionalities and tasks: Fault, Configuration, Accounting, Performance, and Security. Other lessons come also from the traditional layered TMN management model (from element configuration to business management), described in M.3010 [61]. Works of SmartenIT project focus on higher levels of this layered model. When defining complex application, at first the high-level management functions are designed and then, subsequently, such functions are translated into the bottom layers, to element management, and, finally, to influence user behavior, stimulated by QoE awareness. SmartenIT has defined social awareness, QoE awareness and energy efficiency as the key targets for the design and optimization of traffic management mechanisms for overlay networks and cloud-based applications. Such three main targets can be used as design goals for emerging proposals, e.g., to establish content distribution systems minimizing energy consumption by using energy awareness of its architecture elements and using social awareness translated into efficient structure of caches which minimizes volume of transferred data.
2.1
Purpose of the Document D2.1
This document is the deliverable D2.1 Report on Overview of Overlay Traffic Management Solutions Report within the ICT SmartenIT Project 317846. The main goal of the document is to overview traffic management solutions that can be of importance for the SmartenIT project and bring to the consortium concise knowledge about management mechanisms which can be used in novel service and network environments. Additionally, this deliverable aims to categorize the assessed overview traffic management solutions. This document conforms to the SmartenIT strategy defined in deliverable D5.1 [110] by providing three key project know-how assets: Knowledge on traffic management in the contexts of: stakeholders requirements, incentive compatibility, current and emerging cloud applications and services, traffic characteristics and measurement tools, energy efficiency, as well as QoE and social awareness. Deepened know-how, and scientific and engineering experience with traffic management solutions.
Page 9 of 87
Version 1.1

Public
Theoretical background for traffic management.
Deliverable D2.1 is considered as a report bridging the theoretical foundations and analysis done within WP1 on the scenarios and the design of specific and modular SmartenIT architecture within WP3. As such D2.1 overviews management processes specific for overlay, self-organizing and cloud networks and provides a basis for future work in WP2 and WP3.
2.2
Methodology
The established methodology aims at identification of classical management solutions, identification and brief analysis of novel solutions proposed by SmartenIT partners and then deriving sufficient functionality from existing solutions in order to build and run the traffic management mechanisms in the SmartenIT architecture with relevant functionalities. In order to make an overview of the existing traffic management solutions relevant for SmartenIT, at first the requirements according to the SmartenIT scenarios are analyzed. Based on these requirements, existing traffic management solutions are gathered and summarized to give an idea about the solutions. Existing traffic management solutions are first grouped into: lower layer, which corresponds to OSI layers from layer 2 (link) to 4 (transport), and application layer.
However, these two categories do not capture the situation in enough details, and therefore, 9 distinct categories are defined. All the existing traffic management solutions are assessed according to these categories. In order to provide an overview, Table 4 shows which categories apply to which solutions.
2.3
Document Outline
Deliverable D2.1 is divided into three parts. The first part (Chapter 3) defines the main SmartenIT requirements for traffic management and the relevant mechanisms, namely stakeholders requirements and technical requirements imposing main stresses and limitations for the system. Among technical requirements there is a focus on social awareness and energy efficiency as key issues for the whole SmartenIT project, and directions of optimization, which will be further discussed and developed within WP1 and WP3 activities aiming at scenario completion and architecture design of the SmartenIT system respectively. The second part (Chapter 4) starts with an overview and discussion of Internet interconnection agreements, namely peering and transit. Chapter 4 continues with the presentation and discussion of management approaches and solutions relevant for transport technologies and applications as well. It can be observed that transport-oriented management solutions are built-in into traditional, widely accepted technologies and solutions, such as IP, MPLS, IntServ, DiffServ, etc. New solutions are related to applications or client layer management issues developed in last years. Some solutions and proposals are defined by members of SmartenIT consortium (e.g., Inter-ALTO). Moreover, Chapter 4 discusses the important problem of interworking, both in the inter-
Page 10 of 87
Version 1.1

Public
layer context and within an overlay application), i.e., involving cooperation among elements of overlay architecture. The third part (Chapter 5) provides analysis of solutions previously described in Chapter 4 with the target to categorize these traffic management solutions and assessing their relevance for SmartenIT, by looking at a broad range of different properties. The findings are briefly summarized in Table 4 in Section 5.2 which is then used as the basis for the summary and conclusions presented in Chapter 6.
Version 1.1
Page 11 of 87

Public
3 Requirements for SmartenIT Traffic Management Solutions

In this chapter, a complete set of requirements is described to outline what is required from the traffic management solutions that will be proposed by the SmartenIT project. The presented analysis is an input for further work and is crucial to make the right decisions on the high level, and the algorithms and design levels, as well as the low technical and software development levels. Consideration of three categories of requirements, namely stakeholders' requirements, incentive schemes requirements and technical requirements ensure that a complete and consistent vision of network traffic management is achieved. Moreover, the importance of listed requirements is indicated and thus the priorities of SmartenIT are made clear. The outcome of this analysis will be taken into account by both WP2 and WP3. Selection of existing traffic management mechanisms, extensions thereof and development of new mechanisms, as well as needed functionalities in the overall architecture will be driven by the identified requirements.
3.1
Stakeholders Requirements
Table 1 presents the requirements for the SmartenIT traffic management solutions relevant for scenarios and stakeholders defined in the SmartenIT deliverable D1.1 [83]. The table contains two types of requirements. The first ones (standard bullets) represent the requirements which will be carefully considered whilst designing and developing the SmartenIT traffic management solutions. The second ones (white bullets) represent the requirements that do not have high priority for the project and will be reconsidered (and possibly omitted) in the next phases of the project. Table 1: Stakeholders requirements for the SmartenIT scenarios. Stakeholder Requirements Maintaining levels of network traffic parameters established in SLA; high QoS Compatibility with important existing policies of the Connectivity Provider on service delivery and value, customer relations, etc. Provisioning and optimized use of bandwidth Minimization of total operating cost (OPEX and CAPEX), which includes interconnection costs, energy costs etc. If a cost does not have the highest priority (e.g., more important is saving of natural resources ecology awareness) then new cost-benefit metrics could be considered. Security (Authentication and Authorization) fully controlled access to the resources owned by the Connectivity Provider Monitoring and failure handling to meet SLA
Scenario 1: Inter-cloud communication
Connectivity Providers (Edge ISP, Transit ISP)
Page 12 of 87
Version 1.1

Public
Stakeholder
Requirements Access to the network topology information. The format of topology description should allow Connectivity Providers to hide confidential information that are crucial because of business or operational reasons. On the other hand, abstracted and thus incomplete topology should be enough informative for Infrastructure Providers. Knowledge about the topology and QoS could be used to instruct Connectivity Providers how to set up network connections in order to be optimized for cloud services. Access to the QoS information. Selection of links which should be monitored depends on a topology and deployment (multidomain or single-domain; end-to-end or/and connection between neighboring domains). Available alternative connections Minimization of total operating cost (OPEX and CAPEX), which includes connection costs, energy costs etc. If a cost does not have the highest priority (e.g., more important is saving of natural resources ecology awareness) then new cost-benefit metrics could be considered. Optimized data transfer (scheduling, data fragmentation and transfer possibly via different connections and intermediate storages) Security (Authentication and Authorization) fully controlled access to the resources owned by the Infrastructure Provider Abstracted routing cost information. This kind of information might be useful for applications that want to have control over traffic in a highly distributed environment for optimized operations. Access to the QoE information from Users (this may be used to tune/reconfigure an application or a service) Optimized data transfer (scheduling, data fragmentation and transfer employing different connections and intermediate storages and/or other alternatives) Minimization of storage overhead in data centers and total operating cost (OPEX and CAPEX) which also includes energy costs High QoE Fast access to application data Simplicity and transparency Security of transmitted data
Infrastructure Providers (Cloud Operators)
Information Providers (Content Distribution Networks, Gaming Providers, Application Service Providers, Data Center)
Users
Version 1.1
Page 13 of 87

Public
Stakeholder
Requirements
Scenario 2: Global service mobility Avoiding (to the extent possible) abrupt variations of network traffic parameters (e.g., utilization) caused by traffic Fast reaction to connection changes request (fast switching) Connectivity Minimization of total operating cost (OPEX and CAPEX), which Providers (Edge includes interconnection costs, energy costs, etc. If a cost does ISP, Transit ISP, not have the highest priority (e.g., more important is saving of MNO) natural resources ecology awareness) then new cost-benefit metrics could be considered. Security (Authentication and Authorization) fully controlled access to the resources owned by the Connectivity Provider Monitoring of user mobility (up-to-date information on: where a user is located/when the location is changed) Fast reaction to location changes Optimized usage of resources (storage, computation, bandwidth) Infrastructure Minimization of total operating cost (OPEX and CAPEX), which Providers (Cloud includes connection costs or energy costs. If a cost does not Operators, Cohave the highest priority (e.g., more important is saving of natural location Provider) resources ecology awareness) then new cost-benefit metrics could be considered. Data and services brought as close to the end-user as possible Security (Authentication and Authorization) fully controlled access to the resources owned by the Infrastructure Provider Monitoring of user mobility (up-to-date information on: where a Information user is located/when the location is changed) Providers (Content Optimized data movement to follow a user (one-time or gradual Distribution move, which depends on: 1) the mobility frequency; or 2) amount Networks, Gaming of data needed to execute a task in a new location etc. Providers, Fast reaction for location changes Application Service Access to the QoE information from Users (this may be used to Providers) tune/reconfigure an application or a service) Data as close to the end-user as possible High QoE Users Stable QoE while changing the location Simplicity and transparency Scenario 3. Exploiting online social network information Avoiding (to the extent possible) abrupt variations of network traffic parameters (e.g., utilization) caused by traffic Minimization of total operating cost (OPEX and CAPEX), which includes interconnection costs or energy costs. If a cost does not have the highest priority (e.g., more important is saving of natural resources ecology awareness) then new cost-benefit metrics could be considered. Security (Authentication and Authorization) fully controlled access to the resources owned by the Connectivity Provider
Page 14 of 87
Version 1.1

Public
Stakeholder
Requirements Data and services as close to the end-user groups (social network) as possible Minimization of total operating cost (OPEX and CAPEX), which includes connection costs or energy costs. If a cost does not have the highest priority (e.g., more important is saving of natural resources ecology awareness) then new cost-benefit metrics could be considered. Security (Authentication and Authorization) fully controlled access to the resources owned by the Infrastructure Provider Prediction of interest in certain data based on the social network information Optimized data movement and placement Access to the QoE information from Users (this may be used to tune/reconfigure an application or a service)
Information Providers (Content Distribution Networks, Gaming Providers, Application Service Providers/Online Social Network) Users
High QoE Simplicity and transparency Scenario 4. Collaboration between data centers for energy efficiency Optimizing energy consumption Maintaining levels of network traffic parameters established in SLA; high QoS Optimized use of available bandwidth Minimization of total operating cost (OPEX and CAPEX), which includes interconnection costs or energy costs. If a cost does not have the highest priority (e.g., more important is saving of natural resources ecology awareness) then new cost-benefit metrics could be considered. Security (Authentication and Authorization) fully controlled access to the resources owned by the Connectivity Provider Access to the energy consumption statistics and metadata in data centers Prediction of most suitable location for data and services in the context of green and optimized energy consumption Minimization of total operating cost (OPEX and CAPEX), which includes connection costs or energy costs. If a cost does not have the highest priority (e.g., more important is saving of natural resources ecology awareness) then new cost-benefit metrics could be considered. Security (Authentication and Authorization) fully controlled access to the resources owned by the Infrastructure Provider
Version 1.1
Page 15 of 87

Public
Stakeholder Information Providers (Content Distribution Networks, Gaming Providers, Application Service Providers)
Requirements
Prediction of the most suitable location for data and services in the context of green and optimized energy consumption
Energy Providers
Users
Eliminating outages Stable operation without sudden peak (e.g., as a result of moving data or computational processes between locations) in energy consumption (such a peak increases the Energy Providers cost/OPEX and may lead to operational problems) Optimized QoE (balance between energy consumption and high QoE) Maximal green energy usage and optimized energy consumption (a user is aware of energy consumption issue). New cost-benefit metrics including energy consumption but not in terms of money could be considered.
3.2
Incentive Schemes Requirements
In D1.1 [83], stakeholders have been identified, their (possibly conflicting) interests were investigated and their interactions and potential for collaboration among them, their technical dependencies and business relationships were analyzed. Consequently, a system relying on the participation of third parties to provide service while lacking means to enforce the provision of resources is in need of an incentive scheme. The entities in such systems usually act rational, i.e., selfish, by maximizing their gains from the system while minimizing their contribution. The consequences on system performance can lead to market equilibrium far below the optimum, an effect that has long been known to sociologists as the tragedy of the commons [50]. During the last decade, the problems of lacking incentives have also been observed in networking systems [58]. The SmartenIT scope, as also indicated by the scenarios identified, clearly highlights the fact that multiple stakeholders are involved, each of them having his own interests, strategies and business goals. It must be noted that a SmartenIT solution would inevitably have to accommodate the possibly conflicting goals and needs of the stakeholders in an incentive-compatible way. Otherwise, the SmartenIT propositions would have limited or even no chance of being adopted in practice, resulting in limited or zero impact on the market. To this end, it is important to identify in this section the incentive schemes of interest that could be applied in order for SmartenIT to provide the proper incentives to the stakeholders, given their interests and needs, which have already been described in Section 3.1. One possible taxonomy of incentives and incentive-based schemes is a categorization along two dimensions: type of incentive and time-scale of incentive (see Table 2). A widely applied class of schemes is the class of reciprocal incentives. A very prominent instance using bandwidth as an incentive is the Tit-for-Tat (TFT) mechanism applied by BitTorrent: the scheme ensures that no peer can consume more bandwidth than he contributed to the
Page 16 of 87
Version 1.1

Public
network [23]. Although [71] reveals weaknesses of TFT, a variation of the reciprocal approach is widely deployed with BitTorrent [92]. While BitTorrent is a bilateral scheme involving only two parties, other schemes involve multiple parties [15], [34]. However, those schemes usually only work well, when trading partners have about the same amount of resources at their disposal. Taxation schemes try to account for resource heterogeneity by balancing the overall resource contribution proportionately to the resources available on a node (e.g., [26], [57]). As with real-world taxation, nodes with poor resources pay less, while the richer nodes bear a bigger fraction of the systems load. Taxation works in tightly controlled environments only, as the nodes identity needs to be mapped to its available resources, which usually affords a central trusted entity. Reputation schemes impose an incentive by translating the real-world phenomenon of long-term reputation into the area of networked system. Therefore, the behavior of nodes in the network is mapped to a reputation value and spread in the network or collected centrally (e.g., [48], [62]). Other parties can take the reputation value into account when deciding on providing service to another node. These schemes extend the short-term bilateral reciprocal approach to a longer-term multilateral level. However, reputation schemes are usually complex (especially in distributed environments). Due to their longterm nature, they can also be exploited by strategic or even malicious actors [28]. Other well-researched economic concepts such as credit, bartering and auctions have been translated to the networking domain ([72], [74]). In credit-based schemes, nodes can earn credit by behaving in a system compatible way, which can be spent in return for receiving service. A problem of network economics is security. Double spending, counterfeited money and fraudulent accounting have to be prevented by heavily applying cryptography. Besides providing incentives on a technical level, market players can also be incentivized by bonding their behavior to real-world financial rewards using one of the schemes described above, e.g., by pricing goods accordingly. Table 2: Overview of Incentive Schemes. Incentive Scheme Reciprocation Reputation Network Economics Taxation Credit-Based AuctionBased Bilateral Multilateral Type of Incentive private or shared history global reputation value (virtual) currency Time Scale short-term long-term long-term
winning by bidding resources short-term punishment, if tax is not paid mediumterm
The incentives required to make the SmartenIT concept attractive for the stakeholders have to be evaluated in advance and have to be integrated in the proposed solution from a business perspective as well as on a technical level. On a qualitative level, where utility functions cannot be described easily, a tussle analysis has to be performed. Such an analysis considers the interest of all parties in a qualitative way and tries to ensure that
Version 1.1
Page 17 of 87

Public
fairness and incentive is guaranteed to all stakeholders [63] mentioned in Section 3.1. Where a formal description of utility functions is possible, other tools can be applied such as game theory. Game theory models the payoff and strategies of users and proposes means to predict market equilibria imposing stable points to which the system converges [26], [77]. This general method can be exemplified for the Global Service Mobility scenario: taking reference to Table 2, Infrastructure Providers are interested in monitoring user mobility. However, there is no way of gathering this data, as users have an interest in privacy and mobile network providers will act in the sense of the user, as he pays for the service. Thus, an Incentive for mobile network providers and users is needed to make the data available. A very simple incentive for the user is a reciprocal incentive, e.g., location based services such as the Google traffic jam service could give users not contributing their data a worse quality of service than those who do.
3.3
Technical Requirements
The aim of this section is to present on overview of requirements for traffic management solutions described throughout Chapter 4. Technical requirements described in this section are aligned to the SmartenIT main objectives and purposes as described in the DoW. Requirements for SmartenIT: Re-usage of actual network infrastructure. SmartenIT traffic management should be as less invasive as possible. SmartenIT components must be designed to be located in strategic points of the network (Cloud operator side and Service provider side), while the main purpose of the project is the optimization of overlay network traffic as generated by cloud services offered at end-user All solutions that will expect for a clean slate approach of the actual network architecture will not fit well to SmartenIT purposes. Social awareness. Social awareness is one of three main objectives of SmartenIT project. Traffic management must leverage on social awareness information (mutual relationships between user who are interested in the same contents) to provide optimized decision on traffic management and on content placing. At a first stage, the SmartenIT traffic management mechanisms should infer social information based on device-awareness and specific traffic flows among them. At a later stage, user-awareness could be achieved relying on more fine grain traffic inspection capabilities. Also combinations of user-awareness and device-aware could be use to better coordinate the correlation of traffic information. Capability to handle different types of traffic. Traffic management must offer a comprehensive solution for different types of offered services and related traffic types (Video streaming, P2P, file sharing, online gaming etc.). A selection of services and traffic to be covered can be derived from SmartenIT D1.1 [83] deliverable and its related activities (in terms of traffic and selected scenarios). Cross-layer interactions. Traffic management solutions must provide algorithms to merge information gathered at different layers to build a high level view of the overlay network (formed by Cloud entities and end-user) and the underlying infrastructures (datacenter and core/access network devices) to provide
Page 18 of 87
Version 1.1

Public
optimization of traffic. The information that must be conveyed to the traffic management are network topology, link usage and available bandwidth, Quality of service, available bandwidth, business agreements between different Service providers, end-user location, QoE experienced by end-user, end-to-end performances, energy consumption (both ISP core devices and end-user devices) as well as end-user social interactions. Cloud operators interaction. SmartenIT operation framework foresees the interaction between different cloud operators (Interconnected clouds and federated clouds main scenarios has been identified). A traffic management solution should take into account the exchange of information within the overlay network formed by different cloud operators in terms of cloud operator identities, resources, SLA, capabilities and offered services. The unified representation of information and interface should be designed and implemented to allow the wider interaction among different cloud providers. Specific solutions or implementation of this unified interface will be detailed at a later stage. Traffic manager dynamics. A proper Traffic management solution must assure a compromise between fast reaction to changes in the underlying structure (network topology changes, variation in traffic load .. ) and stability of rules dictated to traffic flows thus avoiding flapping of routing paths, instability and continuous best-path recalculation. Service level agreement (SLA). The interactions between a cloud operator (offering a service) and the end-user (receiving a service) are regulated by a SLA. Proper traffic management solutions must take into account how agreed SLA is impacted by rules dictated to traffic. Moreover, when a scenario of inter-cloud operations is been employed (for example SmartenIT scenario for Service mobility) traffic management solutions must take into account how SLA is mapped when crossing the administrative domains of different cloud operators. Quality of service. A proper solution for traffic management must take into account the following aspects related to QoS (in terms of Throughput, Latency, Packet Loss): 1. QoS is measured and monitored from the underlying infrastructure 2. QoS information must be conveyed from underlying infrastructure to upper layer of overlay network 3. QoS should be accordingly managed when crossing different administrative domains (i.e., external NNI for different service providers) 4. QoS figures should be used to derive a theoretical calculation of Quality of Experience 5. QoS must be one of the main drivers for the traffic management algorithms. Optimization strategies. Traffic management solution must provide a strategy for the optimization of the following aspects: 1. Resources of core network (shorter distance in terms of hops from user to where the requested content is made available)
Version 1.1
Page 19 of 87

Public
2. Resources in terms of Datacenters (find the best strategy to offer the selected service with minimum hops possible from cloud operator datacenter to end-user) thus reducing network traffic and saving datacenter resources) 3. Energy efficiency mainly related to three main areas: network side (Service provider infrastructure) user side (user devices) cloud operator side (datacenter infrastructure)
4. Improvement in QoS figures according to the type of traffic (traffic manager should achieve different gains in QoS/QoE according to the type of traffic/service to be managed) 5. QoE experienced by end user. The following Table 3 presents the traffic management requirements and the relevance to SmartenIT. The requirements have been categorized into the categories must have and nice to have. Table 3: Traffic management requirements for SmartenIT. Traffic Manager Requirements Re-usage of actual network infrastructure Social awareness Capability to handle different type of traffic Cross-layer interactions Cloud Operators interaction Traffic manager dynamics Quality of Service Service level agreement Optimization strategies for core network Optimization strategies for data centers Optimization strategies for energy efficiency Optimization strategies for QoS improvement Optimization strategies for QoE improvement 3.3.1 Quality of Service To better understand QoS requirements, further key aspects with respect to mobile networks will be discussed. Mobile and wireless network operators have to support quality of service within their platform to meet KPI parameters according to SLAs with other parties and service portfolio. This can be achieved by provisioning of enough bandwidth and coverage and by introducing a QoS policy based on differentiation and/or guaranteed resources for the customers and their applications. End-to-end transport paths of most IP
Page 20 of 87
Must have x x
Nice to have
x x x x x x x x network side, user side x cloud operator side x
Version 1.1

Public
applications are traversing several network platforms beyond LTE access and Evolved Packet Core (EPC) involving different administration regions and heterogeneous technologies. Enforcing end-to-end QoS in a global Internet environment is an important and challenging task, which mainly depends on interconnection agreements and standardization of QoS support between multiple carriers. Service level agreements (SLA) between service, network and content providers as well as users with special QoS demands can help to set up interconnections with specified QoS properties and responsibilities as illustrated in Figure 1, but at the current stage have not been deployed.
Video Streaming IP-TV
Service, Content Providers

Multimedia Calls, Conf. Content on the Web
Service Level Agreements (SLA) Between Network Providers
ISP Backbone WLAN, Wimax Enterprise Networks 2/3/4G Mobile Networks
Monitoring, Enforcement of QoS Parameters per Subnetwork
End to End QoS
DSL,FTTH
Residential Users
Public Environment
Business Customers
Figure 1: End-to-end QoS for IP service. Main KPI parameters have to be negotiated and determined in SLAs of Internet access, user applications, as well as interconnection or transit for network providers. The focus of the involved parties is different, where business customers often demand for extremely high network availability and reliability. Residential users are sensitive to throughput and delay, whereas network providers are concerned about resource efficient service provisioning with regard to the demands of all user and application classes. Measurement and monitoring of the QoS performance at servers, interconnection points and/or between ingress and egress of a network is crucial for SLA control. On a single transport path, end-to-end QoS parameters usually can only be guaranteed based on worst case assumptions on the resources, i.e., end-to-end throughput is the minimum that is provided on the interfaces and links on the path, and end-to-end delay is the sum of delays on the sections of a path including (de-)coding in terminal equipment etc. Awareness of the current QoS performance is a basis for fast signaling and handling of problems and failure cases, where automated routing and traffic engineering methods involving backup resources are important as a first aid, together with repair and upgrades of resources for long term treatment of bottlenecks. The QoS and inter-domain aspects are also of interest for SmartenIT. Most intra-domain solutions are not applicable or fail to scale in the inter-domain Internet context. End-to-end QoS also depends on the performance parameters of the transmission systems including
Version 1.1
Page 21 of 87

Public
the terminal equipment, with the user experience (quality of experience, QoE) being the decisive measure for the service quality. It can be determined by subjective estimation e.g., on a mean opinion score (MOS) scale and is partly also assessed by automated methods, e.g., for speech transmission quality as defined by the ITU based on a model for the user sensitivity. Quality of Service considerations are crucial with respect to SmartenIT project especially for the aspects related to QoS measurements within Service provider network and for the mapping of a measured QoS to a perceived QoE for the end user. It must be remarked that SmartenIT main aim is not to provide end-to-end guaranteed QoS (with resource reservation techniques or signaling protocols) but it is more focused in enhancing the QoE as perceived at end-user by optimizing the traffic generated by cloud services. 3.3.2 Energy Efficiency Energy efficiency requirements comprise the entirety of mechanisms and approaches that are targeted at lowering the overall energy consumption. They can be subdivided into aspects concerning the core network as well as the ones concerning the cloud. Both are discussed in detail in the following subsections. 3.3.2.1 Energy Efficiency in Core Networks Core Networks represent the backbone of the Internet [107]. Since the back-bone is designed such it can cope with peak loads, a substantial amount of its resources remains idle [107]. In particular, the authors of [107] suggest the following approaches are employed to reduce energy consumption: 1. Shutting off idle network components using frame-based periodic scheduling [4] or based on traffic statistics [16]. 2. Turning off unused cables in bundled links. The term "bundled link" refers to an aggregation of many smaller capacity links which together form a higher capacity link. Whenever the load is low, unused links can be shut down thus lowering the energy consumption [107]. 3. Deployment of rate-adaptive routers [107], as described in [16], [75] and [17]. The term "rate adaptation" refers to the practice of operating a device blow its capacity [107]. The authors of [30] mention two additional approaches: 4. Compressing traffic in optical networks. 5. Keeping P2P traffic local. Further approaches include the lowering of CPU speed or the reduction of traffic. With respect to the SmartenIT project, the mentioned approaches can be considered as requirements for an energy-efficient core network. The requirements are illustrated in Figure 2.
Page 22 of 87
Version 1.1

Public
Figure 2: Energy Efficiency Requirements in Core Networks. As can be seen from Figure 2, there are numerous approaches to reduce energy in core networks. They can all be summarized in the following requirement for SmartenIT: SmartenIT must provide versatile traffic management mechanisms which allow for the reduction of energy in core networks. 3.3.2.2 Energy Efficiency in Data Centers The idea of using cloud computing to lower power consumption is appealing. The core idea of a white paper published by Google [45] is to reduce energy consumption by replacing the typically underutilized and inefficiently cooled servers operated by individual companies with fewer but highly utilized and efficiently cooled cloud servers, at the expense of some additional network traffic. The idea is illustrated in Figure 3. However, research results indicate that the energy consumption of the network itself can be substantial [43], [10]. Based on [45], [43], [10], and [11], the following methods for reducing energy consumption in data centers can be derived: 1. The migration of virtual machines should be fast and - whenever possible automated, as this improves the load-balancing among physical servers in the cloud. 2. Data centers should be placed where they can be cooled efficiently, e.g., in the far north or south. Furthermore, nodes within a data center should be placed such that cooling energy consumption is minimized. Finally, the possibility of using the heat produced by the nodes in a data center in places where it is required (e.g., the canteen of data center maintenance workers) should be taken into consideration. 3. Retrieving content from data centers should be avoided if caching can be used. The above methods cannot be considered as requirements for SmartenIT directly because SmartenIT does not have an influence on the migration of virtual machines or the placement of data centers. However, SmartenIT should not prevent these approaches from working either. Hence, an additional requirement for SmartenIT can be derived: SmartenIT must be designed such that existing and future approaches to increase energy efficiency in data centers are not at odds with the deployment of SmartenIT.
Version 1.1
Page 23 of 87

Public
Figure 3: Energy Efficiency Comparison of Traditional and Cloud-Based Application Usage. (Source: [45]) 3.3.2.3 Energy Efficiency in Mobile Devices As mobile devices are strictly limited in the available energy capacity, all possible means must be taken to relieve the mobile clients of computationally expensive or data heavy applications. This is relevant, as the improvement of the energy efficiency of the network structure is one of the main objectives within SmartenIT. Furthermore, the user experience is increased by providing a longer battery life by reducing the demands on the mobile devices. Recent studies show that an average of 25% of the power used is consumed by the network interface. A considerable part of this is spent in the ramp or tail phases of wireless connections where no data is transmitted but the device is in a high power state. Hence, the energy is effectively wasted [9], [86]. Aggregating low priority traffic on both sides of the air interface and appending this as soon as high priority data is transmitted can greatly reduce the consumed energy [9]. For this, the feasibility of caching algorithms is to be evaluated and later included on both sides of the wireless interface. Furthermore, the delay tolerance of different services must be categorized and resulting actions be implemented taking this tolerance into account. A requirement is that the energy consumption in connected devices must be monitored, to make informed routing decisions and obtain the necessary data in the desired quality. To do so, it is required to install a component on the participating nodes to allow the monitoring of the energy consumption and the data rate of all network interfaces. A second requirement is the ability to change connectivity as indicated by the SmartenIT component of the current network domain to effectively reduce the power consumption of the device.
Page 24 of 87
Version 1.1

Public
3.4
Summary
The requirements presented and described in this chapter give a general vision of solutions which SmartenIT is going to offer. First, the stakeholders' input is analyzed. To be concrete and narrow down the scope, the analysis is focused on the scenarios defined in the deliverable document D1.1 [83]. The priorities derived from the stakeholders' requirements is an important information for further work in the project (e.g., on the architecture). The incentive schemes subsection gives an overview and preliminary knowledge how challenging the research on incentives for traffic management is in the SmartenIT project. The use of social information from OSNs is one of the major values of the project and it is expected that this allows achieving promising work results. The list of technical requirements complements stakeholders requirements but indicates within which technical boundaries the SmartenIT solutions will be operating.
Version 1.1
Page 25 of 87

Public
4 Traffic Management Solutions Relevant to SmartenIT

This chapter provides an overview over existing traffic management solutions related to SmartenIT. While discussing the structure of this deliverable it became apparent that there is a vast amount of dimensions by which traffic management solutions can be categorized. As a consequence, it was decided that this chapter would restrict itself to categories dealing with interconnection agreements, lower layer solutions and application as well as inter-layer layer solutions and to provide a more finely divided analysis in Chapter 5. Thus, Section 4.1 presents Internet interconnection agreements which can be considered as a layer constituting the basic fabric of the Internet. As this layer is the result of business and traffic needs, the inter-domain routes and links are properly dimensioned. On top of this basic topology, traffic management solutions can be deployed, which can be intra-domain or inter-domain in terms of scope. The layer upon which these traffic management solutions operate can be either the application layer or lower. This is thoroughly investigated in Sections 4.2 and 4.3. In particular, Section 4.2 presents traffic management solutions operating on lower layers, i.e., from the physical layer up to the transport layer. Section 4.3 presents solutions operating on the application layer as well as solutions operating between different layers. In this section the different solutions are explained, categorization is addressed in Chapter 5.
4.1 Internet Interconnection Agreements

Internet interconnection is the glue that keeps the Internet together. The Internet Service Providers establish, dimension and manage inter-domain links, which are required in order to offer global connectivity to their customers. Internet interconnection agreements are standard business agreements, negotiated between the interested networks, and form the Internet topology graph. This also provides a first traffic management solution in the slow time scales, since interconnections are built motivated by the traffic ratios, the need to establish shorter and better in terms of quality Internet routes and the business goals of the operators in terms of attracting revenue and mitigating costs. Clearly, the traffic management solutions presented in the next two sections of this chapter provide a second level of traffic management, which either implicitly or explicitly takes into account the Internet graph formed by the Internet interconnection agreements. There are two basic types of interconnection agreements, each having also some variants, namely peering and transit. Peering is a bilateral interconnection agreement where the two parties reciprocally provide access to each others customers. Internet Peering is typically settlement -free, meaning that neither party pays the other for access to each others customers, as long as the traffic ratio is balanced. On the contrary, if one of the two networks has to terminate much more traffic than what it terminates to the other, then it will ask for some compensation, hence leading to a paid peering relationship. Peering is non-transitive. Transit is the business relationship whereby one network sells access to all destinations in its routing table; large networks that sell Internet termination transit service, while they do not purchase such services from other networks, are called Tier-1 networks. Tier-1 networks maintain peering relationships amongst them. Networks of smaller size are Tier-2 and Tier-3. Transit is a metered service, usually charged with the 95 th percentile rule, i.e., the average bandwidth is computed over 5-min periods and per month the 5% highest measurements are left out. Hence, the various interconnections of each domain have different costs for the traffic carried. Thus, each network when performing Traffic
Page 26 of 87
Version 1.1

Public
Engineering and BGP configuration must take this into account in order to minimize its costs. This clearly is a dimension that is relevant to the SmartenIT envisioned solutions.
Figure 4: Peering and Transit agreements. (Source: [31]) Not all networks typically are willing to peer with any other network. Large networks typically want to charge other networks (and content providers) for reaching their customers (eyeballs). Smaller networks are more eager to peer but are typically refused peering from larger networks, since the latter would prefer them to be their transit customers. Also the establishment of new peering agreements offloads some traffic from other peering and transit links of the network, creating cascading effects. All those issues are important for the establishment of new interconnections and the alternation of the traffic ratios via BGP configuration or Traffic Engineering. A strategy that many Tier-2 networks apply in order to both improve QoS and minimize costs (or even attract revenue from content providers) is donut peering as shown in Figure
Version 1.1
Page 27 of 87

Public
5. This strategy prescribes that a Tier-2 network is present at multiple Internet interconnection points where it peers with same and even smaller sized networks via an open peering policy. This way, it can terminate traffic to a large number of end customers, via those peering links. Therefore, it can then negotiate with content providers partial transit agreements for reaching those eyeballs. Also, it can use the peering links in order to avoid transit charges for traffic of its own customers. A company that applies this successful strategy in the US, attracting significant revenue from content providers, is Mzima.
Figure 5: Donut peering as a gross Traffic Engineering mechanism that attracts revenue. (Source: [73]) Note also that Traffic Management at the Internet Interconnection layer can be used as a business weapon in order to gain competitive advantage in the business, e.g., to force peering even when traffic ratio does not justify this. For instance, consider in Figure 6 network A that wants to peer with B, which is reluctant to do so. A so far for QoS reasons forwards the traffic from its network to B via the transit interconnection it maintains with network L. Since transit prices are fixed in the market, A is indifferent to which transit provider it uses to carry the traffic to B. However, B is not since it is a peer of L while a customer of G. Since transit agreements are exposed via the BGP announcements, A knows via G that B is a customer of G. Therefore, in order to force B to accept peering, it starts forwarding the traffic to B via the transit provider G, increasing Bs co sts since it now has to pay for that traffic which so far had been free. Therefore, B may accept to peer with A, in case this is the most cost efficient solution.
Page 28 of 87
Version 1.1

Public
Figure 6: Traffic Management as a business weapon. (Source: [31]) This example shows the adverse business implications of traffic management decisions taken in the slow time scales; the impact on both QoS and traffic costs for networks may be significant and should not be neglected. Last but not least, the resulting traffic ratios can motivate the deployment of additional infrastructure in the Internet interconnection layer (i.e., new interconnections, capacity upgrades of peering and transit links) and the deployment of additional traffic management solutions, inter- or intra-domain, that will manage the resulting traffic and resources. The latter are overviewed in the two subsequent sections of this chapter.
4.2
Link, Internet, and Transport Layers
The term lower layer refers to the layers starting from physical layer up to the transport layer. The following sections deal with traffic management solutions operating in these layers. Sections 4.2.1 and 4.2.2 introduce IntServ and DiffServ, respectively. IntServ uses the RSVP protocol to reserve network resources in order to provide QoS guarantees. DiffServ is an approach to prioritize traffic according to flags in IP header fields. Section 4.2.3 introduces MPLS which is a protocol allowing for fast packet forwarding based on labels. Some of its extensions are discussed in Section 4.2.4. Section 4.2.7 looks at SelfOrganizing Networks in a mobile environment and Section 4.2.8 presents Software Defined Networks (SDN) and OpenFlow. Finally, a summary is provided in Section 4.2.9. Virtual LANs (VLANs) are often mentioned in the context of traffic management. VLANs are a means to structure LANs, however, since the focus is on structuring a LAN rather than traffic management, they will not be discussed in this section. 4.2.1 Integrated Services (IntServ) Integrated Services (IntServ) is a QoS architecture that allows fine grained (per flow) traffic control in order to enable QoS guarantees [18]. For this purpose not only guaranteed but
Version 1.1
Page 29 of 87

Public
also best-effort services are supported. The RSVP protocol [120], [121] is used by IntServ to place resource reservations along a data path. Thereby IntServ inherits desirable properties of RSVP, such as flexible multicast control and the accommodation of heterogeneous service needs. Although the fine grained traffic control provided by IntServ allows for equally fine grained traffic management to be applied to an IntServ network, the granularity comes at the cost of scalability, as each intermediate router needs to keep track of all IntServ connections that traverse it. For the latter reason and because RSVP introduces some signaling overhead, as well, the application of IntServ in the Internet backbone is infeasible [113] and may also be considered inefficient in the access network. Furthermore, since for IntServ to work, every router along the traffic path must support it, it is not well suited for inter-domain traffic control. Due to IntServs poor scalability, especially large ISPs may choose not to adopt it, which are exactly those with ASs that handle a large amount of traffic. 4.2.2 Differentiated Services (DiffServ) Differentiated Services (DiffServ) is a QoS architecture that provides a scalable mechanism for classifying and managing network traffic and providing QoS on IP networks. Scalability is achieved by aggregating traffic into classes and then applying certain forwarding behaviors to these [14], [46]. DiffServ is therefore often contrasted to IntServ, which trades in scalability for granularity. Within DiffServ architecture a number of DiffServ Per Hop Behaviors (PHB) are defined. They are often referred to as service classes (e.g., the Assured Forwarding service class). This is a terminological inaccuracy. DiffServ PHBs only defines several rules of packet forwarding but do not constitute service classes itself. PHBs can be used for realization of various service classes and QoS support [104]. Although, DiffServ itself does not define service classes and does not specify precisely how to realize given QoS guarantees, IETF proposed a set of 12 classes to be distinguished in telecommunications networks [7]. It also recommends how the classes can be used and proposes how to construct those using DiffServ mechanisms. Association of DiffServ code points (DSCP) with particular classes is proposed. RFC 4594 [7] describes service class requirements qualitatively by a tolerance to packet loss, delay and jitter. Strict values or bounds for the parameters per service class are not provided. RFC 4594 proposes which DiffServ PHB should be used to support each class and suggests using a particular meter/marker implementation as well as an Active Queue Management (AQM) scheme. Additionally, IETF RFC 5127 [19] proposes to aggregate service classes defined in RFC 4594 to four QoS classes. Again, recommendations of how to construct the classes using PHBs, AQM mechanisms, and particular DiffServ elements implementations, are provided. In practice, a differentiation into two classes, premium and best effort can achieve most of the DiffServ classification goals, provided that the premium class can be dimensioned to avoid congestion within this class, e.g., for 50% load. If the premium class is e.g., restricted to control traffic, VPNs of business customers, VoIP and some other applications with low bandwidth demand then they can get almost perfect QoS support by DiffServ, even in cases of single link failures leading to double load on restoration paths. But DiffServ is inappropriate for QoS guarantees for applications of high bandwidth demand if no proper admission control is set up to limit the load in the premium class. In order to provide QoS-guaranteed differentiated services across autonomous systems, inter-AS traffic engineering is essential but complex [105] and therefore not well suited to implement inter-domain traffic control.
Page 30 of 87
Version 1.1

Public
4.2.3 Multi Protocol Label Switching Multiprotocol Label Switching (MPLS [44], [60]) deploys short labels to allow rapid packet switching and establishes virtual paths as a main precondition enabling explicit paths (LSP: label switched path) for traffic demands from source to destination including monitoring statistics for each established LSP. The traffic matrix between edge routers is directly visible from standard LSP monitoring, which is the main reason and advantage of MPLS deployment in ISP aggregation and core networks as compared to pure IP networks, which only provide standard measurement of link loads. MPLS is suited to route aggregated IP flows. The border router between IP and MPLS network, the so called ingress router, assigns an LSP to be followed by the IP packet towards the egress router in the MPLS domain. An LSP design is provisioned to determine the routing/switching in an MPLS network, where LSPs can be optimized for network wide load balancing. On each link, the LSPs are distinguished by different labels that are put into an MPLS shim header in front of the IP packet. The MPLS header encapsulates IP packets in the MPLS domain such that MPLS routing/switching is only based on MPLS header information. As a consequence, this tunneling mechanism makes MPLS networks invisible in trace-route and ping. The labels are only valid on a link in order to allow pairs of neighboring routers to negotiate unique labeling on their interconnection link. Therefore the label in the MPLS header of each packet must be switched on an LSP at each MPLS router for the next link, until the egress router, removes the last label. Several LSPs are usually set up between each edge router pair in an MPLS network for e.g., as backup paths for fast rerouting for failure restoration or to support several QoS classes. The MPLS concept merges connectionless networking (represented by IP) with connection-oriented paradigm in order to combine some automatic functionalities (such as routing) with controlled functionalities, such as path establishment (called LSP Label Switched Path in MPLS). The freedom in LSP set-up means that network administrators can leave the process as an automatic one (LSP is set-up using directly routing information from network layer, e.g., IP) or intervene by imposing additional constraints or even implementing explicit routing. 4.2.4 Multi Protocol Label Switching - Traffic Engineering MPLS Traffic Engineering (TE, [5], [6]) mechanisms are used to minimize network congestion, improve network performance and support enhanced resilience features. MPLS-TE modifies routing patterns to provide efficient mapping of traffic streams to network resources. In details, MPLS-TE has the following features: provides efcient spreading of trafc across the network, avoiding situation of underutilized and over utilized links. takes into account administratively assigned (congured, static) ban dwidth of links. takes the link attributes into account (e.g., delay, jitter). adapts automatically to changing bandwidth and link attributes. recovers to link failures or change in topology.
The idea of implementing Traffic Engineering in MPLS environment is based on marking out specific paths for the Label Switching Path (LSP) on the basis of information about the current state of the use of resources and parameters selected by the network administrator. For this purpose there is a link state routing protocols used such as OSPF
Version 1.1
Page 31 of 87

Public
and IS-IS - allowing to communicate information on the availability of resources and the parameters selected by the administrator. Transmission of information concerning the specific value of the label that defines the LSP is done using RSVP-TE (Resource ReSerVation Protocol with Traffic Engineering extensions) version of protocol. Important features of MPLS TE are predefined/preconfigured backup paths for failure resilience. To enable fast switching onto the alternate path, MPLS TE technology uses a path protection mechanisms and link protection mechanism. By monitoring the LSP path (path protection mechanism), pursued by LSP end routers, and by LSR routers that support data connection, when it detects a malfunctioning LSP or links they can be switched instantly onto the alternate path. Requirements for traffic engineering over MPLS are discussed in [6] and automatic recovery of MPLS networks in [69] and [98], which may be interesting for SmartenIT. Interdomain traffic control by means of MPLS is discussed in [37], where three different signalling methods are offered. Traffic engineering tools can be applied based on MPLS in different ways by ISPs and network providers depending on their network infrastructure and management environment [25], [55], [88]. As an example, when Deutsche Telekom introduced MPLS in the backbone since 2001, a traffic engineering tool (TE Scout [55]) has been set up for throughput optimizing and load balancing in the MPLS environment. This includes a full cycle of permanent monitoring of the traffic demand matrix, discovery of inacceptable load situations triggering a re-optimization of the LSP path design or link upgrades if the overall demand cannot be carried in the current network infrastructure as well as configuration of the LSP design in the the MPLS routers. The benefit of network wide load balancing was evaluated in case studies as compared to independent per link upgrades [55] and with regard to cost and energy savings [54]. 4.2.5 BGP-TE Inter-domain traffic engineering is rather natural consequence of Internet evolution. It aims at set-up and control of paths supporting exchange of data among involved nodes. In this subsection we describe two solutions based on fundamental position and proliferation of MPLS, namely the joint BGP/MPLS based VPNs and as second solution, the interworking supported by inter-domain usage of MPLS or GMPLS control planes. The main idea of BGP/MPLS VPN concept [87] is to connect customer nodes (CE Customer Equipment) via provider nodes (PE - Provider Equipment) using routing information from BGP inter-domain routing and transferring this information to MPLS in order to establish relevant MPLS tunnels. Another concept, which is called the inter-domain MPLS and GMPLS [37], is based on usage of the RSVP routing and control protocol in order to create inter-domain paths in flexible way. In RFC5151 [35], there is a proposal for LSP establishment in inter-domain situations when using RSVP and the following 3 situations are considered: contiguous LSPs, nested LSPs, stitched LSPs.
Page 32 of 87
Version 1.1

Public
Extending MPLS concept out of single-domain network (intra-domain situation) is done in consistent way as in IP/MPLS single-domain case: routing information is made available to MPLS set-up mechanism. The motivations to implement TE are multifold: Supporting QoS requirements. Enhancing resilience by potential set-up or backup paths. Split and separation of paths supporting different types of traffic. Separation of traffic of different customers.
Using MPLS introduces a high level of flexibility in LSP establishment which is governed by control mechanisms and also can be stimulated by management functions. Even if the inter-domain traffic control by means of MPLS is discussed in [37], neither inter-cloud communication, nor global service mobility, nor social awareness, which are key to SmartenIT, are addressed. 4.2.6 Overprovisioning and link capacity upgrades in ISP networks From a network providers perspective, traffic and network management includes a continuous process of monitoring and failure handling in order to stabilize normal operation. Moreover, the planning for operational IP networks has to foresee a steady link upgrade process to adapt to fast traffic growth. Therefore load thresholds are monitored in order to trigger upgrades before traffic variability affects the quality of service. Redundant resources and failure resilience mechanisms have to be provided at least in core and aggregation areas, where link failures have an impact on a large user population. Resource utilization in IP networks is often low. Among the main reasons contributing to overprovisioning for IP traffic and applications are: variability in usage pattern and source traffic on different time scales from short term bursts on the milliseconds scale, up to periodical daily/weekly profiles, demands for redundancy, backup paths and failure resilience in the aggregation and the backbone, cross-layer and cross-domain inefficiencies between application and network layer protocols and between network domains without awareness and sufficient information exchange for overall optimization and partly lacking support for flexible traffic management and load balancing methods on many network platforms especially for new developing technologies and network architectures.
Automated load balancing mechanisms are important not only to handle sudden shifts in traffic demand matrices, but also for including new resources becoming available during a network upgrading process. 4.2.7 Mobile/LTE-related methods: Self-Organizing Networks (SON) MPLS has established an advanced framework providing a set of monitoring and traffic engineering functions for load control in normal operation as well as for failure resilience. Other network technologies in mobile and wireless environment often do not provide full support of basic traffic monitoring and management functionality especially when they are
Version 1.1
Page 33 of 87

Public
newly developing. The IETF demands consideration of security as well as operations and maintenance (OAM) concepts from the start in mandatory section of each new protocol standard document, after suboptimal experience with extending IP protocols without initial security and OAM awareness at a later stage. Mobile and dynamic/adhoc network environments make traffic engineering often much more challenging while offering less control functions. Fast and efficient algorithms for local monitoring and management response have to be established when the network topology and usage pattern are subject to a high rate of change. Then self-organizing networks (SON) [1], [76], [101] as standardized by 3GPP can provide distributed functionality, which is required as soon as a centralized management is no longer capable of tracking the state of the whole dynamic network. Therefore more intelligence has to be put on network elements in order to enable: Decentralized monitoring techniques based on gossiping and tree-based distribution of information [116]; as an alternative monitoring scheme, structured peer-to-peer networks using distributed hash tables are proposed for connecting self-organizing entities. Gossiping and peer-to-peer approaches can deal with dynamic networks subject to a high churn rate. Aggregation and evaluation of information in management overlays, from simple functions, e.g., a sum or a minimum to more complex evaluations of network wide threshold crossings [117], Estimation of the size of networks or of groups with specific characteristics in the network at minimum messaging overhead, as a basic function to be embedded in higher layer evaluations and applications, Efficient topology discovery with scalable information propagation and synchronization [76] and Search methods for highly dynamic networks using combinations of flooding and random walks including partially available information about the path to a target [53].
Again, path optimization with regard to failure resilience has to be included [25], [55], [66]. Together with standardization for pre-configuration mechanisms, future Internet initiatives cover support of the complete traffic engineering cycle, where the main focus is on distributed schemes for heterogeneous and dynamic networks rather than on centralized approaches for static or slowly varying topologies. Even if traffic management support is challenging in heterogeneous network environments achieving different levels of efficiency, a tremendous growth in traffic demand on mobile and wireless networks puts pressure towards optimized resource utilization, and as a non-negligible side effect reduces energy consumption. 4.2.8 OpenFlow and SDN OpenFlow [82] is a standardized specification of communication between two layers Control Layer and Infrastructure Layer - in the Software Defined Network (SDN) architecture [81]. This solution allows sending packet forwarding decisions from a separate controller (typically a standard server) to the OpenFlow-enable switches. Such separation helps to build very dynamic network infrastructures with centralized consistent management. Detailed description of SDN and OpenFlow as well as their relevance to SmartenIT are provided in the deliverable document D3.1 [56].
Page 34 of 87
Version 1.1

Public
4.2.9 Summary This section summarizes the lower layer traffic management solutions described in the sections 4.2.1 to 4.2.8. The IntServ approach uses resource reservation along the path of a flow. Once a flow is set up, it can be used with consistent QoS until it is not needed anymore. There might be situations where the desired or required QoS cannot be guaranteed. So it can happen that, a call for example, cannot be placed because not enough resources are available. DiffServ uses coarse classes in order to prioritize critical traffic such as VoIP. Packets are classified using the IP differentiated services field. Classification and prioritization solutions do not guarantee a certain level of QoS, if they are not combined with a strict load control for prioritized classes. MPLS networks enable to set up and monitor source-to-destination paths for traffic demands between edge routers in an MPLS network. These paths can be configured by the operator or dynamically using Label Distribution Protocol (LDP) or RSVP. MPLS allows to route traffic through a network independent of protocols or content. The MPLS-TE extension provides traffic engineering tools which allow among others - for better load balancing of different links and switching based on link characteristics such as delay or jitter. In contrast to pure IP networks, MPLS makes the traffic demand matrix available through standard LSP statistics, as the basic information required by ISPs for network planning and optimization. Self-Organizing Networks (SON) as standardized by 3GPP provides distributed network management functionality such as decentralized monitoring and distributed information aggregation and evaluation as well as functionality for network size estimation, topology discovery as well as searching. OpenFlow is a specification for communication between the infrastructure and the control layer in Software Defined Networks (SDN).
4.3
Inter-Layer and Application Layer
Inter-Layer traffic management solutions try to align application traffic to the underlying network infrastructure. The application layer traffic management solutions focus on layers above four in the OSI model. The following sections describe inter-layer and application layer traffic management solutions. While P2P traffic remains a challenge for ISPs, several solutions have been developed e.g., SmoothIT, P4P, and ALTO. Thus, the underlying mechanisms and concepts can be of great value for SmartenIT. 4.3.1 SmoothIT SmoothIT [103] is focused on techniques to align overlay and underlay networks. The need for such approaches stems from the fact that traffic produced by P2P networks is constantly rising but may take inefficient paths, if the overlay network is constructed unaware of the physical underlay. Besides its highly economic [29] and also implementation driven [102], the decentralized and incentive driven approach make the work of SmoothIT highly relevant for SmartenIT. In order to harmonize overlay and underlay networks, peers can get information on where to get a resource from. This information is provided by the SmoothIT Information Service (SIS) [38], which is a distributed system that implements information flows between overlay and underlay
Version 1.1
Page 35 of 87

Public
networks. The SIS thereby is able to make locality recommendations, i.e., point to peers with the designated content that are physically closest, as shown in Figure 7. The information to be distributed among peers is extracted from the BGP. These BGP based locality recommendation called BGPLocality or just BGP-Loc [91] is the first of three major ETM mechanisms proposed by SmoothIT. As argued by SmoothIT, overlay users as well as underlay providers have incentive to feed the SIS with information, as physically closer content usually means better data rates, higher QoS, and less cost for the network. More general, SmoothIT takes socio-economic factors into account to design a tussle-proof architecture. In particular, it is aimed for a triple win situation, which can be described as an outcome where all three major stakeholders profit. Two of these stakeholders have been already mentioned in Section 3.1 namely the ISPs and users. The third major stakeholder is the overlay provider, who is a content distributor, which is commercially benefitting from the overlay. As these stakeholders have different and in many scenarios conflicting goals, SmoothIT tries to design the architecture, such that it creates incentives for (honest) participation for all three. To further ease adoption, additional requirements have been taken into account: first, two user modes are provide, where one supports anonymity (which is often desirable for users in content sharing scenarios) and the other one allows for premium services. Second, inter-domain support is implemented to allow neighboring domains to cooperate (cf. inter-ALTO), with could for example ease selfish ISP behavior such as hot potato routing.
ISP B
ISP A
SIS
Transit
ISP D
SIS
Peering P P P P
ISP C
SIS P P P
Peer / Overlay application Overlay traffic SmoothIT Information Service (SIS)
Figure 7: SmoothIT Information Service Overview. The SIS also allows ISPs (underlay providers) to determine reasonable locations for the insertion of (ISP-owned) peers, which are machines with abundant resources, managed and controlled by the ISP. They held in the seeding phase of content, by acting as a transparent, non-intercepting cache. Therefore they also run the overlay protocol with minor modifications and employ further mechanisms to increase their effectiveness. In this way the ISP is granted the possibility to provide local caches for frequently accessed content resulting in a reduction of inter-domain traffic and an increase of user satisfaction. This insertion of ISP-owned Peers [85] is the second major ETM mechanisms proposed by SmoothIT. Instead of inserting own peers to the network, the SIS also allows ISPs to
Page 36 of 87
Version 1.1

Public
promote more cooperative behavior among overlay peers. In particular, if peers stick to the SIS recommendations and therefore help to increase locality of traffic, i.e., help to keep it inside the ISPs domain, the ISP may increase the peers bandwidth, in order to boost this locality effect and at the same time reward peers for their cooperative behavior. This promotion of Highly Active Peers (HAPs) [90] is the third major ETM mechanism proposed by SmoothIT. While such peers that produce a lot of traffic are usually not welcome by ISPs, the latter can now deploy the knowledge provided by the SIS to actively increase the bandwidth of those peers and thereby again reduce inter-domain traffic and increase user experience [84]. 4.3.2 P4P P4P [118] describes a protocol to better utilize bandwidth and to keep traffic local within an ISP. P4P introduces a new service called iTracker, which contains information about the network configuration of an ISP. The local peers should be preferred as they typically offer better performance and/or are cheaper for an ISP than other peers. Since P4P does not dictate the exact method for finding local peers, several methods are possible: A P2P client that support P4P uses the network information from the iTracker and select local peers that were received from a BitTorrent tracker. The BitTorrent and iTracker run independently. Another method is when a BitTorrent tracker implements the iTracker protocol and can make a peer selection on its own. With this, a peer does not need to query the tracker multiple times, but in the worst case for each peer a new iTracker has to be queried by the tracker. The third method is that the iTracker of the ISP becomes the tracker and serves local peers. With this method the ISP does not need to reveal its network configuration.
The authors in [118] came to the conclusion that P4P can improve the completion time and link utilization by 50-70%, although such a high optimization potential depends on the network topology and other optimization technique being applied on the network infrastructure level. They also mentioned that P4P is robust with respect to different bandwidth and network link capacities of peers. The authors in [52] looked at traffic engineering in the application layer and network layer within the context of P4P and came to the following conclusions: that accurate monitoring is important on the network layer to trigger fast response to failures, adaptation to unexpected changes and to have the traffic matrix available for planning of upgrades on a long term time scale, that broadband access networks undergo a steady upgrade process to cope with traffic growth where load balancing with re-optimization of traffic paths has to flexibly adapt to every change in order to reduce overprovisioning including corresponding invest and energy consumption, that large CDN and P2P networks can establish their own traffic optimization for content distributed on the overlay by selecting sources with shortest transport paths and in addition with regard to load balancing, that cross layer coordinating between network and application layer traffic engineering is needed in order to avoid mutual information deficits about source
Page 37 of 87
Version 1.1

Public
and transport bottlenecks and contrary path redirection procedures as a worst case scenario. 4.3.3 ALTO The Application Layer Traffic Optimization (ALTO) problem can be described as the problem to align overlay and underlay networks [95] and is therefore similar to problems as for example addressed by SmoothIT. The IETF has formed an ALTO working group (ALTO WG, [59]) for standardizing a protocol to enable P2P applications to obtain information about network layer topology. This is important to tackle the ALTO problem, because endpoints have to select peers but usually have no knowledge of the network. The interface defined by the ALTO WG enables a peer selection optimization service. A peer p can submit a set of peers to this interface and the interface returns an order of the peers in this list, which represents their feasibility for the exchange data with p. For this optimal peer selection, several different network metrics or combinations of these may be used while also the type of traffic to be exchanged can be taken into account. The network information necessary to make reasonable peer selections may be fed to the ALTO service by different stakeholders, as, for example, ISPs, as these know the network topology. However, also communities of non-commercial stakeholders, that run distributed algorithms to retrieve topological information, may provide input. The basic ALTO deployment scenario is shown in Figure 8. As shown here, a peer logically located in the application (overlay) topology deploys the ALTO service to receive information about two other peers that both hold the same resource. The ALTO service then provides ALTO guidance information to the requesting peer, by deploying information about the physical (underlay) Topology.
Figure 8: The Basic ALTO Deployment Scenario. (Source: [96]) ALTO acknowledges several use cases such as file-sharing scenarios (large choice of data sources, distributed video streaming, DHTs), mirror selection, and real-time
Page 38 of 87
Version 1.1

Public
communications (selection of closest media relay selection for NAT traversal), to name just a few [49]. Problems that the ALTO architecture has to face are listed in [96]. For example the ALTO server selection, i.e., how should a peer select the ALTO server that has the best suited information for it, is an inherent problem. Also problems, such as that peers do not want to disclose a list of their potential peers to ALTO servers arise. Similarly, ISPs may be reluctant to feed the ALTO servers with information, as it might reveal information about their interior network topology, routing policies, or business relationship with neighboring ASs. This problem becomes especially relevant, when ALTO servers of different ISPs communicate which each oth er, to optimize the information provided by the ALTO system across different autonomous systems. Such inter ALTO optimization is discussed in the next section. 4.3.4 Inter-ALTO Overlay traffic management enabled by ALTO service uses optimization based on information available at the Internet Service Providers (ISP) domain, i.e., an Autonomous System (AS) [95]. Information on the AS internal topology and some routing information obtained from the global Internet (the BGP routing tables) may be used for the overlay traffic management procedures. The data transfer cost can be also incorporated. The ALTO protocol itself is used for communication between ALTO servers and ALTO software components at client side. However, locally available information may be insufficient for effective traffic management. Some information that can be used for the better traffic management, is not available in the local AS and must be obtained from outside, i.e., from a remote AS. It was a motivation for considering information exchange between remote ALTO servers operated by different ISPs. It is assumed that those ISPs collaborate and agreed to exchange some useful information. The inter-ALTO protocol is may be used for information exchange between ALTO servers [32], [33]. Among motivations for implementing inter-ALTO protocol the following were identified [33]: Route Asymmetry in the global network. The communication between two ASes does not need to follow the same path in the upstream and downstream direction. As a result, upstream and donwstream paths may differ in the number of hops, ingress and egress node etc. BGP routing information available in the AS identifies only the upstream path. Many ASes operated by a single ISP. Current ALTO specification allows for deployment of independent ALTO servers in each AS. The overlay traffic management performed by the ALTO server is restricted to a single AS since cost maps have a local meaning. An ISP operating a multi-AS network may be interested in managing the traffic in the whole administrative domain in a consistent and coordinated manner. Remote ISP's Preference and coordination of ISPs' Policies. If ISPs agree on cooperation, they may exchange some preference parameters that may be taken into account by the second party in traffic management algorithm. Operators may have an incentive to coordinate their overlay traffic management strategies.to decrease transfer costs on inter-AS links or improve quality experienced by application users, i.e., This way, operators may avoid contradictory strategies resulting in inefficiency of traffic management.
Looking from the SmartenIT project perspective, such an information exchange operated by different ISPs may be useful for a more efficient traffic management. The optimization
Version 1.1
Page 39 of 87

Public
may take into account a content location, energy consumption related to content transfer in the network as well as QoS and QoE awareness. Collaboration between ISPs may enable a more efficient cooperation with cloud providers; data center operators and, in general, better overlay application traffic management. Also social information available in one domain may be useful for traffic optimization in the other. Additionally, such cooperation may be useful to indirectly influence overlay providers decisions. For example, as presented on Figure 9, ISP-2 having an agreement with cloud provider 3 may take into account information provided by ISP-1 which collaborate with ISP-2 but not have direct agreement with Cloud provider 3. The result of optimization algorithm may be beneficial for both collaborating ISPs and cloud provider.
Figure 9: The usage of ALTO and inter-ALTO protocol in a multi-AS environment. 4.3.5 CDNI The IETF started a working group on CDN interconnection (CDNI) in June 2011. The interconnection of separately administered CDNs is considered for support of end-to-end delivery from content service providers (CSPs) through multiple CDNs to end users via their respective user agents. The CDNI goal and milestone plan includes four informational documents on the problem statement, use cases, the framework and requirements as well as five specifications of interfaces in the proposed standards track o for the request routing and redirection,
Page 40 of 87
Version 1.1

Public
o for logging, control and metadata distribution and o for the request routing/footprint and capabilities advertisement. After about two years of activity, the CDNI working group has issued two informational standard documents RFC 6707 [78] on the CDNI problem statement and RFC 6770 [12] on use cases for CDNI
Moreover, four documents have been adopted as CDNI working group drafts to be currently worked out towards RFC status on the framework, the requirements, on metadata and on logging. There are about two dozen drafts by individual proposers brought into consideration for CDNI work, whose adoption is still open and to be discussed in the next steps. The main problem statement sees a lack of standards or open specifications to facilitate CDN interconnection for support of content delivery between the content provider and the requesting user. The use cases include Resource efficient dimensioning, load balancing and failure recovery between CDNs: While CDN support can essentially reduce the risk of bottlenecks at a single web site, since it has distributed network and server capacity available for many sites, the resources may still be overloaded in case of flash crowds or failures. Small CDNs can profit most from federations making a larger infrastructure available in such cases. Improved third party content handling by large network providers: Large network providers who have established own CDN and data center structures on their network can improve traffic management, resource efficiency, and QoS by standardized interworking and with global CDNs. Footprint extension: Therefore a CDN interrelates with downstream CDNs in order extend its coverage. Robustness against denial-of-service attacks Enhancement of limited CDN functions and capabilities to be outsourced to another CDN, e.g., for special support of security, QoS, or new technologies. Enforcement of policies demanded by the content service provider over several CDNs.
Among the main requirements, CDNI has to work without changes to the user agents and servers of content provisioning systems and shall reuse existing protocols. The framework draft includes a reference model, an overview on operations, DNS and HTTP redirection modes, storing and removal of content. Main interfaces are described. The informational RFCs and drafts issued by the CDNI working cover a wide scope of the problem space. The working group is expected to proceed towards the goals of its original charter although the required time frame may be extended beyond two years until the recharter. The CDNI work already provides a large repository of background information and on the other hand is still open for input.
Version 1.1
Page 41 of 87

Public
4.3.6 ABNO Closely related to ALTO is a recent proposal in the IETF, called ABNO [65]. This is a Path Computation Element (PCE)-based architecture for Application-Based Network Operations. PCE is an AS system component that is capable of determining a suitable route between a source and destination [36]. ABNO brings together and interfaces with several existing technologies for gathering information about the resources available in a network, for consideration of topologies and how those topologies map to underlying network resources, for requesting path computation, and for provisioning or reserving network resources. Thus, ABNO is a general framework, i.e., a toolbox of existing components enhanced with a few new elements. The key component within an ABNO is the Path Computation Element (PCE) [36], which can be used for computing paths. The ABNO use cases are: Inter-AS Connectivity, Multi-Layer Networking, Bandwidth Scheduling, Grooming and Regrooming1, Global Concurrent Optimization, and Adaptive Network Planning. Its focus is in line with the SmartenIT focus, however the level of maturity of the ABNO architecture is still low since it is a very new proposal in the IETF (December 2012). 4.3.7 BitTorrent-based TE Mechanisms BitTorrent is one of if not the most popular P2P file sharing applications. BitTorrent is an overlay application for transferring files. Since BitTorrent traffic is a challenge for ISPs, several traffic management solutions have been proposed that can be of interest to SmartenIT. In the following, two mechanisms for traffic management mechanisms are discussed. The first is tit-for-tat which creates an incentive to upload content. The second is the Micro Transport Protocol (TP) which transmits the files in background without disturbing interactive application traffic such as VoIP. 4.3.7.1 Tit-For-Tat / Choking Algorithm BitTorrent applies its own traffic management mechanism [80]. Opposed to traditional traffic management, BitTorrent applies a variation of the tit-for-tat strategy which is called the choking algorithm [23], called regular unchoking, which the choking algorithm is part of the peer protocol [24] and is based on incentives rather than congestion. Tit-for-tat means give to get. Peers only download as long as they are simultaneously uploading. With the employment of tit-for-tat fundamental limitations of P2P networks, that peers are unwilling to provide if they do not receive, can be overcome. A peer in BitTorrent keeps connection with many other peers, the so called neighbors. For the connection of the two peers there are two states, which are chocked or not. If the peer chooses to choke a connection, it refuses to upload data. Leeching peers employ this tit-for-tat strategy, by monitoring the current connections and take a fixed amount of connections with the highest download rates to upload. This mechanism is known as Choking Algorithm and is repeated every 10 seconds. In addition to unchoke slots of leechers, every leecher also unchokes a peer from the local neighborhood every 30 seconds, even though those peers did not reciprocate before. This behavior is known as optimistic unchoking. It allows newly joined peers to bootstrap and find potentially good providers for a resource. Although this technique is regarded as a mechanism against free-riding, some strategic clients such as
1
This is a future ABNO use case (no details provided in the draft yet) which will cover the following scenarios: Nested LSPs, Packet Classification (IP flows into LSPs at edge routers), Bucket Stuffing, and IP Flows into ECMP Hash Bucket.
Page 42 of 87
Version 1.1

Public
BitThief [71] and the modified version of Enhanced CTorrent [99] has shown that BitTorrent is not capable of preventing free-riding behavior. 4.3.7.2 Micro Transport Protocol (TP) TP is a BitTorrent implementation of the Low Extra Delay Background Application Traffic (LEDBAT) protocol [97]. Both TP and LEDBAT do congestion control based on delay measurements instead of only packet loss, like the original TCP does. The overall goal of the TP [79] congestion control is to use one way buffer delay as the main congestion measurement, as well as packet loss, like TCP. The point is to avoid running with full send buffers whenever data is being sent. This is specifically a problem for DSL/Cable modems, where the send buffer in the modem often has room for multiple seconds worth of data. The ideal buffer utilization for TP (or any background traffic protocol) is to run at zero bytes buffer utilization, i.e., any other traffic can at any time send without being obstructed by background traffic clogging up the send buffer. In practice, the TP target delay is set to 100 milliseconds. Each socket aims to never see more than 100 milliseconds delay on the send link. If it does, it will throttle back. This effectively makes TP yield to any TCP traffic. This is achieved by including a high resolution timestamp in every packet that's sent over TP, and the receiving end calculates the difference between its own high resolution timer and the timestamp in the packet it received. This difference is then fed back to the original sender of the packet. This value is not meaningful as an absolute value. The clocks in the machines are most likely not synchronized, especially not down to microsecond resolution, and the time the packet is in transit is also included in the difference of these timestamps. However, the value is useful in comparison to previous values. Each socket keeps a sliding minimum of the lowest value for the last two minutes. This value is called base_delay, and is used as a baseline, the minimum delay between the hosts. When subtracting the base_delay from the timestamp difference in each packet you get a measurement of the current buffering delay on the socket. This measurement is called our_delay. It has a lot of noise it, but is used as the driver to determine whether to increase or decrease the send window which controls the send rate. 4.3.8 BitTorrent with social relations In [111] the authors collected 100,000 torrents from www.btmon.com, a popular BitTorrent torrent site. They further crawled Twitter pages to check whether these torrents are also shared in Twitter communities and thus divided the respective swarms into Twitter swarms and normal swarms. Furthermore, they passively monitored BitTorrent traffic from the outgoing switch of a local ISP and identified the torrents and peers which belong to the two sets. They incorporated a social network from these data by adding a peer relationship if two peers share at least one common torrent. They found that peers from Twitter swarms have more common torrents and have a higher clustering coefficient than normal peers. Moreover, online periods of users in Twitter-triggered swarms overlap much more. Thus the authors present a modified unchoking algorithm which selects some peers from social friends. In simulations they show that this new algorithm significantly decreases startup delay and download completion time of peer-to-peer file sharing (cf. Figure 10).
Version 1.1
Page 43 of 87

Public
Figure 10: Dowload completion time, startup delay, and download completion time (larger swarm) compared to the cumulative distribution function (CDF) of peers (Source: [111]) This approach can be interesting for SmartenIT as it uses information from a social network to improve an existing application. By taking into account social relations simulation results show that the application performs better. 4.3.9 RB-Tracker RB-Tracker [68] incorporates three mechanisms in a fully distributed system, which form an integrated traffic management approach for P2P services combined with content-aware distribution demands: (1) The identification of content that is popular and of interest to the user in order to replicate it to the local cache. (2) The identification of network status to determine a feasible time to replicate, which is an off-peak hour. (3) The identification of close peers to replicate from in order to avoid additional intra-domain traffic induced by replication.
Figure 11: Example of a Simplified Neighbor Set over Several Files (Source: [68]) Figure 11 shows an example of a neighbor set of peers; each letter represents a file being shared. Such a mesh structure can be exploited by RB-Tracker to gather information about files shared among neighbors. Current work on RB-Tracker is done in determining files to cache (1). An example algorithm which considers common interest and file popularity (1) is presented. Peer P1 collects file sets of its neighbors: {ACY}, {AX}, {ABYX}, {BX}, {BCY}, {CX} and for each file set the similarity is calculated by counting common files to its file set {ABC}: P2 = 2; P3 = 1; P4 = 2; P5 = 1; P6 = 2; P7 = 1. In the next step, new files from these file sets receive the similarity score calculated, multiple occurrences are added: Y = 2 + 2 + 2 = 6, X = 1 + 2 + 1 + 1 = 5. This shows that, even though X is more popular (shared by 4) than Y (shared by 3), Y is the better candidate to replicate,
Page 44 of 87
Version 1.1

Public
because it has a higher chance of being in the P1s interest. Further evaluations of additional recommendation schemes determine work in progress. An RB-Tracker peer envisions to use passive network measurement approaches (2) similar to LEDBAT, which is closely related to TP. Through adding a time stamp to messages sent between peers, a peer can guess the delay and build statistics. Thus, it can be determined, if a connection to a certain peer is busy. An increase of time between two packets can have two causes: (1) the link is congested or (2) the neighbor is busy. In both cases another provider should be found to replicate from. In order to reduce inter-domain traffic, RB-Tracker needs a metric for closeness like the SIS [38] can provide. However, RB-Tracker is a fully distributed system, and cannot rely on centralized service like the SIS. A peer in RB-Tracker decides, if it should replicate from a neighbor using a threshold of maximum AS hops. To calculate the AS hop distance vector, a trace route tool in combination with an IP to AS map is used. For fixed line peers such a hop distance vector has to be calculated only once, when two peers first meet. Evaluation of different threshold values determines work in progress. In a mobile scenario hop distance vectors have to update more regularly. RB-Tracker autonomously relocates content in order to reduce traffic peaks and interdomain traffic very much like a CDN. Therefore, RB-Tracker is an automatically configured P2P CDN, which shares similar concepts with NetStitcher and TailGate. Combining concepts from P2P systems and CDNs, RB-Tracker promises an improvement in automatic traffic management in the application layer. A larger set of further and extensive experiments are required to validate these claims under many additional considerations. 4.3.10 vIncent Traffic management with a reciprocal incentive such as Tit-for-Tat discriminates resource poor nodes in the network, as the possibilities to contribute limit the possibilities to benefit from the network. This is especially true for asymmetric link properties (e.g., DSL) and heterogeneous types of nodes: for mobile devices, reciprocation via some cellular uplink is far more expensive in terms of energy consumption and bandwidth than a pure download, whereas a wired user mainly cares for quality, while bandwidth and energy are subsidiary problems. Researchers have tried to cure these shortcomings by using taxation schemes. Those schemes treat nodes according to their resources, where poor nodes have to contribute less and rich nodes contribute more. However, these approaches have a serious flaw preventing practical applicability: a trusted entity such as a directory is needed for mapping IPs and available resources. If such a trusted entity does not exist, taxation is prone to attacks, as every node can forge a low-resource nodes identity.
Version 1.1
Page 45 of 87

Public
Figure 12: Topology of an incentive scheme supporting virtual nodes. The dashed, virtual links may have to be balanced any time, while the dashed links may be unbalanced. vINCENT [114] is going a different way. Instead of treating nodes according to their possibilities, vINCENT tries to raise the resources of all nodes to a comparable level. This is achieved by introducing virtual nodes in a reciprocal incentive scheme used for managing traffic. Each virtual node constitutes a representation of devices acting in the same interest, e.g., the smartphone and the router of a user in a Peer-to-Peer content distribution network, a DSL user supported by a cloud instance or even virtual machines in different data centers of one user in an inter-cloud scenario. Within the node, a load balancing algorithm is applied, where resource-rich nodes contribute to the system, while resource-poor nodes consume resources. Assuming the use case of Peer-to-Peer video streaming, a smartphone and the users router could be unified under on virtual node, where the router performs the upload of video segments to the network, while the smartphone downloads only (see also Section 4.3.19). 4.3.11 NetStitcher Large datacenter operators incorporate sites at multiple locations, while they dimension their key resources according to the peak demand of the geographic area that each site covers. Though, the demand on each datacenter exhibits diurnal patterns correlated with the local time. Thus, the combination of peak load dimensioning with strong diurnal patterns leads to poor average utilization of resources over the day. To perform efficient traffic management of inter-data center traffic, in [67], an approach is proposed, called NetStitcher, which uses unutilized bandwidth across datacenters and backbone network exploiting also time-zone differences for bulk transfers, e.g., data replication among datacenters. In particular, NetStitcher employs a network of storage nodes to stitch together unutilized bandwidth, whenever and wherever it exists. Such storage nodes can be co-located with datacenters or expanded to other parts of the interdatacenter network as needed. NetStitcher gathers information about leftover resources and uses a clever store-andforward (SnF) algorithm to schedule data transfers, and adapt to resource fluctuations as depicted in Figure 13. Initially, the system splits bulk data into pieces which are then scheduled across space, i.e., geographical location, and long periods of time into the
Page 46 of 87
Version 1.1

Public
future exploiting time-zone differences between geographical locations, over multiple paths and multiple hops within a path. Scheduling is driven by predictions on the availability of leftover bandwidth at access and backbone links as well as storage constraints at storage relay nodes. It uses novel graph time expansions techniques in which some links represent bandwidth (carrying data across space), while others represent storage (carrying data across time). The system is also equipped with mechanisms for inferring the available future bandwidth and can adapt to estimation errors and failures.
Figure 13: A source datacenter uses available bandwidth to perform bulk backup to sink datacenter. (Source: [67]) An example which motivates the need for multipath and multi-hop SnF scheduling is based on the topology depicted in Figure 14. The authors assume that a datacenter in New York wants to back up its data to Palo Alto. Due to the different load and thus storage availability in the two datacenters, direct transfer of the data between them may not be feasible in a common time window. However, taking advantage of the availability of intermediate storage nodes and the available capacity of the backbone links over different time zones, this can be feasible if the intermediate datacenters/storage nodes of Boston, Chicago, Phoenix, Denver and Seattle are used, as depicted in Figure 14. Specifically, the aim is to maximize the volume of data that a datacenter in New York can back-up to another one in Palo Alto within 24 hours, assuming that datacenters have a 3 hour time window early in the morning (e.g., 3-6 am.) for performing such backups. Note that these datacenters may be in general served by multiple Edge ISPs; their interconnection is possible due to the Transit ISPs that sell to the Edge ISPs transit (global connectivity) network service; The transit service is seamless to the datacenters and the end customer who is purchasing Internet access from the Edge ISP.
Version 1.1
Page 47 of 87

Public
Figure 14: NetStitcher. (Source: [67]) NetStitcher is of interest to SmartenIT as it introduces a novel approach of scheduling content replications across both time and space to address the inter-data center scenario. Additionally, apart from bulk data transfers, it could be extended to address also simpler scenarios such as the communication of two data centers for the exchange of data needed to perform computing operations over massive datasets (e.g., using a medical data database in the cloud). Another possible extension of this approach is also to take into account energy efficiency as a constraint; e.g., to try to optimize data transfers across space by aiming to simultaneously minimize the number of data centers participating in the transfer relay, or by minimizing the time window during which they are active. 4.3.12 TailGate Distributing long-tail content is an inherently difficult task due to the low amortization of bandwidth transfer costs as such content has limited number of views. CDNs find it economically infeasible to deal with such content, while P2P systems suffer from peer/seeder shortage and meeting bandwidth or quality of experience (QoE) constraints. Two recent trends are making this problem harder. First, the increasing popularity of usergenerated content (UGC) and online social networks (OSNs) create and reinforce such popularity distributions. Second, the recent trend of geo-replicating content across multiple points-of-presence (PoPs) spread around the world, done for improving QoE for users and for redundancy reasons, can lead to unnecessary bandwidth costs. In [108], the authors propose TailGate which derives and uses social information and meta-information derived from OSNs, such as social relationships, regularities in read access patterns, and time-zone differences for predicting where and when the content will likely be consumed, in order to push the content where-ever before it is needed. Thus, exploiting the derived social information, long-tail content is selectively distributed across globally spread PoPs, while lowering bandwidth costs and improving QoE. In particular, th bandwidth costs are minimized under peak based pricing schemes (95 percentile), but is also beneficial for flat rate schemes. For the analysis of TailGate, the authors considered the scenario depicted in Figure 15. Specifically, they consider an online video delivery service with users across the world, operated on a geo-diverse system comprising multiple PoPs distributed globally. Each of
Page 48 of 87
Version 1.1

Public
these interconnected PoPs handles content for geographically close users. In particular, when UGC is created, it is first uploaded to the geographically closest PoP, and then it can be distributed to other PoPs.
Figure 15: TailGate scenario (Source: [108]). TailGate is built around three notions that dictate the behavior of users. First, users follow strong diurnal patterns while accessing data. Second, there exist time-zone differences between the PoPs in a geo-diverse system. Third, the social graph obtained by crawling Twitter provides information on who will likely consume the content. Centrally in TailGate, there is a scheduling mechanism, which schedules content by exploiting time-zone differences (an idea which is similar to that employed also by NetStitcher described in Section 4.3.11) between PoPs trying to spread and flatten out the traffic caused by moving content. The scheduling scheme enforces an informed push scheme, i.e., the content is pushed to the relevant sites before it is likely accessed reducing the latency for the endusers, peaks and hence costs for the video delivery platform. Finally, TailGate does not consider storage constraints or deals with dynamic content like profile information. As aforementioned, TailGate employs a scheduling algorithm similar to that of NetStitcher. However, TailGate employs social information to predict where content will be requested and addresses UGC, i.e., long tail content, while, on the other hand, NetStitcher handles bulk data traffic replicated between data centers of an operator. Nevertheless, TailGate is also of interest to SmartenIT as it is related to the scenario of content delivery exploiting social-information, which is one of the key scenarios addressed by the project. Additionally, it could be extended, in a SmartenIT context to address also energy efficiency, e.g., by aiming to minimize the number of data centers participating in the content replication, or the time that they remain active. Moreover, other types of traffic can be address, e.g., traffic generated by online storage applications for collaboration among work partners can be managed considering social information from business social networks such as LinkedIn. 4.3.13 Angels in the Cloud Existing peer-assisted content distribution systems usually utilize a clients upload capacity only to the extent that other swarming clients are able and request to utilize it. Indeed, most mechanisms proposed and implemented for peer selection do not primarily aim to maximize the utility of a swarms aggregate capacity, but rather focus on other goals, including dealing with freeriding using rational tit-for-tat exchanges [23], or reducing interISP traffic using geographic (or topological) locality [118], [22]. These approaches are well
Version 1.1
Page 49 of 87

Public
justied when peer assisted content distribution is not under the control of a single authority, or do not cater to a common overarching socially optimal objecti ve. In [106], the authors claim that for many emerging applications and settings, either or both of these conditions may not hold. In particular, when content providers employ peerassisted delivery mechanisms, they are in fact acting as a single authority that choreographs the operation of all clients involved, using specially-developed software clients. Moreover, for many emerging cooperative applications, optimizing the performance of individual clients may not be a rational objective as it may lead to suboptimal group performance. Thus, motivated by the above observations, the authors tackle the problem of peerassisted content delivery in a setting where the content provider is assumed to choreograph the participation of all clients in a swarm, and/or the objective of the content delivery system is to minimize the Minimum Distribution Time (MDT), i.e., the total time it takes to distribute a common piece of content to all clients in the swarm. In particular, they propose the use of helper nodes called Angels, equipped with storage and bandwidth resources, which are deployed on-demand to alleviate the swarms upload capacity bottleneck. Angels are not clients, in the sense that they are not interested in downloading all parts of the content file, rather they use the upload capacity to cache and forward parts of the file to other peers. Moreover, in their proposed architecture called CloudAngels, the authors propose the instantiation of a set of Virtual Machines (VMs) to act as angels, while the aggregate capacity of the deployed angels would depend on the content providers stated objectives e.g., how much uplink bandwidth to add to the swarm to achieve an optimal MDT, or to ensure that MDT is below a certain preset threshold. Furthermore, in [106], a novel swarming strategy is proposed to orchestrate the angels and to organize the content delivery, which is called Group Tree (GT). The GT strategy works in two phases as in Figure 16. Specifically, in Phase 1, the swarm is organized into k binary trees. One of the trees is dedicated to angels, e.g., the blue nodes, whereas the other trees are populated by clients. Clients are matched up and assigned to trees in such a way that all tree participants have similar upload capacities. Each tree is assigned a segment of the le that is proportional in its size to the nominal, individual upload capacity of nodes (clients or angels) in the tree. The seeder sends the segments in chunks to the root of each tree, noting that the tree nodes operate in a pipelined fashion: Once a client/angel receives a packet, it forwards it to its children in the tree. Then, in Phase 2, sets of k nodes (from the k different trees) each having received one of the k different segments of the le, form a clique for swarming purposes, e.g., a clique of four including one green, one yellow, one red and one blue node. By construction, each clique would include one angel, i.e., the blue node. In this phase, the operation of angels and clients is different; namely, each angel sends data to clients in its clique without receiving any data from these clients, thus saving the precious upload capacity of clients
Page 50 of 87
Version 1.1

Public
Figure 16: Group Tree strategy. (Source: [106]) To evaluate the GT strategy, the authors compared it to a random swarming strategy, which does not employ any intelligence in peer or piece selection. Additionally, the local rarest first piece selection strategy was considered, i.e., selection of rarest piece among local neighbors, a global rarest first, i.e., selection of rarest piece among all known peers, and a fair peer selection strategy, which tries to get each client a fair-share of the networks upload capacity. Evaluation results showed that the GT strategy outperforms all other strategies, scales well, and operates near the optimal, theoretical MDT bound. Additionally, evaluation ndings suggested that coordinated swarming strategies, which coordinate both piece and peer selection, such as GT result in much better performance than strategies that focus on either piece or peer selection or those that consider both but in an uncoordinated fashion. According to [106], all nodes participating in the cloud are assumed to cooperate, i.e., they can be actively choreographed by the content provider in order to reduce the MDT. This is a valid assumption as long as all nodes belong to the same entity; otherwise, the peers exhibit selfish behavior and their cooperation must be pursued by providing incentives to all nodes to collaborate, and specifically by improving their download time individually (not only the MDT). In a SmartenIT context, the angels approach could be extended to address also energy efficiency, i.e., instantiation of VMs, (angels), and GT algorithm should be performed also aiming to minimize the number of VMs active at each time slot. 4.3.14 SocialTube Video has been an increasingly popular application which is today highly related to users activity in Online Social Networks (OSNs). Due to the fact that the traditional client/server architecture deployed in Video-on-Demand (VoD) systems is costly in terms of bandwidth and not scalable, P2P-based video sharing has emerged as a solution for on-demand video streaming (e.g., GridCast [51] and Vanderbilt VoD [20]). With each peer contributing its bandwidth to serving others, the P2P architecture provides high scalability for large user base. However, so far mechanisms proposed to facilitate P2P VoD in OSNs are suboptimal, if not entirely inapplicable, since videos are visited and spread by the users friends through the Friend-of-Friend (FOF) relationship. Additionally, unlike stand-alone VoD systems that provide system-wide video searching and sharing, where a peer can access any other peers content, VoD systems triggered through OSNs do not provide video search functionality.
Version 1.1
Page 51 of 87

Public
In order to design a P2P VoD system that exploits social information, the authors of [70] crawled data from a large set of more than 1,000,000 users and 2,500 videos on Facebook. They observed that in Facebook 90% of the viewers of a video are within 2 hops in the video owners social network. Also, on average, in a users viewer grou p, 25% of viewer watched all, 33% of viewers watched 80%, and all viewers watched 20% of the users videos. In addition, they observed that viewers that watch almost all of a users videos (followers) usually are 1-hop friends of the user, while most of other viewers (nonfollowers) are 1-hop or 2-hop friends of the user. Then, to explore the correlation between user interests and video viewing patterns they classify videos in 19 interest groups, and observed that users watch the videos of their interests and each user generally has less than 4 video interests. Thus, they concluded that followers are primarily driven by social relationship to watch videos, while non-followers are driven mainly by interest. Based on their observations, i.e., users in an OSN watch videos driven by both the friendship relation and video content, they proposed in [70], a novel peer-assisted video sharing system, named SocialTube, which explores and exploits social relationships, interest similarity, and physical location between peers in OSNs. Specifically, SocialTube incorporates three algorithms: a social network (SN)-based P2P overlay construction algorithm that clusters peers based on their social relationships and interests, a social network-based chunk prefetch algorithm to increase the video prefetch accuracy to minimize video playback startup delay, and a buffer management algorithm. SocialTube pre-defines two thresholds, Th and Tl, if the percent value of a viewer is larger than Th, then the viewer is considered to be a follower, while when the percent value is between Tl and Th, the viewer is considered a non-follower. The social network-based P2P overlay has hierarchical structure that connects a source node with its followers, and connected the followers with other non-followers. The source pushes the first chunk of each new video to its followers where it is cached because there is high probability that it will be requested to be watched, since followers watch almost all videos of the source. Further, non-followers, which are sharing the same interest, are grouped into an interest cluster for video sharing, and are called interest-cluster-peers. Figure 17 illustrates SocialTubes overlay structure, i.e., a group of source, followers, and interest-clusterpeers, which is called a swarm. Moreover, in order to reduce the video startup latency, the social network-based prefetching algorithm is employed. This algorithm dictates that when a source node uploads a new video to a centralized video server, the source also pushes the prefix, i.e., the first chunk, of the video to its followers, as well as to the interest-cluster-peers in the interest clusters matching the content of the video. The prefix receivers store the prefix in their cache. Those interest-cluster-peers and followers who are not online when the source node pushes the prefix will automatically receive it from the source node or the server once they come online. After the source node leaves, the responsibility to push the prefix falls to the server. Since these followers and interest-cluster-peers are very likely to watch the video, the cached prefixes have a high probability of being used. Once the nodes request the videos, the locally stored prefix can be played immediately without delay.
Page 52 of 87
Version 1.1

Public
Figure 17: SocialTubes structure. (Source: [70]) The SocialTube approach is of interest to SmartenIT as it explicitly addresses the issues of using social information to perform efficient content delivery. Additionally, it is an interesting approach as it combines social information, and users interests and physical location to employ content prefetching. Another important aspect is the fact that SocialTube addresses YouTube traffic; as YouTube is a proprietary VoD platform, the potential of intervention in such a proprietary system is of critical importance. Although, SocialTube proves that YouTube traffic can indeed be handled efficiently, it does not clearly address the need for collaboration with the VoD platform. 4.3.15 Webcloud OSN content is different from more traditional web content, as it is more likely to be generated at the edge of the network, to be exchanged within a local geographic region and poses a more even popularity distribution with fewer popular objects. Unfortunately, most OSNs still use largely centralized approaches to distribute content (e.g., CDNs and web caches), resulting in lower performance due to the different workload. A number of peer-to-peer (P2P) systems for implementing OSNs or distributing content have been proposed. However, these systems either (a) are built as separate (non-web) systems or (b) require plug-ins, both of which drastically limit applicability. In [122], the authors examined crawled data from Facebook and observed that a significant fraction of Internet traffic contain content that is created at the edge of the network, i.e., UGC. Moreover, they observed that users are in general significantly more interested in the content that is uploaded by their friends and friends-of-friends (80% of the photos viewed in Flickr were found by browsing the social network), while traffic local to a region is produced and consumed mostly in the same region, which is contrary to the case of traditional web content. Finally, they identified that the exchange of content happens mostly between OSN friends; in particular almost 30% of comments on a photo were made by friends of the uploader and almost 90% by friends or friends of friends of the uploader. Furthermore, according to [122], CDNs are not well suited for the distribution of such UGC traffic in OSNs. In particular, the authors argue that while caching the most popular 10% of traditional content would allow to satisfy at least half of all requests, this caching technique would perform significantly worst for content with a more even popularity distribution.
Version 1.1
Page 53 of 87

Public
Therefore, they propose WebCloud, a content distribution system for OSNs that works by repurposing client web browsers to help serve content to others, and which tries to serve the request from one of that users friends browsers, instead of from the OSN d irectly. WebCloud is designed to be deployed by a web site, such as the provider of an OSN, to be compatible with the web browsers (no plug-ins) of today and to serve as a cache for popular content. The authors claim that WebCloud trying to keep the content exchange between two users within the same ISP and geographic region, to reduce both OSNs and the ISPs costs. WebCloud emulates direct browser-to-browser communication by introducing middleboxes called redirector proxies (Figure 18). The proxy determines if any other online local user has the requested content and if so, fetches the content from that users browser and transmits it to the requestor. Should no local user have the co ntent, the browser fetches the content from the OSN.
Figure 18: Content sharing in WebCloud. (Source: [122]) WebCloud is agnostic to the type of content that is exchanged, however requires that content be named using hashes. The OSN includes the WebCloud javascript library for communicating (WebSockets or XMLHTTPRequests) with the proxy, and storing and serving local content (LocalStorage API). Each redirector proxy maintains connections to all of the OSNs online clients that are located within the same geographic region and ISP. This list is kept up-to-date as clients join and leave. Also, the proxy keeps a list of the content that each client stores in LocalStorage. An optional local cache can be included in the redirector proxy to help content exchange, as depicted in Figure 19.
Figure 19: A state redirector proxy. (Source: [122]) The proposed architecture is evaluated by microbenchmarks, a small-scale deployment, and large-scale Facebook simulations. Also a proof-of-concept iOS app is implemented. These evaluations show that WebCloud is even faster than standard content delivery, if
Page 54 of 87
Version 1.1

Public
the middleboxes have the designated content cached. WebCloud can be summarized as a "novel use of established web technologies to allow clients to help serve content to other clients, keeping the content exchange local and providing savings for both the site OSN provider and the ISP". WebCloud is a solution that can be applied by the OSN provider, e.g., Facebook, and is having clearly impact on both OSN's and ISP's performance. WebCloud is of interest to SmartenIT, as it addresses the issue of exploiting social information to perform efficient content delivery. 4.3.16 Microblog-based Predictions Microblogging, which includes users exchanging short messages with other users and following content that they are interested in such as video, photos, and songs, shared by others, is becoming increasingly popular by todays Internet users. Additionally, video sharing is a prominent example of content sharing that takes place on a microblogging site. Therefore, similar to TailGate, the authors of [112] explore: (a) the connections between the patterns of microblog exchanges, and (b) the popularity of videos and use propagation patterns of microblogs to guide proactive service deployment of video sharing system. The potential benefits of the exploitation of content sharing patterns are two-folded: First, a content sharing site typically has no information on how video views propagate among its users, while a view propagation model could enable more effective view prediction; second, the exchanges of video links in a microblogging system typically happen earlier than the actually video view on a video sharing site, and the time lag between both events can allow more timely, proactive deployment of videos. The authors of [112] collected 29.000 traces from Youku, i.e., a video sharing platform, and Weido, i.e., a microblogging system, both deployed and used in China, and they performed extensive measurements in Weibo traces. Through these measurements they collected information such as the number of users that introduce a video in a timeslot (root user), the number of users who after reading a microblog containing the video link, reshare the link to their followers in a timeslot (re-share users), the number of followers of those root and re-share users, who can see the microblogs and may view the video on Youku in a timeslot (influenced users), and finally, the geographic distribution of Weibo users. Consequently, the authors investigated the predictability of future Youku view numbers using historical Weibo measurements, as well as the connection between future geographic distribution of viewers and their historical distribution. As reported in [112], they observed that the number of root, re-share and influenced users at time slot T is related to the number of the views at time slot T+1. The more root users a video has, the more likely the video can attract more views in the future. Similarly, when more users are re-sharing a link to their followers, the more views can be expected on Youku for that specific video. Moreover, they investigated the geographic distribution of Weibo users publishing a microblog containing a link to the video, and used it to estimate the distribution of all viewers in Youku. Specifically, they observed that the distribution over different regions is highly skewed: more than 40% of the viewers of the videos reside in Beijing and Shanghai regions, i.e., highly urbanized regions, while very small fractions of viewers are from the
Version 1.1
Page 55 of 87

Public
overseas. Furthermore, they found that future geographic distribution can be predicted by historical distributions in a neural network model. Based on the derived information, they trained neural network models to predict the number and distribution of views of each video. They proposed to train two types of neural networks, one for the prediction of the total number of views of a video and one for forecasting the geographic distribution of users. The neural networks were trained for standard time window, frequency and weight values. In order to evaluate the accuracy of neural network models, the authors used 6,000 samples extracted from the same set of traces. Then, they compared the accuracy of the trained neural networks with that of a linear regression approach. Linear regression involves prediction of the future number of views (geographic distribution) on Youku based learning of the historical numbers of views (geographic distributions) in the past M time slots, using mean least-square line fitting. Figure 20 depicts evaluation results which show that neural network models achieve superior prediction accuracy than that achieved by the linear regression approach. In addition, the number of views and geographic distribution of old videos, i.e., videos that have been uploaded for longer time, can be better forecasted, than those of the new videos, i.e., videos that have only very recently been uploaded, due to the fewer number of features in the learning framework of new videos.
Figure 20: Comparison of predictions obtained by the trained neural network to predictions obtained by linear regression. (Source: [112]) As exploitation of social awareness for efficient content delivery is one of the four interesting scenarios identified in deliverable D1.1 [83], the approach proposed in [112] is interesting to SmartenIT with respect to the type of information extracted by the microblogging site and the way it is utilized by means of training a neural network to later perform predictions on future video views on a video streaming platform. 4.3.17 CDN and Geo-information from Online Social Networks In [93] the authors want to predict geographical access patterns from social networks. They focus on a scenario in which a limited number of caching locations has to be selected from a limited number of available locations. The authors describe the classical location based placement in which the content is placed in the regions with most previous access. They propose social cascade prediction in which the content is placed in the regions with the highest number of potential future users. These potential future users are the social network friends of previous users as they participate in the social cascade.
Page 56 of 87
Version 1.1

Public
To evaluate their proposal they identify the affiliations of 20,000 Facebook profiles and cluster them into 10 regions. The user generated content shall be cached in 3 regions. In a simulation users access the content either by social cascade or by random access. The ratio is determined by parameter p which is the probability of social cascade access. They give an arbitrary cost function which gives remote access a 20 times higher cost to local access. If p=0.5, location based prediction is better for the first accesses but then social cascade prediction becomes more efficient. They show that in the end social cascade prediction is cheaper for all p larger than 0.25. In [94] the authors try to improve CDN performance by information from online social networks. The authors use a geo-social dataset from Twitter containing geographic location, follower list and tweets for more than 400,000 users. They analyzed this corpus of 334 million messages and extracted about 3 million messages containing a YouTube video link. They identify the social cascades for these video links and compute link distances and node locality for the involved users. By analyzing the social cascades they show the cascade size has a long-tail distribution. There are more than 60,000 cascades with only two users and a few cascades reaching up to hundreds of users. Moreover they illustrate the time delay between two consecutive tweets which is about 15min for 40% of the tweets, with around 10% having a delay of up to 2 minutes. This indicates that links can quickly spread over the social network leading to many potential views in a short time. The authors then compare three classical cache replacement strategies, namely Least Recently Used (LRU), Least Frequently Used (LFU) and a mixed LRU/LFU strategy in a CDN-model based on the old-fashioned CDN Limelight. They introduce the geosocial (sum of the node locality of all users that posted about a video) and geocascade (sum of the node locality of all users that participated in the videos social cascade(s), i.e., posting users and their followers) weight based on the Twitter dataset. They show by simulation that a larger cache size improves the performance. However, the performance increment is limited. Moreover a larger workload has a worse performance but differences between the strategies disappear with larger cache sizes as the large cache size dominates the performance. By weighing the classical cache replacement strategies with geosocial and geocascade measures the hit ratio improves. Again the benefit decreases as the cache size increases. From both weights, geocascade shows a better performance. As mentioned in Section 4.3.16, exploitation of social awareness for efficient content delivery is one of the four interesting scenarios identified in Deliverable D1.1 [83]. Thus, both approaches of extracting CDN and geo-information from information derived by OSNs are relevant for SmartenIT as they show how OSN information can be utilized to improve content delivery. The simulative results show the potential of the methods and have to be implemented and evaluated in a real scenario. 4.3.18 Cloud Caching Strategies The emerging of various cloud services have made content ubiquitously available for end users. The continuous growth of cloud usage poses challenges to traffic management inside the cloud. One solution to reduce traffic overhead and latency is cloud based caching.
Version 1.1
Page 57 of 87

Public
The authors in [21] propose a Cloud-based cooperative cache system for reducing execution times of data-intensive processes and reduce overprovisioning. The solution is exploiting the redundancy in cloud service requests during peak hours by the use of caching. Experiments show that cooperative caching of reusable content in clouds improves request serving performance. However, those benefits come at a cost. The main issue is the high node allocation due to cache size. Although the system adapts dynamically to the workload, it requires the most resources during peak times when resources are scarce. Relocation of cached content to another node, because of memory limits, is an expensive operation. Experiments have shown that this happens when request frequency is raising and caches get full. Finally, the proposed solution delivers a certain benefit in request response performance but requires more memory to operate. Depending on the characteristics of the load in a cloud, this solution improves the performance of the cloud.
Figure 21 System schematics of a hybrid cloud distribution system (Source: [13]) Hybrid content distribution systems feature edge nodes which are located at the border of a cloud network. Typically, content is cached at these edge nodes once a request is being served from the central server. The authors in [13] propose that these edge nodes can fetch content from other edge nodes instead of querying the central server. Furthermore, a load-aware hybrid caching policy is proposed and evaluated against more traditional policies which mainly consider the hit-ratio of content. Their findings state that selecting nodes which have a short request queue combined with either random or least-recentlyused, for lower complexity, cache adaption can greatly improve retrieval latency. 4.3.19 Nano Data Centers Most of the new overlay applications, which are highly popular among Internet users today, are served from a large number of collocated servers stacked together in one of multiple data center facilities around the world. This legacy hosting model is a classic example of the economies of scale, where homogeneous hosting environments allow for better resource optimization and management, while extensive use of virtualization technologies, i.e., clouds, provide an abstraction of dedicated platforms to developers.
Page 58 of 87
Version 1.1

Public
However, the current approach followed does not come at no cost; in particular, data centers are prone to: 1) over-provisioning as they are designed to meet peak demand while the average demand is lower, 2) high cost of heat dissipation as energy for cooling server farms is almost equal to energy spent for powering them, and 3) increased distance to end-users, which implies higher bandwidth demand so as to support certain services which implies even higher energy consumption by networking equipment. The authors of [109] address the aforementioned issues by proposing a distributed service platform, called Nano Data Centers or NaDa, based on tiny (i.e., nano) managed servers located at the edges of the network, i.e., users' premises. In NaDa, both the nano servers and access bandwidth to those servers are controlled and managed by a single entity, typically an ISP. The role of the nano servers can be played by ISP-owned devices like Triple-Play gateways and DSL/cable modems that sit behind standard broadband accesses. According to [109], such gateways can potentially form the core of the NaDa platform and, in theory, can host many of the Internet services hosted in today's data centers, including the increasing popularity video streaming services. NaDa follows a P2P philosophy, but is coordinated and managed by an ISP that installs and runs the gateways that act as nano servers, as well as the network that interconnects them. Due to its managed nature, NaDa avoids most of the shortcomings of classic unmanaged P2P. ISPs can easily implement NaDa by providing new customers with slightly over dimensioned gateways, whose extra storage and bandwidth resources would be used by NaDa to implement services like video hosting, all of which will be totally isolated from the end-user via virtualization technologies. The NaDa architecture, depicted in Figure 22, consists of: Gateways which provide storage, and bandwidth resources, whereas in the case of VoD service, they store full or partial replicas of video content objects, and provide uplink bandwidth to deliver these objects to other gateways. Additionally, a NaDa controller coordinates all VoD-related activities in NaDa, i.e., it monitors the availability and content possession of gateways, and answers requests for content by lists of gateways holding the desired content. Then, it is up to the requesting gateway to download movie parts from other gateways. Finally, content servers provide the content from legacy data centers or caches. They can belong to the entity that manages the NaDa platform, i.e., the ISP, or to content providers, whereas their primary role is to pre-load gateways in offline mode with content that they can subsequently re-distribute. Content servers can also serve content requests online if no gateway can treat the request.
Version 1.1
Page 59 of 87

Public
Figure 22: NaDa architecture. (Source: [109]) In order to evaluate power savings, the authors develop in [109] a specific model addressing the Power Usage Efficiency (PUE). The calculated savings by the NaDa approach come in three ways: First, through improved heat dissipation stemming from the distributed nature of NaDa which minimizes the need for cooling. Second, through traffic localization resulting from the co-location between NaDa and end users. Third, NaDa performs efficient energy use by running on gateways that are already powered up and utilized for content access or other services. Specifically, related to the third observation, the authors performed measurements of the energy consumed by a video server serving with bandwidth of a few hundreds of Mbps, and a home gateway serving with a bandwidth of a few tens of Mbps, under varying and increasing load. The evaluations showed that while the energy consumed by the video server increases as the traffic load is higher, the home gateway's consumption has an upper bound which is close to the energy consumed when the gateway is in idle state. Specifically, the authors showed that around 85% of the gateways are constantly online and adding additional storage does not increase the power consumption significantly. Although high performance servers are more energy efficient than consumer gateways with respect to the the bandwidth in the video streaming scenario, the consumer gateways are always powered and thus can be deducted from the equation. Their gateway consumed under high load 14.5 Watt while in idle mode it consumed 13.5 Watt, resulting in 1 Watt contributing to the energy usage. Having only 1 Watt in the equation makes the NaDas more energy efficient than high performance servers. The energy usage acquired through simulations and YouTube traces in Figure 23 shows that Youtube video streaming saves energy when NaDas are used. The authors concluded that NaDas are 20-30% more energy efficient in their video streaming scenario as with a traditional data center.
Page 60 of 87
Version 1.1

Public
Figure 23: Energy traces acquired through simulations for YouTube (Source: [109]) According to its authors, the NaDa architecture needs to deal with some issues, e.g., the limited upload bandwidth of the end-users due to asymmetric DSL lines which may result in deteriorating performance of video streaming service. Furthermore, incentives must be provided to end-users to adopt such enhanced gateways taking into account the extra cost, to share their upload bandwidth so as to serve other peers, and to carry the burden of the extra energy consumption by the gateway; thus, cooperation once again cannot be pre-assumed. The NaDa approach is interesting to SmartenIT, as it addresses one of the key goals; that of energy efficiency in data centers. A possible extension of the NaDa architecture could be to employ also social information and meta-information so at to perform content placement. 4.3.20 Summary Inter-Layer traffic management solutions aim at aligning overlay traffic to the underlying network infrastructure by providing necessary information to applications. SmoothIT, ALTO and Inter-ALTO are similar approaches which, although targeting mainly P2P networks can be relevant for SmartenIT as the traffic related problems are comparable. Different ALTO solutions have shown that they can significantly reduce P2P intra-domain traffic. ALTO systems do not actively manage traffic; they expose an interface to overlay applications serving some information about underlay properties. As broadband Internet access technologies are becoming commonplace, applications are increasingly relying on the Internet to fulfill their tasks. This results in higher demand and usage of bandwidth. While all distributed systems produce network traffic by definition, applications consuming or distributing multimedia content have a particularly high demand for bandwidth. P2P file sharing applications, online social networks, and cloud services are especially prominent with respect to a growing user base and traffic share. As a consequence, there is a need to manage this traffic effectively and economically. Caching is another mechanism that is frequently applied by overlay applications. Caching is effectively used on different levels: the server/cloud side, the ISP level, and the end user hosts. Cloud based caching strategies like TailGate or Cloud Angels aim at placing data physically closer to the consumer and therefore reduce back-bone traffic. ICNs place caches at routers of ISPs where resources are cached and redundant traffic is avoided. The challenge in ICNs is the storage requirements for caching in routers. Nano Data Centers cache content on end user machines to reduce load on the data center which is
Version 1.1
Page 61 of 87

Public
less energy efficient than using consumer devices. Social Tube follows a similar approach borrowed from P2P systems, where a consumer is also a provider for a resource and resources are stored for some time. RB-Tracker and SocialTube go one step further, by replicating pro-actively before a user has requested them, this way, the time of the downloading/replication process can be controlled by the application and traffic peaks might be avoided.
Page 62 of 87
Version 1.1

Public
5 Assessment of Traffic Management Solutions

Numerous traffic management solutions have been identified in Chapter 4. This chapter categorizes these traffic management solutions by looking at a broad range of different properties. The findings are summarized in Table 4 in Section 5.2 which constitutes the basis for the summary and conclusions provided in Chapter 6. Both Table 4 and Chapter 6 will serve as input for the tasks T2.2 and T2.3.
5.1
Categorization
The traffic management solutions identified in Chapter 4 can be categorized according to different characteristics. The first three categories interconnection agreements, lower and higher as well as inter-layer were already described in Chapter 4 and therefore are not separately addressed in this chapter. However, the overall table in Section 5.2 includes these categories. The following sections discuss in detail whether the traffic management solutions are suitable for use within a single Autonomous System (AS) or whether they can also be used between Autonomous Systems. Further sections discuss whether the traffic management solutions can be considered collaborative, energy efficient as well as whether they are socially aware or enhance resources. The last two sections elaborate on what time scale the traffic management solutions operate and whether they take the incentives of individual stakeholders into consideration. The chosen categories are vertical to the interconnection agreement, lower-, and higherlayer categories selected in Chapter 4 and therefore provide valuable insight by looking at the traffic management solutions from a different perspective. 5.1.1 Inter-/Intra-domain Solutions Traffic management solutions are classified with respect to their scope, i.e., whether they are applicable within a single networks administrative domain or it can be generally applied in multiple domains. The majority of traffic management solutions in the literature are targeted to the single-domain case. This is not surprising due to the fact that interdomain QoS has not emerged in the market. This is mostly due to the fact that so far the focus of the providers has been to establish a significant network coverage (footprint) and customer base and then capitalize on the on-net services. Traffic originated from other domains typically brings negative externalities in the form of delays and congestion. Since these flows belong to customers of another network, such inter-domain does not bring any immediate rewards to the network itself. This is why networks currently accept at the interdomain points only data and BGP information; they do not exchange any kind of signaling and IP packet headers are blackened once accepted in their own domain thus not allowing for any kind of resource reservation or preferential treatment. To overcome this, lately there have been some initiatives for promoting inter-domain collaboration. This applies to inter-domain overlay collaborative solutions (such as IPX), research projects (such as ETICS as described in D3.1 [56]) and standards (inter-domain extensions of MPLS-TE LSP solutions, inter-PCE architectures such as ALTO and ABNO). Currently there is no support for inter-domain SLA standards and interconnection agreements (peering and transit) are agnostic to inter-domain QoS. However there is an increasing interest also by carriers on such solutions due to the erosion of profit margins
Version 1.1
Page 63 of 87

Public
and in an attempt to provide assured quality services to more (i.e., off-net) customers, including content providers and hyper-giants2. QoS support between network and content providers has been addressed by several standardization bodies and research projects. On the IP layer, the Differentiated Services concept in principle can be applied in different interconnected domains. Therefore the network operators have to agree on similar QoS policies and classification schemes or a set of QoS classes has to be reserved for usage according to a common standardized strategy to be supported by each operator. But neither of both options seems to be commonly used. Standardization approaches for QoS interworking have been elaborated by the IPsphere forum, which started as a stand alone industry forum and has been integrated in the Tele-Management (TM-)Forum in 2010. In addition, the IP eXchange initiative of the GSM association [47] has specified an interconnect service to be offered by carriers on a competitive basis in a managed network at specific quality levels with traffic engineering. It is based on agreed technical specifications and consistent commercial models. It provides a range of technical and commercial features that enable business models including security features and bi- and multilateral connectivity. Main IP eXchange features are illustrated in Figure 24.
Figure 24: IP eXchange interconnection service framework. (Source: [47]) There are traffic management solutions a) whose scope is purely intra-domain (e.g., IntServ), b) others that are inter-domain-capable, i.e., can work over multiple domains but do not necessarily use explicitly inter-domain knowledge on their algorithms and protocols (e.g., SmoothIT) or require some extension/mapping across multiple domains (e.g., DiffServ), and finally c) traffic management solutions that are inter-domain-aware in the sense that are explicitly designed for the inter-domain scope and rely on information and functionality that must be provided over multiple domains (e.g., CDNI, inter-ALTO). Entries in Table 4 can be an x, which means the traffic management solutions work interdomain. Entries with no x (empty) denote traffic management solutions that work intra domain. 5.1.2 Collaborative Solutions Collaborative Solutions share the common characteristic that several entities reach a goal by means of collaboration. Examples of such entities in the scope of SmartenIT are: nodes in a distributed system, services in different domains, or peers in a P2P system. SmoothIT takes a collaborative solution to overlay traffic management, as the architectures central entity is the SmoothIT Information Service (SIS) which is a distributed system that exchanges information between ISPs and overlay applications,
2
IT giants like Apple, Amazon, Google, and Microsoft.
Page 64 of 87
Version 1.1

Public
e.g., peers. Furthermore the SIS servers in different network domains exchange information to support the collaboration between different ISPs. For similar reason also ALTO can be considered a collaborative approach. Also here, ALTO clients depend on ALTO servers that provide information. Furthermore, ALTO also allows for third-party ALTO queries, where ALTO clients find ALTO server suited for other ALTO clients. Similar to SmartenIT Inter-ALTO extends ALTO strengths cross-AS communication capabilities, to allow ALTO servers to coordinate actions and [...] introduce policies, which provide communication between applications localized in cooperating Autonomous Systems . Similar to SmoothIT and ALTO, P4P describes a common framework for servers/trackers that collaborate with end-system applications, e.g., P2P-system, to provide network topology information, such that the applications can use this information to adapt overlay connections on a inter as well as intra domain level. CDNI can be considered a collaborative approach, as content distribution networks are de facto based on collaboration and the interconnection of those even broadens this collaboration. In particular, CDNI addresses scenarios where a user requests content from a CDN, which may decide that the request can be better handled by a CDN that is located downstream. If the CDN that finally answers the request, does not hold the desired content, it will fetch the content from the respective content provider. The tit-for-tat mechanism used in BitTorrent can be considered a collaborative approach, as it is designed to stimulate cooperative behavior. RB-Tracker is a collaborative approach, as P2P clients anticipate which content may be requested by their user or the clients neighbors in order to fetch it and thereby improve the distribution process. Although the TP protocol was developed in the framework of BitTorrent applications, which are by nature collaborative, TP cannot be considered collaborative, as it only implements basic data exchange between two endpoints. Although this can already be considered collaboration, this collaboration is given by the very nature of data exchange but not an asset of the protocol. WebCloud and SocialTube improve content distribution in OSNs (where SocialTube focuses on video streaming) by involving user clients this process and are therefore considered collaborative approaches. NetStitcher is considered a collaborative approach, for it deploys network of commodity storage nodes to relay and re-route data between data centers. The approach chosen by Angels in the Cloud is collaborative as it is assumed that "the content provider choreographs the participation of all clients in a swarm" which implies altruistic and therefore collaborative behavior. Entries in Table 4 can be an x, which means the solution is collaborative, or it can be empty, which means no collaboration is applied. 5.1.3 Solutions/Mechanisms pursuing Energy Efficiency From the traffic management solutions described in the previous chapter, only a subset considers energy efficiency. As energy conservation is a topic, which includes all network layers, a large number of energy efficiency improving solutions is possible. These range from reducing the generated traffic over the reduction of the processing requirements to the use of hardware with higher energy efficiency. Although other EU projects exist, which consider energy efficiency, such as All4Green [3], CoolEmAll [27], and GAMES [40], the most relevant project is Fit4Green [39], which also investigates in energy-aware traffic management. In Fit4Green, the authors [41] propose
Version 1.1
Page 65 of 87

Public
to optimize the routing behavior in order to save energy. They propose an energy-aware routing protocol (EARP) that is fully distributed and showed that its saves more energy than other approaches. Based on the EARP, they investigated further and came up with a gradient algorithm that can save up to 10% more energy [42]. However, these approaches focus on the lower layers. Further information about these EU projects can be found in D1.1 [83]. For the assessment of the traffic management solutions described in the previous chapter, a number of parameters are of interest. Namely, these are the current power consumption, and in the case of mobile devices battery status, the available networks with an expected throughput and delay, and the average network usage. From these parameters, the possible optimizations in the network can be derived. Further interesting parameters are the current location and, in the case of movement, the general direction. Such, the availability of more energy efficient connections might be predicted, and as a consequence, data transmissions delayed until the more efficient network is connected. For the power measurements, two different approaches are possible. First, the power consumption can be measured prototypically on different devices and a model derived from this. This is extremely time-consuming, as a large range of devices is to be measured. At the same time, this approach is highly inflexible, as by design it cannot include the latest devices. The second approach is to monitor the power usage on each device individually using the PowerTutor [89], [119] or comparable software, which calculates the devices power consumption based on the activities of individual components, which are comparable between devices. An extension of this approach is described in [115], where the Power Tutor is extended to send the measurements to a server, where the measurements of the individual devices can be aggregated. An alternative for analyzing the power consumption of a given application is eprof [86], which allows analyzing the power consumption of the application under test down to the function level and, unlike PC based performance analysis tools, includes the hardware commonly found in smartphones like GPS, compass, gyro and display. Combining the energy consumption with the duration of a data transmission, the cost in Joule for a given file transfer can be calculated. The measurement is device dependent, because the chipsets and implementations differ, but can be used to derive the optimal transmission medium for a requested data transfer. This is of particular importance, if the media is not to be consumed immediately but cached on the device for later access. Exploiting this concept, it may even be more efficient to pre-load media up to a multiple of the usual consumption, which might never be used and later removed from the cache. Another solution to conserve energy within the network and at the content providers side are Nano Data Centers. These allow pre-fetching of content on the end-users devices. This is advantageous, as such the content, which is likely to be consumed later, can be placed on the first hop, or in a worse case, on other end-users internet gateways, and such, is only two hops away. According to [109] at least 20% to 30% of the overall energy consumed can be saved this way. There is also considerable space for improvement with respect to energy efficiency and social data. The first could be achieved in the wireless domain on the end-users device as well as the providers infrastructure, as an application of vINCENT can reduce traffic on mobile links considerably. Additionally, OSN data can be leveraged as a source of trust for
Page 66 of 87
Version 1.1

Public
the incentive scheme. A user can open his or her virtual node for friends, so they can utilize each others resources. At the end, the different routing and caching approaches are to be assessed based on their overall energy consumption as well as the energy consumption on the individual devices. The main objective in the end users perspective is to improve the QoE, i.e., reduce the delay of transmissions and increase the battery lifetime. From the view of the network operator, the main goal is to offload traffic, which might increase the power usage on the mobile clients. Here, the optimal tradeoff between the requirements of the network and the individual user must be met. In Table 4, an x denotes that a traffic management solution considers energy efficiency or is considerably more energy efficient that other solutions. 5.1.4 Social Aware Solutions Social awareness exploits the social behavior of users in order to enhance a service. With respect to traffic management, such an enhancement may be a better bandwidth or lower latency. Social awareness can be exploited in several ways. First, it can be used to schedule resources based on the temporal demand. The social network provides information where and when there is additional demand in the network or if network resources are temporarily not utilized. TailGate (see Section 4.3.12) takes into account social relationships and regularities in read access patterns to efficiently distribute long-tail content. Furthermore, it considers time zone differences, to utilize temporal resources in off-peak hours. To efficiently use unutilized bandwidth NetStitcher (see Section 4.3.11) can be used to transport content among data-centers. Second, social awareness can be used for improved caching or efficient content prefetching. Social networks can provide information about trends, i.e., they can indicate which content is likely to be consumed in the near future. This content can be cached temporarily and spatially according to the social network information. Similarly SocialTube (see Section 4.3.14) deploys social information to implement an OSN based P2P video on demand system. WebCloud (Sec. 4.3.15) deploys such information as well, to improve content distribution in OSNs. Also the approach taken by SocialTube gains its performance by deploying the fact, that content in OSNs follows social relationships. RBTracker (see Section 4.3.9) organizes P2P networks in a social aware manner, as (i) the P2P network clusters in dependence of shared interests of users and (ii) peers subsequently anticipate based on their neighbors interests which content may be interesting for their respective user or other neighbors. They then fetch the content in order to help in the distribution process. In [93] and [94] geo-information from social networks is used to improve caching and CDN performance, see Section 4.3.17. Finally, ISPs can use social awareness for cost effective monitoring, by identifying important nodes in the social network. An important node in the social network might be a person which has many followers in the IPSs network. In [8] influence of users and the content they share is quantified, depending on the interest and positive feeling of the content and the users past sharing behavior. If a person with high influence posts content,
Version 1.1
Page 67 of 87

Public
the followers will probably also demand the content. If the ISP monitors the important node it can act preemptive to avoid peak loads. Entries in Table 4 can be an x, which means the solution is aware of social behavior, or it can be empty, which means no social behavior is exploited. 5.1.5 Resource and Capacity Enhancing In the client-server paradigm, a central server provides the resources for all interested clients. The asymmetry of the approach often results in the server's resources being over utilized while the client's resources remain mostly idle. P2P can be considered as a resource enhancement approach that makes currently unused resources available at one peer available to other peers, thus using existing resources more effectively. In the case of BitTorrent [24], the upload bandwidth available at one peer can be used by another peer requiring download bandwidth. Other approaches for more efficient resource usage include the deployment of ISP-owned peers which aim to reduce inter-domain traffic and to increase download performance of common peers or the promotion of highly active peers (HAP) [85], [90]. NetStitcher stiches together the unused bandwidth available at different datacenters which results from fluctuating daily bandwidth requirements - by providing the bandwidth to processes that do not have real-time requirements (e.g., backup, update, and migration traffic) [67]. Nano Datacenters (NaDa) reduce the amount of required resources such as content servers, network resources as well as the energy by storing content and services on home gateways rather than datacenters [109]. Entries in Table 4 can be an x, which means the solution enhances a resource (bandwidth, storage, processing power), or it can be empty, which means no resource enhancement is performed. 5.1.6 Time Scale The time scale is an important factor for traffic management. The time scale describes when a traffic management mechanism takes effect. Such a mechanism may take effect immediately or take days, weeks, or even months. In the literature, the following time scales are distinguished: LTPT-level, Packet-level, call-level, days, weeks or months [64]. LTPT-level (less than a packet) describes a time scale that is less than one round trip time of a packet. This is used for scheduling and buffer management. One goal of such a buffer management is to keep the buffer not grow too large to prevent a bufferbloat. Routing prioritization based on packet markings (e.g., type-of-service) belongs also to this category. The time scale is typically in microseconds. Packet-level describes a time scale that has one or more round trip times. It is used for flow control based on feedback, retransmissions, and renegotiations. The time scale is typically in milliseconds. Sessionlevel describes a time scale that lasts for a session. Such a session may be a TCP stream. In ATM this time scale corresponds to call-level based mechanisms such as not allowing clients participate in case of congestion. The time scale is typically in minutes. Day-level describes a time scale that lasts for days. Such a mechanism may include human interaction since there is enough time to react. Peak offloading mechanisms such as RB-Tracker belongs to this category that offloads peaks within night time. The time scale is typically in days. Long-term-level describes a time scale that lasts from weeks to
Page 68 of 87
Version 1.1

Public
months and even longer. This time scale is used for capacity planning and negotiations involving long term contracts or peering agreements. The time scale is typically months. The following selected mechanisms are categorized into the previously mentioned time scales. NetStitcher and RB-Trackers time scale is in the category day-level, since the traffic is shifted from peak times to night times which happen typically within a day. On the other hand, DiffServ is a traffic management solution that takes effect within as soon as packet is marked and queued. TP uses the packet-level time scale, that means it needs to wait for a least one round-trip. Tit-for-tat is a traffic management scheme that takes previous contributions into account and either provides or rejects uploads to other peers. The effect can be seen within seconds to minutes. Peering and contracts are long term traffic management mechanisms that take effect for a longer period of time, from months to years. In order to enhance the overall categorization table with time-scales, the following timescales are grouped together: Short-term scale (empty field in Table 4): LTPT-level, packet-level, session-level, day-level Long-term scale (marked with x in Table 4): weeks or months
5.1.7 Incentive-Based/Compulsory Mechanisms To avoid congestion traffic management may be necessary e.g., to shape users. Such a traffic management mechanism may be compulsory that means it has to be strictly enforced. Another way would be to provide incentives to users not to use a service at a certain time. Such an incentive mechanism may be combined with caching so that users have an incentive to cache content during non-peak time and produce less traffic during peak time. The incentive is a better QoS for the end-user since the content is in the best case locally available. SmoothIT also provides an incentive to use their peer selection mechanism, since the selected peer will be closer and can deliver a better QoS. A typical incentive mechanism is TFT where peer are encouraged to contribute upload bandwidth in order to get download bandwidth. Other incentive mechanisms include differentiated charging that charges users more during peak time and less when the network is less busy. Since incentive mechanisms cover a wide range of aspects, the dimensions for the categorizations are incentive-compatible (marked with x in Table 4) and enforced (empty field in Table 4). DiffServ is a traffic management solution that is typically enforced (although it may be part of another incentive mechanism), while RB-Tracker provides an incentive-compatible mechanisms where end-users have an incentive to actively cache content. vIncent also belongs to the incentive-compatible mechanisms, since it has an incentive mechanism built in. 5.1.8 End-User Related Some of the above mentioned traffic management solutions are only efficient, if end-users participate, i.e., the application or a part thereof must be deployed on the end-users device. As these approaches require user intervention, these are specifically marked here.
Version 1.1
Page 69 of 87

Public
An approach to motivate end-users installing additional software is tightly coupled to incentive schemes (see Section 5.1.7). Using the right incentives, it may be possible to convince people to install software packages supplied by the network provider. Still, privacy concerned users might opt-out of this, if the software requests too many privileges. The deployment of these components may also be achieved by large TelCos branding their devices, but this limits the scope to a comparatively small number of devices. A challenge inherent in software installed on the end users devices is that the versions of the software installed cannot easily be controlled from outside. Hence, the component and its interfaces must be well specified before deployment. In Table 4, an x denotes the need of the end-users interaction, or at least an installation on the devices in the field. The solutions with empty fields work in the network domain only and such, do not provoke the above mentioned problems.
5.2
Findings and Summary
Sections 5.1.1 to 5.1.8 introduced different characteristics of traffic management solutions in detail as identified in Chapter 4. Table 4 matches different tools (rows) to the before described characteristics (columns). As mentioned before, the solutions can be divided into characteristics concerning their layer affinity. This affinity is marked with x in the corresponding cell in the first two columns in Table 4. Solutions counting to the lower layers, such as IntServ, DiffServ, MPLS and CDNI, require compatibility to existing standards. Although clean-slate approaches (such as ICN [2]) exist and also propose to change the lower layers, however, such solutions have only been deployed in experimental setups and are not relevant to SmartenIT, since SmartenIT builds on existing Internet infrastructure. Most of the introduced tools count to the application layers (e.g., SmoothIT, RB-Tracker, and SocialTube) and require resource-enhancing strategies as described in Section 5.1.5. Some of those solutions additionally support collaborative activities / social awareness. In order to match the tools concerning the introduced characteristics in Sections 5.1.1 to 5.1.8, respective cells in Table 4 contain x or (x). For the interpretation of those decisions it is referred to the corresponding section.
Page 70 of 87
Version 1.1

Public
Table 4: Characterization of Tools. Long-term Time Scale (Section 5.1.6)
Resource Enhancing (Section 5.1.5)
Social Awareness (Section 5.1.4)
Energy Efficiency (Section 5.1.3)
Peering IntServ DiffServ MPLS BGP-Loc IoP HAP P4P (inter-) ALTO CDNI ABNO TFT TP RB-Tracker vIncent NetStitcher TailGate Angels
x x x x x x x x x x x x x x x x x x
x (x) x x x x x x x x x x x x x x
3
x x x x x x x x x x x x x x x x x x
x x x
(x)4 (x)5 x x x x x x x x x
x x x x x x x x x x x x x x x
3 4
DiffServ can be enhanced to work inter-domain, but typically works intra-domain. P4P does not dictate the exact method and one method is end-user related 5 Not in the case of inter-ALTO.
Version 1.1
Page 71 of 87
End-user related (Section 5.1.8) x
Incentive-Based (Section 5.1.7)
Application Layer (Section 4.3)
Collaborative (Section 5.1.2)
Inter-domain (Section 5.1.1)
Lower layer (Section 4.2)
NaDa
WebCloud
Page 72 of 87
SocialTube
Cloud Caching Lower layer (Section 4.2) x x x x x x x x x x x x x x x x x x Application Layer (Section 4.3) Inter-domain (Section 5.1.1) Collaborative (Section 5.1.2) Energy Efficiency (Section 5.1.3) Social Awareness (Section 5.1.4) x x Resource Enhancing (Section 5.1.5) x Long-term Time Scale (Section 5.1.6) Incentive-Based (Section 5.1.7)
CDN / geo-info. from OSNs
Microblog-based prediction
x x x x
Public
x x
Version 1.1
End-user related (Section 5.1.8)

Public
6 Summary and Conclusions

In this deliverable D2.1 we had three main targets, profiting from the investigations, analysis and conclusions provided in deliverable D1.1 [83]. The content of D1.1 provides major characteristics of contemporary cloud-based overlay applications, describes the potential for intervention aiming at optimization of applications traffic flows, energy efficiency and user-perceived QoE. D1.1 brings also recommendations for selection of overlay applications being of interest for SmartenIT project. The first target was to review classical management concepts with focus on traffic management standards, being worked out for years and thus constituting stable, widely accepted and implemented solutions. Main representatives of such approaches are DiffServ, basic MPLS, MPLS-TE and BGP-TE. All four mentioned concepts fit into transport-oriented solutions, being in Chapter 4 completed by many novel concepts such as SON, SDN, and OpenFlow. The second target was to describe emerging traffic management solutions relevant for cloud-based applications and reflecting partners understanding of concepts potentially applicable for SmartenIT or at least giving new dimensions for discussion about architecture, scenarios, and functionalities of novel applications. This overview of traffic management solutions was done mainly from the viewpoint of economic incentives and social awareness in traffic management, and not exactly from the energy efficiency viewpoint. Finally, the third target was to make suggestions and conclusions, on the basis of done analysis, to the modular structure of SmartenIT architecture being defined within WP3. The next two sections summarize key outcomes and lessons learnt from our investigations towards mentioned above three targets, and finally outline the next steps and open issues to be addressed in future works of SmartenIT, mainly within WP2, but also when transferring results to practical implementation done within WP3.
6.1
Key Outcomes and Lessons Learnt
This deliverable documents classical, currently elaborated and prospective traffic management solutions for existing and emerging applications. They are described and analyzed with a main focus on suitability of traffic management mechanisms. Besides overviewing requirements of stakeholders and application features, conclusions and directions for SmartenIT project are formulated. A broad definition of different types of requirements for SmartenIT traffic management solutions is given in Chapter 3. Three categories of requirements, namely stakeholders' requirements, incentive schemes requirements and technical requirements ensure that a complete and consistent vision of network traffic management is achieved. Identification of stakeholders provided in Section 3.1 begins from definition of scenarios and relevant stakeholders are listed for each scenario, with provided specific requirements. Such approach is comprehensively summarized in Table 1. The considered scenarios are the outcome of wide discussion among partners and they reflect main useful situations: inter-cloud communication, global service mobility, exploiting online social information, and support for collaboration among data centers. The main identified stakeholders are: connectivity providers, service providers, information providers, and end-
Version 1.1
Page 73 of 87

Public
users. Depending on the scenario, the involved stakeholders disclose slightly different roles and targets. Definition of incentive schemes is provided in Section 3.2, summarized in Table 2 with mentioned main features and time scales identified for each case. Identification of incentive schemes is completed by suggestions for defining features of SmartenIT system in order to be attractive for involved stakeholders. It is briefly illustrated how the incentive system works for the global service mobility scenario where mobile network providers could use information about location of mobile user in a case the latter one is profiting from enhaced level of service, e.g., by receiving valuable location-based data. A broad range of technical requirements is presented in Section 3.3 and they are aligned to the SmartenIT main objectives and purposes as described in the DoW [100] and subsequently discussed in the preliminary phase of running the project. This introductory period made possible an alignment of general studies on service and stakeholder classification within WP1, management aspects with SmartenIT key targets within WP2 and recommendations towards architecture and functionality definition within WP3. As an example of how technical requirements work we recall here social awareness, being one of three main objectives of SmartenIT project. The social awareness catches qualitatively, and possibly also quantitatively, the mutual relationships between users who are interested in the same contents in order to influence the decision on traffic management and on content placing. Preliminary proposal for SmartenIT is to infer social information based on device-awareness with the intention to move the concept towards user-awareness. The summary of traffic management requirements for SmartenIT system is presented in Table 3 where as many as 13 interesting for SmartenIT categories are listed and supplemented by their interest and relevance for practical implementation within the project using must have and nice to have indication. Chapter 4 consequently translates requirements from Chapter 3 into many traffic management solutions relevant for SmartenIT. This section can be considered as repository of concepts, with different levels of details and applicability, but with possibly wide scope of enumerated potential mechanisms and their location in single layers and inter-layers. Section 4.1 presents a high-level view of business and traffic needs, the Internet interconnection agreements which can be considered as a layer constituting the basic structure of the Internet. As a consequence of set-up of this layer, the structure of Internet with the inter-domain routes and resources is designed and configured. On top of this basic topology, the more specific traffic management solutions are deployed. The single-layer mechanisms are presented in Section 4.2. Among 8 described concepts, 4 have long history and they constitute the core of classical traffic management solutions: IntServ, DiffServ, basic MPLS and MPLS-TE, with the first one, the IntServ be claimed to lack scalability feature. Emerging concepts, such as SON and OpenFlow are gaining increasing interest concerning their practical usage. SON defines distributed network management functionality completed by topology discovery and searching. Section 4.3 provides description of impressive number of 19 management solutions indicated as inter-layer or application layer solutions. Inter-Layer traffic management solutions provide dedicated mechanisms allowing making available information from
Page 74 of 87
Version 1.1

Public
underlying network infrastructure aim to applications. Important representatives of this group of solutions are SmoothIT, ALTO and Inter-ALTO. They are designed originally for P2P networks but can be relevant for SmartenIT. E.g., ALTO systems do not actively manage traffic; they merely expose an interface to overlay applications that are able to cooperate voluntarily. Using this interface the underlay properties can be transferred to overlay applications. In Section 4.3, several strictly application-oriented solutions based of defining distributed architecture and organizing exchange of information about users activity and location are described. Each solution has its specific scenario and set-up architecture with the intention to explore social-aware information and exploiting off-load of information transfer. E.g., TailGate application uses social information derived from OSNs, such as social relationships, regularities in accessing content and additionally exploiting time-zone differences in order to predict where and when the content will be probably consumed and such content is in advance transferred closer to potentially interest user. Different characteristics of traffic management solutions identified in Chapter 4 are then introduced in details in Sections 5.1.1 to 5.1.8 and summarized in Table 4. Rows in Table 4 identify different solutions (tools), while described characteristics are indicated in columns. The content of Table 4 should be of significant importance for practical implementations of SmartenIT architecture since columns relevant for projects key targets (such as energy efficiency) will direct our attention to ideas of good practices. In other words, when enhancing SmartenIT architecture, the participants are able to analyze and classify the pros and cons for designed modules.
6.2
Next steps
This deliverable D2.1 provides a categorization of management approaches, current and prospective traffic management solutions for existing and emerging applications. They are described and analyzed with a main focus on suitability of traffic management mechanisms and their potential implementation in experimental works carried within SmartenIT project. Results from D2.1 can have some impact on several other activities in SmartenIT project. Already defined scenarios can be further developed in T1.4 into final scenario settings. The direct task relying on D2.1 results is T2.3 with the target to finally define Traffic Management Mechanisms Specification, being with accordance to system architecture designed within T3.1 and documented in D3.1 [56]. Using assumptions, analysis, and comparisons of stakeholders, services, and management mechanisms done and documented in D1.1 and D2.1, it is possible for SmartenIT consortium to identify the gap between extensively defined requirements and existing implementations. As a consequence, it is possible to introduce building blocks to the SmartenIT architecture to help make efficient management mechanisms. The project will propose innovative management solutions supporting service provisioning based on clouds, overlays, social networks, user mobility, service performance, energy efficiency, and operators requirements.
Version 1.1
Page 75 of 87

Public
7 SMART Objectives Addressed

Through this document, three SmartenIT SMART objectives defined in Section B1.1.2.4 of the SmartenIT Description of Work (DoW, [100]) have been partially addressed. Namely, one overall (O2, see Table 5) and two theoretical (O1.1 and O1.4, see Table 6) SMART objectives were addressed. The overall Objective 2 is defined in DoW as following: Objective 2 SmartenIT will develop theory for new pricing and business models, applicable in example use cases, combined with the design and prototyping of appropriate traffic management mechanism that can be combined with todays and IETFs proposed relevant communication protocols. The specific research area covered by this deliverable is: Prototyping of traffic management mechanisms. The document contributes to the design achievement by providing an overview (Chapter 4) and classification (Chapter 5) of existing traffic management solutions. Moreover, the requirements for the traffic management mechanisms being developed by the SmartenIT project have been determined and are listed in Chapter 3. These results provide the basis for tasks T2.2 and T2.3 in which further traffic management solution design process will be continued. Further information concerning realization of Objective 2 in the abovementioned research area will be presented in deliverables D2.4 (end of project month 24) and D3.4 (end of project month 30). Table 5: Overall SmartenIT SMART objective addressed. (Source: [100])
Objective No.
O2
Measurable Specific
Prototyping of traffic management mechanisms
Deliverable Number
Timely Achievable Relevant

Mile Stone Number
D2.1
Design
Complex
MS2.1
Table 6: Theoretical SmartenIT SMART objectives addressed. (Source: [100])

Objective ID Measurable Specific
Metric
Timely Achievable Relevant

Project Month
O1.1
How to align real ISP networks, while optimizing overlay service/cloud requirements? Are decentralized traffic management schemes superior to traditional schemes; if yes, why? If not, what is the associated efficiency loss?
Savings in inter-domain traffic (in Mbit/s) and possible energy savings of due to optimized management mechanisms Number of identified and tested scenarios for the comparison of the different traffic management schemes
Design T2.1
Major output of relevance for provider and in turn users
M36
O1.4
Design T2.1
Highly relevant output of relevance for providers
M12 (design)
Page 76 of 87
Version 1.1

Public
This deliverable contributes to answering two specific theoretical questions: 1. Objective O1.1: How to align real ISP networks, while optimizing overlay service/cloud requirements? The literature overview performed during task T2.1 and reported in this document proved that there is a potential for optimization of the network behavior. The overviewed solutions (see Chapter 4 and the summary in Chapter 5) were provided together with a number of numerical results showing that it is possible to reduce the inter-domain traffic volume and/or energy consumption. This document will serve as an important reference for tasks T2.2 and T2.3 in which solutions pursuing savings in both traffic volume and energy will be designed. Further research on this topic (including assessment of the developed solutions) will be done within tasks T1.4, T2.2, T2.5, and T4.4. 2. Objective O1.4: Are decentralized traffic management schemes superior to traditional schemes; if yes, why? If not, what is the associated efficiency loss? As stated above, a number of traffic management solutions were overviewed. This document shows that both centralized and decentralized ones can be beneficial in different scenarios. In Chapter 3, four scenarios were discussed and the requirements for traffic management solutions mapped onto them. Together with the results of task T1.2 (see deliverable D1.1 [83]), these results will be used by tasks T2.2 and T2.3 during development of use-cases and solutions. The detailed comparison of the different traffic management schemes in various scenarios will be carried within task T2.5. According to the SMART objectives set within SmartenIT DoW, those ones of relevance for D2.1 and the respective task within WP2, i.e., T2.1, the targeted for objectives have been met.
Version 1.1
Page 77 of 87

Public
8 References
[1] [2] [3] [4] [5] [6] [7] [8] [9] 3rd Generation Partnership Project (3GPP). "Telecommunication management; Self-Organizing Networks (SON); Concepts and requirements." TS 32.500 version 11.1.0 Release 11, 2012. Ahlgren, Bengt, et al. "A survey of information-centric networking." Communications Magazine, IEEE 50.7 (2012): 26-36. All4Green. [Online] http://www.all4green-project.eu/. Accessed April 2013. Andrews, Matthew, et al. "Routing and scheduling for energy and delay minimization in the powerdown model." Networks (2012). Awduche, Daniel, et al. "Overview and principles of Internet traffic engineering. RFC 3272, 2002. Awduche, Daniel, et al. "Requirements for Traffic Engineering Over MPLS." RFC 2702, 1999. Babiarz, Jozef, Kwok Ho Chan, and Fred Baker. "Configuration Guidelines for DiffServ Service Classes." RFC 4594, 2006. Bakshy, Eytan, et al. "Everyone's an influencer: quantifying influence on twitter." Proceedings of the fourth ACM international conference on Web search and data mining. ACM, 2011. Balasubramanian, Niranjan, Aruna Balasubramanian, and Arun Venkataramani. "Energy consumption in mobile phones: a measurement study and implications for network applications." Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference. ACM, 2009.
[10] Baliga, Jayant, et al. "Green cloud computing: Balancing energy in processing, storage, and transport." Proceedings of the IEEE 99.1 (2011): 149-167. [11] Berl, Andreas, et al. "Energy-efficient cloud computing." The Computer Journal 53.7 (2010): 1045-1051. [12] Bertrand, Gilles, et al. "Use cases for content delivery network interconnection." RFC 6770, 2012. [13] Bjorkqvist, M., et al. "Minimizing retrieval latency for content cloud." INFOCOM, 2011 Proceedings IEEE. IEEE, 2011. [14] Blake, Steven, et al. "An architecture for differentiated services." RFC 2475, 1998.. [15] Bocek, Thomas, et al. "CompactPSH: An efficient transitive TFT incentive scheme for Peer-to-Peer Networks." Local Computer Networks, 2009. LCN 2009. IEEE 34th Conference on. IEEE, 2009. [16] Bolla, Raffaele, et al. "Energy-aware performance optimization for next-generation green network equipment." Proceedings of the 2nd ACM SIGCOMM workshop on Programmable routers for extensible services of tomorrow. ACM, 2009. [17] Bolla, Raffaele, et al. "Performance constrained power consumption optimization in distributed network equipment." Communications Workshops, 2009. ICC Workshops 2009. IEEE International Conference on. IEEE, 2009. [18] Braden, Rob, David Clark, and Scott Shenker. "Integrated services in the Internet architecture: an overview." RFC 1633, 1994. [19] Chan, Kwok Ho, Jozef Z. Babiarz, and Fred Baker. "Aggregation of DiffServ service classes." RFC 5127, 2008. [20] Chang, Bin, et al. "On Feasibility of P2P on-demand streaming via empirical VoD user behavior analysis." Distributed Computing Systems Workshops, 2008. ICDCS'08. 28th International Conference on. IEEE, 2008. [21] Chiu, David, Apeksha Shetty, and Gagan Agrawal. "Elastic cloud caches for accelerating serviceoriented computations." High Performance Computing, Networking, Storage and Analysis (SC), 2010 International Conference for. IEEE, 2010. [22] Choffnes, David R., and Fabin E. Bustamante. "Taming the torrent: a practical approach to reducing cross-ISP traffic in peer-to-peer systems." ACM SIGCOMM Computer Communication Review. Vol. 38. No. 4. ACM, 2008. [23] Cohen, Bram. "Incentives build robustness in BitTorrent." Workshop on Economics of Peer-to-Peer systems. Vol. 6. 2003. [24] Cohen, Bram. "The BitTorrent protocol specification." (2008).
Page 78 of 87
Version 1.1

Public
[25] Cohen, Reuven, and Gabi Nakibly. "Maximizing restorable throughput in MPLS networks." IEEE/ACM Transactions on Networking (TON) 18.2 (2010): 568-581. [26] Cole, Richard, Yevgeniy Dodis, and Tim Roughgarden. "How much can taxes help selfish routing?." Journal of Computer and System Sciences 72.3 (2006): 444-467. [27] CoolEmAll. [Online] http://www.coolemall.eu/. Accessed April 2013. [28] Dellarocas, Chrysanthos. "Reputation mechanisms." Handbook on Economics and Information Systems (2006): 629-660. [29] Despotovic, Zoran (editor). "Deliverable D3.4: Economic Traffic Management Systems Architecture Design." SmoothIT, 2010. [30] Dong, Xiaowen, et al. "Energy-efficient core networks." Optical Network Design and Modeling (ONDM), 2012 16th International Conference on. IEEE, 2012. [31] DrPeering - The Internet Peering Knowledge Center. [Online] http://drpeering.net/. Accessed April 2013. [32] Duliski, Zbigniew, et al. "Inter-ALTO communication protocol." draft-dulinski-alto-inter-alto-protocol-00, work in progress, 2010. [33] Duliski, Zbigniew, Piotr Wydrych, and Rafal Stankiewicz. " Inter-ALTO Communication Problem Statement." draft-dulinski-alto-inter-problem-statement-01, work in progress, 2011. [34] Eidenbenz, Raphael, et al. "Boosting Market Liquidity of Peer-to-Peer Systems Through Cyclic Trading." Peer-to-Peer Computing (P2P), 2012 IEEE International Conference on. IEEE, 2012. [35] Farrel, A., Arthi Ayyangar, and J. P. Vasseur. "Inter-Domain MPLS and GMPLS Traffic Engineering Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions." RFC 5151, 2008. [36] Farrel, Adrian and Jean-Philippe Vasseur. "A Path Computation Element (PCE)-Based Architecture." RFC 4655, 2006. [37] Farrel, Adrian, Arthi Ayyangar, and Jean-Philippe Vasseur. "Inter-Domain MPLS and GMPLS Traffic Engineering Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions." RFC 5151, 2008. [38] Fernandez-Palacios Gimenez, Juan Pedro, et al. "A new approach for managing traffic of overlay applications of the SmoothIT project." 2nd International Conference on Autonomous Infrastructure, Management and Security (AIMS08). 2008. [39] Fit4Green. [Online] http://www.fit4green.eu/. Accessed April 2013. [40] GAMES. [Online] http://www.green-datacenters.eu/. Accessed April 2013. [41] Gelenbe, Erol and Toktam Mahmoodi. "Distributed energy-aware routing of traffic." 26th International Symposium on Computer and Information Sciences (ISCIS'11). 2011. [42] Gelenbe, Erol, and Christina Morfopoulou. "Power savings in packet networks via optimised routing." Mobile Networks and Applications 17.1 (2012): 152-159. [43] Gelenbe, Erol, and Simone Silvestri. "Reducing power consumption in wired networks." Computer and Information Sciences, 2009. ISCIS 2009. 24th International Symposium on. IEEE, 2009. [44] Ghein, Luc De. MPLS fundamentals. Cisco Press, 2006. [45] Google. "Google Apps: Energy Efficiency in the Cloud." [Online] http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/us/green/pdf/ google-apps.pdf. Accessed March 2013. [46] Grossman, Dan. "New terminology and clarifications for Diffserv. RFC 3260, 2002. [47] GSMA. "IP eXchange | Technical Projects." [Online] http://www.gsma.com/technicalprojects/technicalprogramme/ip-exchange. Accessed April 2013. [48] Gupta, Minaxi, Paul Judge, and Mostafa Ammar. "A reputation system for peer-to-peer networks." Proceedings of the 13th international workshop on Network and operating systems support for digital audio and video. ACM, 2003. [49] Gurbani, Vijay. " Peer-to-peer infrastructure: The application-layer traffic optimization (ALTO) problem." [Online]
Version 1.1
Page 79 of 87

Public
http://callan.nuim.ie/publications/documents/presentations/vijay_gurbani_28may08_%28alto%29.pdf. Accessed March 2013. [50] Hardin, Garrett. "The tragedy of the unmanaged commons." Trends in ecology & evolution 9.5 (1994): 199. [51] Harmer, T. J., et al. "Gridcast: a grid and Web service broadcast infrastructure." Services Computing, 2005 IEEE International Conference on. Vol. 1. IEEE, 2005. [52] Halinger, Gerhard, and Franz Hartleb. "Content delivery and caching from a network providers perspective." Computer Networks 55.18 (2011): 3991-4006. [53] Halinger, Gerhard, and Thomas Kunz. "Challenges for routing and search in dynamic and self organizing networks." Ad-Hoc, Mobile and Wireless Networks (2009): 42-54. [54] Halinger, Gerhard, et al. "Traffic engineering supported by Inherent Network Management: analysis of resource efficiency and cost saving potential." International Journal of Network Management 21.1 (2011): 45-64. [55] Halinger, Gerhard, Stefan Schnitter, and Martin Franzke. "The Efficiency of Traffic Engineering with Regard to Link Failure Resilience." Telecommunication Systems 29.2 (2005): 109-130. [56] Hausheer, David and Julius Rckert (editors). "Deliverable D3.1: Report on Initial System Architecture." SmartenIT, 2013. [57] Hu, Hao, Yang Guo, and Yong Liu. "Peer-to-peer streaming of layered video: Efficiency, fairness and incentive." Circuits and Systems for Video Technology, IEEE Transactions on 21.8 (2011): 1013-1026. [58] Hughes, Daniel, Geoff Coulson, and James Walkerdine. "Free riding on Gnutella revisited: the bell tolls?." Distributed Systems Online, IEEE 6.6 (2005). [59] IETF. "ALTO Status Pages". [Online] http://tools.ietf.org/wg/alto/. Accessed March 2013. [60] IETF. "MPLS Status Pages". [Online] http://tools.ietf.org/wg/mpls/. Accessed April 2013. [61] ITU-T. "Principles for a telecommunications management network." Recommendation M.3010, 2000. [62] Jaramillo, Juan Jos, and R. Srikant. "A game theory based reputation mechanism to incentivize cooperation in wireless ad hoc networks." Ad Hoc Networks 8.4 (2010): 416-429. [63] Kalogiros, Costas, et al. "An approach to investigating socio-economic tussles arising from building the future internet." The future internet (2011): 145-159. [64] Keshav, Srinivasan. "An Engineering Approach to Computer Networking: ATM Networks, The Internet and Telephone Network." Reading MA 11997 (1997). [65] King, Daniel and Adrian Farrel. "A PCE-based Architecture for Application-based Network Operations." draft-farrkingel-pce-abno-architecture-03, work in progress, 2013. [66] Kwan, Raymond, et al. "On mobility load balancing for LTE systems." Vehicular Technology Conference Fall (VTC 2010-Fall), 2010 IEEE 72nd. IEEE, 2010. [67] Laoutaris, Nikolaos, et al. "Inter-datacenter bulk transfers with Netstitcher." ACM SIGCOMM. 2011. [68] Lareida, Andri, Thomas Bocek, Martin Waldburger, and Burkhard Stiller, "RB-Tracker: A Fully Distributed, Replicating, Network-, and Topology-aware P2P CDN." Integrated Network Management Workshops, 2013. IM'13. IFIP/IEEE International Symposium on. IEEE, 2013 [69] Li, Li, et al. "Routing bandwidth guaranteed paths with local restoration in label switched networks." Network Protocols, 2002. Proceedings. 10th IEEE International Conference on. IEEE, 2002. [70] Li, Ze, et al. "SocialTube: P2P-assisted video sharing in online social networks." INFOCOM, 2012 Proceedings IEEE. IEEE, 2012. [71] Locher, Thomas, et al. "Free riding in BitTorrent is cheap." Proc. Workshop on Hot Topics in Networks (HotNets). 2006. [72] Loukos, Fotis, and Helen Karatza. "SPECT: A system for Peer-to-Peer economic transactions." Computers and Communications (ISCC), 2011 IEEE Symposium on. IEEE, 2011. [73] MZIMA. "The Donut Peering Model: Optimizing IP Transit for http://packetexchange.com/pdf/donut_peering.pdf. Accessed April 2013. Online Video." [Online]
Page 80 of 87
Version 1.1

Public
[74] Nakamoto, Satoshi. "Bitcoin: A peer-to-peer http://bitcoin.org/bitcoin.pdf. Accessed March 2013.
electronic
cash
system."
2008.
[Online]
[75] Nedevschi, Sergiu, et al. "Reducing network energy consumption via sleeping and rate-adaptation." Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation. No. 14. 2008. [76] NGMN Alliance. " Next Generation Mobile Networks Use Cases related to Self Organising Network, Overall Description." 2008. [77] Nisan, Noam, and Amir Ronen. "Algorithmic mechanism design." Proceedings of the thirty-first annual ACM symposium on Theory of computing. ACM, 1999. [78] Niven-Jenkins, Ben, Francois L. Faucheur, and Nabil Bitar. "Content distribution network interconnection (CDNI) problem statement."RFC 6770, 2012. [79] Norberg, Arvid. " uTorrent transport protocol." BEP 29, 2012. [80] Oechsner, Simon, et al. "A framework of economic traffic management employing self-organization overlay mechanisms." Self-Organizing Systems. Springer Berlin Heidelberg, 2008. 84-96. [81] Open Networking Foundation. "Software-Defined Networking: The New Norm for Networks." ONF White Paper, 2012. [82] OpenFlow. "OpenFlow Documents." [Online] http://www.openflow.org/wp/documents/. Accessed March 2013. [83] Papafili, Ioanna and George D. Stamoulis (editors). "Deliverable D1.1: Report on Stakeholders Characterization and Traffic Characteristics." SmartenIT, 2013. [84] Papafili, Ioanna, et al. "Assessment of economic management of overlay traffic: methodology and results." The future internet. 2011. 121-131. [85] Papafili, Ioanna, Sergios Soursos, and George D. Stamoulis. "Improvement of bittorrent performance and inter-domain traffic by inserting isp-owned peers." Network Economics for Next Generation Networks. Springer Berlin Heidelberg, 2009. 97-108. [86] Pathak, Abhinav, Y. Charlie Hu, and Ming Zhang. "Where is the energy spent inside my app?: fine grained energy accounting on smartphones with eprof." Proceedings of the 7th ACM european conference on Computer Systems. ACM, 2012. [87] Pepelnjak, Ivan, and Jim Guichard. MPLS and VPN architectures. Cisco Press, 2001. [88] Piro, Michal, and Deepankar Medhi. Routing, flow, and capacity design in communication and computer networks. Morgan Kaufmann, 2004. [89] PowerTutor. [Online] http://powertutor.org/. Accessed: March 2013. [90] Pussep, Konstantin, et al. "An incentive-based approach to traffic management for peer-to-peer overlays." Incentives, Overlays, and Economic Traffic Control. Springer Berlin Heidelberg, 2010. 2-13. [91] Racz, Peter, Simon Oechsner, and Frank Lehrieder. "BGP-based locality promotion for P2P applications." Computer Communications and Networks (ICCCN), 2010 Proceedings of 19th International Conference on. IEEE, 2010. [92] Sandvine. "Global Internet Phenomena Report". http://www.sandvine.com/news/global_broadband_trends.asp. Accessed January 2013. [Online]
[93] Sastry, Nishanth, Eiko Yoneki, and Jon Crowcroft. "Buzztraq: predicting geographical access patterns of social cascades using social networks." Proceedings of the Second ACM EuroSys Workshop on Social Network Systems. ACM, 2009. [94] Scellato, Salvatore, et al. "Track globally, deliver locally: improving content delivery networks by tracking geographic social cascades." Proceedings of the 20th international conference on World wide web. ACM, 2011. [95] Seedorf, Jan, and Eric Burger. "Application-layer traffic optimization (ALTO) problem statement." RFC 5693, 2009. [96] Seedorf, Jan, Sebastian Kiesel, and Martin Stiemerling. "Traffic localization for P2P-applications: The ALTO approach." Peer-to-Peer Computing, 2009. P2P'09. IEEE Ninth International Conference on. IEEE, 2009.
Version 1.1
Page 81 of 87

Public
[97] Shalunov, Stanislav, et al. "Low extra delay background transport (LEDBAT)." RFC 6817, 2012. [98] Sharma, Vishal, and Fiffi Hellstrand. "Framework for multi-protocol label switching (MPLS)-based recovery." RFC 3469, 2003. [99] Sirivianos, Michael, et al. "Free-riding in BitTorrent networks with the large view exploit." Proc. of IPTPS. Vol. 7. 2007. [100] SmartenIT. "Grant Agreement for STREP: Annex I 'Description of Work (DoW)'." 2012. [101] SOCRATES (Self-Optimisation and self-ConfiguRATion in wirelEss networkS). [Online] http://www.fp7socrates.org/. Accessed March 2013. [102] Soursos, Sergios (editor). "Deliverable D3.3: Documentation of Engineering and Implementation." SmoothIT, 2010. [103] Soursos, Sergios, et al. "ETMS: A System for Economic Management of Overlay Traffic." Towards the Future Internet-Emerging Trends from European Research, IOS Press, Amsterdam (2010). [104] Stankiewicz, Rafa, Piotr Choda, and Andrzej Jajszczyk. "QoX: what is it really?." Communications Magazine, IEEE 49.4 (2011): 148-158. [105] Sundaram, Shanmugham, Abdurakhmon Abdurakhmanov, and Young-Tak Kim. "WBEM-based InterAS Traffic Engineering for QoS-guaranteed DiffServ Provisioning." Broadband Convergence Networks, 2006. BcN 2006. The 1st International Workshop on. IEEE, 2006. [106] Sweha, Raymond, Vatche Ishakian, and Azer Bestavros. "Angels in the cloud: A peer-assisted bulksynchronous content distribution service." Cloud Computing (CLOUD), 2011 IEEE International Conference on. IEEE, 2011. [107] Szilgyi, Lszl, Tibor Cinkler, and Zoltn Cserntony. "Energy-Efficient Networking: An Overview." Acta Universitatis Sapientiae, Electrical and Mechanical Engineering 2 (2010): 99-113. [108] Traverso, Stefano, et al. "TailGate: handling long-tail content with a little help from friends." Proceedings of the 21st international conference on World Wide Web. ACM, 2012. [109] Valancius, Vytautas, et al. "Greening the internet with nano data centers." Proceedings of the 5th international conference on Emerging networking experiments and technologies. ACM, 2009. [110] Waldburger, Martin (editor). "Deliverable D5.1: Dissemination, External Liaisons Plan, and Initial Exploitation Plan." SmartenIT, 2013. [111] Wang, Haiyang, Feng Wang, and Jiangchuan Liu. "Accelerating peer-to-peer file sharing with social relations: Potentials and challenges." INFOCOM, 2012 Proceedings IEEE. IEEE, 2012. [112] Wang, Zhi, et al. "Guiding internet-scale video service deployment using microblog-based prediction." INFOCOM, 2012 Proceedings IEEE. IEEE, 2012. [113] Welzl, Michael, and Max Muhlhauser. "Scalability and quality of service: a trade-off?." Communications Magazine, IEEE 41.6 (2003): 32-36. [114] Wichtlhuber, Matthias, and David Hausheer. "vINCENT: An Incentive-Scheme for Peer-to Peer Content Distribution Supporting Virtual Nodes". Conference on Networked Systems (NetSys), PhD Forum, 2013. [115] Wichtlhuber, Matthias, et al. "Energy-Efficient Mobile P2P Video Streaming" (Demo). Peer-to-Peer Computing (P2P), 2010 IEEE Tenth International Conference on. IEEE, 2010. [116] Wuhib, Fetahi, et al. "Robust monitoring of network-wide aggregates through gossiping." Network and Service Management, IEEE Transactions on 6.2 (2009): 95-109. [117] Wuhib, Fetahi, Mads Dam, and Rolf Stadler. "Decentralized detection of global threshold crossings using aggregation trees." Computer Networks 52.9 (2008): 1745-1761. [118] Xie, Haiyong, et al. "P4P: Explicit communications for cooperative control between P2P and network providers." P4PWG Whitepaper (2007). [119] Zhang, Lide, et al. "Accurate online power estimation and automatic battery behavior based power model generation for smartphones." Proceedings of the eighth IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis. ACM, 2010. [120] Zhang, Lixia, et al. "Resource reservation protocol (RSVP) Version 1 functional specification." RFC 2205, 1997. Page 82 of 87
Version 1.1

Public
[121] Zhang, Lixia, et al. "RSVP: A new resource reservation protocol." Network, IEEE 7.5 (1993): 8-18. [122] Zhou, Fangfei, et al. "WebCloud: Recruiting social network users to assist in content distribution." Network Computing and Applications (NCA), 2012 11th IEEE International Symposium on. IEEE, 2012.
Version 1.1
Page 83 of 87

Public
9 Abbreviations
TP 3GPP ABNO ALTO API AQM AS BGP CAPEX CDN CDNI CE CPU DHT DiffServ DNS DoW DSCP DSL EPC ETICS ETM FCAPS FOF GMPLS GSM GT HTTP ICN ICT IETF IntServ IoP Micro Transport Protocol 3rd Generation Partnership Project Application-Based Network Operations Application-Layer Traffic Optimization Application Programming Interface Active Queue Management Autonomous System Border Gateway Protocol Capital Expenditure Content Delivery/Distribution Network Content Distribution Network Interconnection Customer Edge Central Processing Unit Distributed Hash Table Differentiated Services Domain Name System Description of Work DiffServ Code Points Digital Subscriber Line Evolved Packet Core Economics and Technologies for Inter-Carrier Services Economic Traffic Management Fault, Configuration, Accounting, Performance, and Security Friend-of-Friend Generalized Multi-Protocol Label Switching Global System for Mobile Communications Group Tree algorithm Hyper-Text Transfer Protocol Information-centric Networking Information and Communication Technologies Internet Engineering Task Force Integrated Services ISP-owned Peers
Page 84 of 87
Version 1.1

Public
IP IPX IS-IS ISP ITU KPI LDP LEDBAT LFU LRU LSP LSR LTE LTPT MDT MNO MOS MPLS MSE NaDa NNI OAM OCEAN OPEX OS OSI OSN OSPF P2P P2P P4P PA PCE PE PHB
Version 1.1
Internet Protocol IP eXchange Intermediate System to Intermediate System Internet Service Provider International Telecommunication Union Key Performance Indicator Label Distribution Protocol Low Extra Delay Background Transport Least Frequently Used Least Recently Used Label-switched Path Label Switch Router Long Term Evolution Less Than a Packet Minimum Distribution Time Mobile Network Operator Mean Opinion Score Multiprotocol Label Switching Mean Squared Error Nano Data Centers Network to Network Interface Operations and Maintenance Open ContEnt Aware Networks Operating Expenditure Operating System Open Systems Interconnection Online Social Network Open Shortest Path First Peer-to-Peer Point-to-Point Proactive Network Provider Participation for P2P Peer-Assisted Path Computation Element Provider Edge Per-Hop Behavior
Page 85 of 87

Public
PoP PUE QoE QoS RFC RSVP SDN SIS SLA SmartenIT SmoothIT SnF SON STREP TCP TE TFT TM TMN UGC VLAN VM VoD VPN VRF WP
Point-of-Presence Power Usage Efficiency Quality of Experience Quality of Service Request for Comments Resource Reservation Protocol Software-defined Networking SmoothIT Information Service Service level agreement Socially-aware Management of New Overlay Application Traffic with Energy Efficiency in the Internet Simple Economic Management Approaches Heterogeneous Internet Topologies Store-and-forward Self-Organising Networks Specific Targeted Research Project Transmission Control Protocol Traffic Engineering Tit-for-tat Traffic Management Telecommunications Management Network User-Generated Content Virtual Local Area Network Virtual Machine Video on Demand Virtual Private Network Virtual Routing Forwarding Work Package of Overlay Traffic in
RB-Tracker Replicated Balanced Tracker
Page 86 of 87
Version 1.1

Public
10 Acknowledgements
This deliverable was made possible due to the large and open help of the WP2 team of the SmartenIT team within this STREP, which includes the deliverable authors as indicated in the document control. Many thanks to all of them.
Version 1.1
Page 87 of 87

Deliverable D2.1 Report On Overview of Overlay Traffic Management Solutions

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deliverable D2.1 Report On Overview of Overlay Traffic Management Solutions

Uploaded by

Copyright:

Available Formats

Seventh Framework STREP No.

D2.1 - Overlay Traffic Management Solutions