Seungmin Kang
email: kangseungmin@nus.edu.sg

Bharadwaj Veeravalli

Khin Mi

Mi Aung
email: mimiaung@dsi.a-star.edu.sg

ESPRESSO: An Encryption as a Service for Cloud Storage Systems

Keywords: Cloud storage system, encryption, data privacy protection Encryption as a Service Encryptor Encrypted Key Storage Encrypted Key Replicator Data Encryption Management

Cloud storage systems have become the primary storage space for cloud users' data. Despite the huge advantages and flexibility of the cloud storage services, many challenges are hindering the migration of users' data into the cloud. Among them, the data privacy needs to be considered. In this paper, we design and implement an encryption service namely ESPRESSO (Encryption as a Service for Cloud Storage Systems) to protect the users' data by using advanced encryption algorithms. The flexible design and the standalone property of ESPRESSO allow cloud storage service providers to easily integrate it without heavy modification and implementation of their infrastructures. ESPRESSO was integrated into two open-source cloud storage platforms: OpenStack/Swift and Nimbus/Cumulus. The real experiments were conducted, and the results assess the performance and effectiveness of ESPRESSO.

Introduction

With significant investment, many cloud storage systems are providing cloud users high data availability and the flexibility in data management, and they become the primary storage space for users' data. Thus, instead of storing and managing data in local servers, most of users nowadays are moving their data into the cloud and paying for storage and management service by a pay-per-use model. In this sense, cloud users are sharing a common storage space offered by Cloud Service Providers (CSPs). This characteristic raises several challenges which are hindering the migration of users' softwares and data into the cloud [START_REF] Imex | The Promise & Challenges of Cloud Storage[END_REF]. Among them, the security and data privacy are the most important challenges needed to be solved to attract users [START_REF] Tian | Evaluation of User Behavior Trust in Cloud Computing[END_REF]. While consumers have been willing to trade privacy for the convenience of cloud storage services, this is not the case for enterprises and government organizations. This reluctance can be attributed to several factors that range from a desire to protect mission-critical data to regulatory obligations to preserve the confidentiality and integrity of data. The latter can occur when the customer is responsible for keeping personally identifiable information (PII), or financial and medical records [START_REF] Kamara | Cryptographic Cloud Storage[END_REF]. Driven by the need to secure growing cloud data storage systems as well as high profile security breaches, data protection in cloud storage systems has become a hot topic in both academia and industry [START_REF] Factor | Secure logical isolation for multi-tenancy in cloud storage[END_REF][START_REF] Huang | YI Cloud: Improving User Privacy with Secret Key Recovery in Cloud Storage[END_REF][START_REF] Hao | The study and design on secure-cloud storage system[END_REF][START_REF] Itani | Privacy as a Service: Privacy-aware Data Storage and Processing in Cloud Computing Architectures[END_REF]. While the current approaches, which rely on a user-centric authentication service, can be broken by authentication attacks, encryption emerged as one of the most effective means to protect sensitive data no matter where it lives [START_REF] Harrin | Cloud Storage Vendors Offering Encryption as a Service[END_REF].

With an encryption tool, users can encrypt data on their local machine before uploading the encrypted data to a cloud. However, this approach introduces an additional burden for users to manage the encryption key and operate the encryption tool. Furthermore, users are required to equip local machines which are able to handle such a compute-intensive task that incurs the time overhead. These issues make the user-side encryption approach difficult to realize, especially when users are using scarce resource devices such as smartphones. A server-side encryption approach is therefore needed. On one hand, CSPs can provide the encryption to users as an added value service with minimal additional cost. On the other hand, this encryption can be offered as a free charge service. It then becomes a competitive advantage of a CSP against other CSPs to attract users and increase the CSP's reputation.

Among existing CSPs, only two commercial CSPs: Google Cloud Storage [START_REF] Google | [END_REF] and Amazon S3 [START_REF] Amazon | [END_REF] offer a server-side encryption service. However, the encryption services developed by Google and Amazon cannot be adopted by many other CSPs which want to offer the server-side encryption to users such as Microsoft Azure [START_REF]Microsoft Azure[END_REF], GoGrid [START_REF] Gogrid | [END_REF], RackSpace [13]. This observation inspires us to design and implement a standalone encryption service, ESPRESSO, for such CSPs to integrate without heavy modification and implementation of their infrastructures. Furthermore, we aim at providing a configurable and flexible encryption service for both CSPs who can choose the encryption algorithm based on their preference, and users who can specify the critical level of their data. The data with higher critical level needs to be more securely protected. Last but not least, we aim at providing ESPRESSO as a transparent encryption service which makes users perceive no difference between with and without the encryption service in terms of latency and complexity of data management operations.

The paper is organized as follows. Section 2 presents the problem statement including threat model and design goals of ESPRESSO whose the architecture is described in Section 3. Section 4 presents the detailed implementation of ESPRESSO. The integration of ESPRESSO into the Swift and Cumulus storage systems is presented in Section 5. Section 6 presents the experimental results which assess the performance and effectiveness of ESPRESSO. The related work is discussed in Section 7 followed by the conclusion of the paper in Section 8.

Problem Statement

The System and Threat Model

In this paper, we consider the CSPs which provide a data storage service. To protect the data privacy, an encryption service is used to encrypt the data before being stored in the cloud, and decrypt the data whenever users need to access the data. Depending on the deployment location of the encryption service, different threat models can be introduced. Below, three threat models will be analyzed.

1. The first model applies the user-side encryption approach. Users deploy the encryption software on their local machine and flexibly operate the service without needing to trust any third party. However, users are generally not expert in the security domain. The user's machine therefore suffers the security risks such as key exposure attacks or attacks from malicious programs. Moreover, it is not an easy task for non-expert users to take full responsibility of encryption key management such as key generation, key storage and keeping those keys always safe. Yet, if users are using scarce resource devices such as mobile devices, performing the encryption on such devices may not be possible since the encryption is considered as a compute-intensive task. 2. Users can rely on a third party who offers the encryption service. The third party takes full responsibility for managing the data encryption, protecting the encryption server and preventing the exposure of the users' encryption keys. Assuming that the encryption service is resistant to the security risks, users still have the sole concern on the adversarial behavior of the third party. With the curiosity and economic purpose, the third party might collude with malicious users to harvest data contents when it is highly beneficial [START_REF] Yu | Achieving secure, scalable, and fine-grained data access control in cloud computing[END_REF]. Moreover, this model requires further effort from users to retrieve the encrypted data to their local machine before uploading to the cloud. 3. CSPs play the role of the third party presented in the second model. CSPs deploy the encryption software on a server in its trusted domain as one of its components. Users therefore benefit all advantages but also suffer the security risks as mentioned above. The operation overhead might be lesser since users do not need to manage the encrypted data. Instead, users upload the plaintext data to the CSP who will forward the data to the encryption server to encrypt before storing the encrypted data in storage servers.

As described, each model has advantages and disadvantages. Assuming that users trust the third party in the second model and the CSP in the third model at the same level, we believe that the third model brings users the most advantages. Depending on the model, the encryption service may be designed and implemented differently to assure that it efficiently operates at high performance. We present in the next section the design goals of ESPRESSO, the encryption service for CSPs as we advocate the third model presented above.

Design Goals

Several design requirements should be carefully considered since the design directly affects the overall performance of the system.

Architectural requirements The encryption service should include two main components. The first component is the encryption key management. To increase isolation among users, a CSP may use different keys to encrypt different users' data and a user may have multiple keys for different data. To prevent leaking one's key to another, the encryption key must also be encrypted. Additionally, since the data availability is an important requirement of a cloud storage system, keys need to be replicated to be available when requested.

The second component is the data encryption management. ESPRESSO needs to provide the flexibility for both CSPs and users. Since ESPRESSO can be used by different CSPs, it should support multiple encryption algorithms. A CSP may choose its preferred algorithms to process users' data, e.g., Swift may use AES while Eucalyptus may use Blowfish. For users, the service should allow them to specify a desired critical level for their data. Currently, the CSPs, which offer server-side encryption, support only a single key length option, e.g., Google Cloud uses 128-bit keys. However, users may have different levels of security. Financial or medical records need to be more securely protected (using 256-bit keys) than entertainment data like musics or movies (using 128-bit keys).

Choosing supported encryption algorithms and critical levels of data

Given that CSPs offer different encryption algorithms and key lengths, choosing the supported encryption algorithms and critical levels of data is also important to achieve the flexibility. There exists many encryption algorithms in the literature including symmetric and asymmetric algorithms with their own advantages and disadvantages. A symmetric algorithm eases the implementation, however, it may not provide high level of security while an asymmetric algorithm is more complex to manage its key pair. Additionally, an asymmetric algorithm may take longer time for data encryption and decryption.

On the critical level of data, the longer key length is, the higher security level is guaranteed, however, it also takes longer time for encryption and decryption of data. Therefore, choosing the key length for each security level should take into account the tradeoff between the security level and the processing time.

APIs for integration to cloud storage platforms As a last requirement of ESPRESSO, a well-designed integration API is also important since this allows CSPs to integrate and to use ESPRESSO easily without heavy modification of the architecture and implementation of their infrastructure. For instance, to provide an enhanced encryption service with a flexible critical level, the critical level should be one of API parameters along with data to be stored and user identification. Depending on the design, other parameters could be added. However, they should be carefully chosen since it may be difficult for CSPs to integrate ESPRESSO with redundant parameters.

System Architecture of ESPRESSO

In this section, we first present the detailed architecture and then describe the method to handle the flexibility and support multi-user scheme in ESPRESSO. The overall architecture of ESPRESSO is depicted in Fig. 1 with two components: Data Encryption Management and Keys Management. The request flow is as follows. Universal API is the gate of ESPRESSO which can provide a wide range of interaction protocols allowing multiple CSPs to integrate ESPRESSO into their infrastructures. After receiving a request, Universal API delivers the request to Data Encryptor which is responsible for processing users' data using algorithms implemented in Encryption Algorithms. Data Encryptor requests encryption key from Keys Management through Key Generator which is the starting point of the Keys Management component. Key Generator retrieves the key stored in Encrypted Key Storage if it already exists, and sends it to Key Encryptor to decrypt using a master key. If the requested key does not exist in the database, that means the user is new on the system or the key for that specific critical level is not yet generated, Key Generator creates a new key and sends a key encryption request to Key Encryptor. The new key is then encrypted by the master key and sent back to Key Generator to store in Encrypted Key Storage. To assure the availability of encryption keys, encrypted keys are replicated and stored in Backup Keys DB.

Architecture of ESPRESSO

Handling the Flexibility and Multi-user Scheme

To provide CSPs the flexibility in choosing a preferred encryption algorithm, ESPRESSO currently supports two algorithms: AES and Blowfish which are symmetric. By choosing symmetric algorithms, we eliminate the complexity of managing encryption key pairs which are supposed to be stored on different servers. Moreover, they are less intensive than asymmetric algorithms in terms of processing time. Additional algorithms can also be integrated into the system without breaking the architecture of ESPRESSO thanks to its agile design.

On the critical level of data, ESPRESSO provides three different critical levels by using three key lengths: 128, 192 and 256 bits for all supported encryption algorithms. The longer key length guarantees the higher critical level of data. A less than 128-bit key may be broken by the modern machine while a more than 256-bit key increases the latency of the service. Thus, each user can have up to three keys corresponding to three critical levels: the highest level uses 256-bit keys and the lowest level uses 128-bit keys, respectively. For a certain user, all the data with the same critical level are encrypted by the same key. Since a CSP serves multiple users, each user is therefore identified by a user identification. We tie the user identification to the critical level and the encryption key by a tuple of < user id, critical level, key string > in the encryption key database. Additionally, keys are generated on request of the CSP for a specific user and critical level. Since the critical level parameter is needed to retrieve the encryption key for data decryption in the future; however, users may not remember which level was set for the data in the past, we include this parameter in the encrypted data. For a data retrieval request, the CSP gets the encrypted data from the storage server and passes it to ESPRESSO with the user id parameter in a decryption request. Data Encryptor first extracts the critical level parameter from the encrypted data and then invokes the decryption by calling the decrypt data function.

To provide users a friendly manner to specify the data critical level, we decode three proposed critical levels by three letters: A stands for the high level, B stands for the medium level and C stands for the low level. Theses three symbolic letters hide the complex technical details of critical levels from users who are not expert in the security domain. The CSPs integrating ESPRESSO should provide a usage guideline to make their users aware of the trade-off between the strength and required processing time of each level, i.e., A is the strongest level but it requires longer time to complete the encryption.

Encryption keys are generated by the Random library supported in Python. Each is a string including alphabet and numbers with length depending on the critical level. All keys are stored in a MySQL database whose the structure of the key table is shown in Table 1. Key Encryptor uses the same algorithm, i.e., AES or Blowfish, to encrypt the users' keys with a master key retrieved from

Algorithm 1 Encryption and Decryption calls

Input: data, user id and critical level for an encryption; encrypted data and user id for a decryption request; the ESPRESSO server address: server for both requests. Output: Encrypted data for an encryption; plaintext data for a decryption request.

1

Integration of ESPRESSO

We choose Swift [START_REF]OpenStack[END_REF] and Cumulus [START_REF] Bresnahan | Cumulus: An Open Source Storage Cloud for Science[END_REF] to integrate ESPRESSO. These systems are open-source cloud platforms and they are widely used in both research community for experimental purpose and industry for commercial purpose. The integration involves determining a proper place in the source code of the storage systems where ESPRESSO is connected by using provided APIs and adding code instructions to realize that connection. The abstract pseudocode for encryption and decryption invocations from the storage systems is presented in Algorithm 1. Its detailed implementation depends on the target systems, programming language and supported library, e.g., Swift and Cumulus use Python while Eucalyptus uses Java. Generally, since ESPRESSO is implemented as a WSGI service, when a storage server requests for an encryption, a WSGI connection will be established (line 1). User's information and the data critical level are then passed by the connection header (lines 3 -5). The data file is divided into chunks and sent to ESPRESSO (lines 6 -8). When the data transmission is completed, ESPRESSO processes the data on its side while the storage server waits for the result (line 9) and continues the process after receiving data.

Integration of ESPRESSO into Swift

The integration of ESPRESSO into Swift is presented in Fig. 2a where we add the ESPRESSO server as a novel component of the Swift platform. ESPRESSO is deployed on a separate server rather than becoming an internal component of Swift. This avoids breaking down the Swift's code structure. Since the encryption On the user's side, this integration does not complicate the data management operation. Only the uploading and updating requests require one more parameter to be added: the data critical level. For instance, if users use cURL [18] to interact with Swift for data management, the data critical level will be added as a novel header: -H 'x-critical-level:A'.

Integration of ESPRESSO into Cumulus

ESPRESSO has also been similarly integrated into the Cumulus storage system. The encryption and decryption invocations, presented in Algorithm 1 are added in the cumulus/cb/pycb/cbRequest.py module at two classes: cbGetObject(cbRequest) and cbPutObject(cbRequest). Like Swift, the total number of code lines added is less than 50 for both methods. This assesses the easy and light adoption of ESPRESSO in any cloud storage platform.

Since Cumulus supports the Amazon's S3 REST protocol, many client libraries and tools, including s3cmd [19], boto [START_REF] Boto | [END_REF] and jets3t [21] can be leveraged by Cumulus users. For instance, if user uses s3cmd, a novel header will be added to specify the data critical level: --add-header "critical-level: A".

With the integrated system, if users do not specify the critical level, ESPRESSO will automatically use the highest level, i.e., A, to encrypt the user's data.

Experiments and Performance Evaluation

Experiment Setup

The integrated storage systems were deployed using two dedicated physical servers on the same rack of the Communications & Networks Lab (CNL) at the National University of Singapore. Swift and Cumulus were installed on the server xx.xx.xx.64 and ESPRESSO was installed on the server xx.xx.xx.65. The servers are PowerEdge C6220 with Intel(R) Xeon(R) Processor E5-2640 2.50GHz, 24GB RAM. We used real data files which are downloaded from the Wikipedia archive [START_REF]Wikipedia: Wikipedia archive[END_REF]. The file size varies from several MB to 4GB that allows us to evaluate the efficiency of the encryption algorithm with different loads. Three following performance metrics were considered for evaluation:

-Latency of encryption algorithms: To show the efficiency of encryption algorithms, we measured the encryption time with different key lengths for the same algorithm. In addition, we compared the encryption time of two different algorithms with the same key length. -Latency of the integrated system with and without ESPRESSO: To show the transparency of ESPRESSO, the total operation time (i.e., sum of the data uploading time from the client to the storage server and the data encryption time) of Swift with and without ESPRESSO were compared. -Impact of network bandwidth: In this experiment, a remote client which uses the Internet backbone for transferring data was deployed. Two different network connections: WiFi and wired connection were applied.

For each experiment, we performed 5 times to measure the average and standard deviation values of performance metrics. The second and third experiments were performed on both systems. However, due to the space limit and to avoid the redundancy, only results on Swift are shown. A comparison of total operation time between Swift and Cumulus is given in the analysis of the third experiment.

Performance Analysis

Evaluation of Encryption Algorithms Fig. 3a presents the encryption latency of the AES algorithm with respect to the data size. We executed AES with three different key lengths: 128, 192 and 256 bits. It is expected that with the same key length, the larger data volume is, the longer time is needed to complete the encryption. With the largest file at 4GB, the encryption time with 256-bit key is 93 seconds. Comparing the latency of AES with three key lengths, it is trivial that the longer key needs longer time to complete, however, it generates a more robust encryption, i.e., the data is more securely protected.

We also measured the encryption time of Blowfish and observed that there is the same behavior as AES. In Fig. 3b, we present the encryption time of AES and Blowfish with respect to the data size and with the same key length, 256 bits. The results show that Blowfish needs a longer time to complete the encryption for the same data compared to that of AES. Indeed, since Blowfish uses a 64-bit block size while AES uses a 128-bit block size, the number of blocks processed by Blowfish is doubled compared to that of AES. The processing transition between blocks leads to the overhead of Blowfish. The results also show the nature of the encryption algorithms that the decryption time is almost the same as the encryption time as expected. Thus, to avoid the redundancy, we do not present the results on decryption time here.

Integrated System Validation

To validate the integrated system, we run the Swift client on a machine located in the same LAN to reduce the data transfer time between the client and Swift. The encryption algorithm is AES and the critical level is A. Fig. 4a depicts the total operation time for uploading requests of Swift with and without ESPRESSO. In the case without ESPRESSO, the total operation time can be considered as the data transfer time from the client to the Swift server. It is expected that the total operation time of Swift with ESPRESSO is longer than that without ESPRESSO since an additional time is needed for data encryption. This overhead includes data transfer time from Swift to ESPRESSO, the encryption time and the transfer time from ESPRESSO back to Swift for resulted data. In the worst case, the total operation time increases 63.95%. The details of the encryption time overhead are presented in Fig. 4b. While the data transfer time between the Swift and ESPRESSO servers is small and not affected by other users since the servers are installed on the same rack, the encryption time dominates when the file size is large, i.e., larger than 3.5GB. Even though we assume 4GB files as the worst case scenario, which roughly corresponds to the total content of a single-sided DVD, one may have larger files to store. However, the results show that it is strongly discouraged to store large files to not significantly degrade the performance of the system.

Impact of Network Bandwidth

In practice, users are not always located nearby the cloud. Therefore, the data transfer time from the user's location to the cloud is much larger than that presented in previous experiment. Indeed, we did the third experiment by running the client machine locating 3 kms from the Swift/Cumulus servers, using the Internet backbone for transferring data. In Fig. 5a, we present the total operation time of Swift for uploading requests when the client uses the WiFi and wired connection. The average uploading speed is 1.54 Mbps and 6.72 Mbps, respectively. The results show that the data transfer time from the client to the Swift server dominates in both connections. With the largest file with the WiFi connection, the total operation time is 37.45 mins while the encryption time overhead is only 2.75 mins, corresponding to 7.34% of the total operation time. From the point of view of a user who is sensitive with the latency, he may still not accept such overhead. However, considering the security aspect that the user's data is securely protected by CSPs, we believe that the cost represented by the time overhead is worth for such a security service. Fig. 5b presents the comparison of operation time between Swift and Cumulus when the remote client uses wired connection. The operation times of both systems are almost the same. While Swift needs longer time for replicating the data with 3 copies, Cumulus does not provide the replication service. However, this overhead on Swift is compromised by the fluctuation of the data transfer time.

Related Work

Most of literatures on data encryption have focused on providing a user-side encryption tool which allows the owner to share his data with different consumers. [START_REF] Kang | Identity-based Authentication in Cloud Storage Sharing[END_REF] proposed an Identity-Based Authentication scheme by which the owner can share his encrypted data stored in the cloud. In [START_REF] Huang | YI Cloud: Improving User Privacy with Secret Key Recovery in Cloud Storage[END_REF], YI Cloud, a framework for protecting the data privacy in the cloud, is presented. The framework includes two components: a client component which is deployed on the user's machine for encryption and key management, and a server component installed on Sector [START_REF] Gu | Sector and Sphere: The Design and Implementation of a High Performance Data Cloud[END_REF] for management of users and storage nodes. Both [START_REF] Huang | YI Cloud: Improving User Privacy with Secret Key Recovery in Cloud Storage[END_REF] and [START_REF] Kang | Identity-based Authentication in Cloud Storage Sharing[END_REF] did not provide the flexibility for providers and users as ESPRESSO did.

In [START_REF] Zhao | Trusted Data Sharing over Untrusted Cloud Storage Providers[END_REF], a progressive encryption system has been proposed based on Elliptic Curve Cryptography. The system allows the owner to share his encrypted data with other consumers without revealing the plaintext data to untrusted entities. The work did not present any real experiment but we believe that this approach involves an intensive computation, thus introduces high latency. Furthermore, [START_REF] Zhao | Trusted Data Sharing over Untrusted Cloud Storage Providers[END_REF] focused on the encryption algorithm and the sharing mechanism while we aim at providing an entire encryption service which can be adopted by any existing CSP. Similarly, [START_REF] Yu | Achieving secure, scalable, and fine-grained data access control in cloud computing[END_REF] proposed a secure and scalable fine-grained data access control scheme for cloud computing by combining attribute-based encryption with techniques of proxy re-encryption and lazy re-encryption. Both [START_REF] Yu | Achieving secure, scalable, and fine-grained data access control in cloud computing[END_REF] and [START_REF] Zhao | Trusted Data Sharing over Untrusted Cloud Storage Providers[END_REF] considered a different threat model where users do not trust any third party such as cloud providers. Hence, users must take full responsibility for the data encryption and key management on their local machines.

In [START_REF] Itani | Privacy as a Service: Privacy-aware Data Storage and Processing in Cloud Computing Architectures[END_REF], the authors presented PasS (Privacy as a Service), a set of security protocols for ensuring the privacy of data stored in the cloud. Although presenting a server-side encryption service, this work assumed that the encryption service is maintained by a third party that is trusted by users as well as CSPs. Instead of trusting the third party, CSPs can integrate ESPRESSO as a security component in their infrastructures. Thus, they can increase the reputation and help cloud users alleviate the security concerns with the third party.

Conclusion and Future Work

We proposed ESPRESSO, a standalone and transparent encryption service for cloud storage systems. It provides CSPs the flexibility of choosing their preferred encryption algorithm by supporting two algorithms: AES and Blowfish. With the flexible design, CSPs can easily integrate ESPRESSO without heavy modification and implementation of their infrastructures. ESPRESSO provides users three data critical levels which allow users to specify an appropriate level of their data. The integrated system does not require much effort from users to make their data protected. The experiments on the Swift and Cumulus storage systems show that the introduced encryption latency is negligible compared to the total operation time of a data management request. All these advantages assess the effectiveness of ESPRESSO to be integrated into any CSP on the production level. The work can be extended to support data-owner and dataconsumer schemes. The access control will be used to handle access permission and an encryption key for each consumer. While we focused only on protecting the backup data in this paper, a secured computation could be considered since the data stored in the cloud can be also used for further computation. However, tackling secured computation properly would require a paper by its self to do justice to the issues involved. Thus, we address this issue in a future paper.

Fig. 1 :

 1 Fig. 1: ESPRESSO overall architecture.

Fig. 2 :

 2 Fig. 2: Integration of ESPRESSO into cloud storage platforms.and decryption happen only when users have downloading, uploading or updating requests which correspond to GET and PUT methods in the RESTful API supported by Swift, all of modifications were made to the swift/proxy/controllers/obj.py module in the proxy server at two functions: GET(self, req) and PUT(self, req).On the user's side, this integration does not complicate the data management operation. Only the uploading and updating requests require one more parameter to be added: the data critical level. For instance, if users use cURL[18] to interact with Swift for data management, the data critical level will be added as a novel header: -H 'x-critical-level:A'.

  key length 192-bit key length 128-bit key length (a) Encryption time of AES.

  AES vs. Blowfish.

Fig. 3 :

 3 Fig. 3: Performance of encryption algorithms.

  Details of the encryption time.

Fig. 4 :

 4 Fig. 4: Uploading time with/without ESPRESSO and details of encryption time.

  Swift vs. Cumulus performance.

Fig. 5 :

 5 Fig. 5: Total uploading time from a distant client to Swift and Cumulus.

Table 1 :

 1 Structure of the encryption keys table in MySQLWe use Python to implement ESPRESSO based on its broad adoption and efficiency. We implement in Universal API the Web Server Gateway Interface (WSGI) which allows CSPs to deploy ESPRESSO as a WSGI service. The implementation of Universal API handles the WSGI requests, i.e., extracting user id, critical level and data, and converts them to internal requests which are then forwarded to Data Encryptor. There are two functions in Data Encryptor: encrypt data and decrypt data. The encrypt data function, which has three parameters: user id, critical level and data, prepares the encryption. It includes instructions for requesting the encryption key from Key Generator, initializing the encryption algorithm instance and finally invoking the execution of the encrypt data function implemented in Encryption Algorithms. The algorithm se-

	Field	Type	Description
	key id	Integer	Key identification: auto increment field
	user id	String	User identification
	critical level Character Critical level of user's data
	key string String	Key string for encryption and decryption.
	4 Implementation of ESPRESSO

lected by the CSP is saved in an INI configuration file with simple format, for example, [algorithm]name = AES. Instead of implementing all encryption algorithms by ourselves, we use a library namely PyCrypto

[START_REF] Litzenberger | PyCrypto[END_REF]

which provides the implementation of various algorithms such as AES, DES, RSA and ElGamal.

  Master Key. The implementation of Encrypted Key Storage and Encrypted Key Replicator handles the interaction with MySQL database, i.e., formulating the SQL query statements and executing the query.

	: connection = HTTPConnection(server); /*Create an HTTP/HTTPS connection*/
	2: connection.putrequest('EN', "); /*'EN' for encryption and 'DE' for decryption*/
	3: for header in headers do /*Send all HTTP headers: user id, critical level*/
	4:	connection.putheader(header name, header value);
	5: end for
	6: for chunk in data do /*Send data by chunks*/
	7:	connection.send(chunk);
	8: end for
	9: response = connection.getresponse(); /*Waiting for response*/
	10: Extract encrypted data or plaintext data from the response;
	11: return

Acknowledgements

This work is supported by A*STAR SERC from the project entitled "Towards Designing Flexible, Cost Effective, Secured Service Provisioning Strategies for Heterogeneous Data Centres in a Cloud-of-Clouds infrastructure" (Grant No. 112 280 4009), and A*STAR TSRP from the project entitled "Secured Large Scale Shared Storage System" (DSI/11-200006).

/ decryption requests/stores encrypted keys replicates encrypted keys updates DB updates DB


Elisa Maini

Antonio Manzalini

Management and Orchestration of Virtualized Network Functions

Software Defined Networking (SDN) and Network Function Virtualization (NFV) paradigms are driving a number of research activities aiming to develop virtual network infrastructures where Network Functions (NF) and services could be executed as applications in ensemble of virtual machines. This paper addresses the problem of managing and orchestrating said highly dynamic networks, where virtualized NFs and resources are created and destroyed depending on traffic demands, service requests, or other high-level governance goals such as the reduction of energy consumption.

Introduction

In the current networks most NFs (from layer 4 to layer 7) are provided by a number of middle-boxes. These nodes are based on closed software solutions running on specialized hardware representing a significant part of the Operational EXpenditures (OPEX) and CAPital EXpenditures (CAPEX) of network operators due to the management effort (e.g. for configuration) that they require [START_REF] Manzalini | Manifesto of Edge ICT Fabric[END_REF], [START_REF] Manzalini | Software Networks at the Edge: a shift of paradigm[END_REF], [START_REF] Manzalini | Clouds of Virtual Machines at the Edge[END_REF], [START_REF] Manzalini | Nechifor et all Self-optimized Cognitive Network of Networks[END_REF]. In principle, SDN and NFV are likely to offer the possibility to develop all NFs, e.g., middle-boxes, in open source software executed in standard hardware. If on one side, Future Networks will rely more and more on such software, which will, in turn, accelerate the pace of innovation and will reduce costs, on the other side, management and orchestration will be the true challenge. Automated operation processes (e.g. configuration of network and service equipment) could limit human intervention also wrong operations and a flexible and optimal provisioning of NFs and services could reduce equipment costs and allows postponing network investments. In this direction, SDN and NFV should be equipped with solid management and orchestration features, capable of automating networks and services operations. These paradigms will largely exploit virtualization technologies for sharing and aggregating resources, and for decoupling and isolating virtual network elements from the physical network. Further, the abstraction of virtualized network elements will enable and simplify the programmability of the network, increasing networking capabilities, allowing innovative service offerings: nevertheless this will increase also the overall management complexity of virtual NFs and virtual resources [START_REF] Galis | Softwarization of Future Networks and Services -Programmable Enabled Networks as Next Generation Software Defined Networks[END_REF], [START_REF] Galis | Software Enabled Future Internet -Challenges in Orchestrating the Future Internet[END_REF]. In the following paper, we give an overview of the main research and challenges for the management and orchestration of virtualized NFs and, we provide an architectural solution for the placement of the virtual resources. As proof of these concepts, some preliminary results are provided.

Concepts and technical challenges

Each Virtual Network (VN) is viewed as a managed network service by the management software [START_REF] Clayman | Monitoring Aggregation and Filtering for Efficient Management of Virtual Networks[END_REF]. All managed network services are mapped to the available resources which allows users of the network service to access it, just like they would access a physical network service. For full operation of the managed network services, the management and orchestration needs to ensure that each VN has the following attributes:

separation: network functions and the network infrastructure are kept separate. A VN of a service needs to be separated from the infrastructure used by an infrastructure provider, similarly to the manner in which a virtual compute environment is separated from the physical host; isolation: a VN of one service is isolated from all other VN services. Isolated VN services need to be offered side by side while sharing network resources of the infrastructure provider; elasticity: a VN can grow or shrink as necessary. A VN service needs to enable network elasticity; federation: a VN can span over more than one domain. An interchangeable VN service needs to be offered across local areas such that network service consumers would not be concerned by the area of the infrastructure location, the physical network used, or its configuration.

Based on the previous description, the management and orchestration component should: a) use adaptive and autonomic methods and systems for automatic management NFs applied not only to the physical resources, but also virtual resources located inside the physical/virtual resources; b) optimize the allocation and orchestration of virtual resources for dynamically instantiating, orchestrating and migrating multiple virtual machines across networks and service infrastructures.

To fulfill the latter, the next section provide a high-level description of a distributed orchestrator prototype.

Architecture and experimental results

The architecture depicted in Figure 1, is based on an orchestrator that ensures the automatic placement of the virtual routers and the allocation of the network services on them, supported by a monitoring system which collect and reports on behavior of the resources involved. The orchestrator manages the creation From an architectural viewpoint, NFs and services can be defined as a number of software components with their accompanying context together with configuration parameters. The provisioning of a service involves the creation of a IT infrastructure, followed by the installation of all necessary software components into the infrastructure, and finally configuring and starting those components. With SDN and NFV these processes can be simplified as the infrastructure provides a platform from which virtual machines can be run. SDNs can be directly manifested as virtual network topologies which need to be setup, have a managed lifecycle, and need to be shutdown -all under software control.

The architecture involves a Global Controller, in other words a distributed management infrastructure that has centralized functionality and it is responsible for the setup, configuration, optimization, and shutdown of the network entities. It takes input from various Management Applications regarding various requirements (e.g. network resources or response time) and then configures the network nodes through a set of Local Controllers. In order to manage the challenging and dynamic infrastructures of virtual networks there needs to be a monitoring system (Monitoring Manager) which can collect and report on the behavior of both the physical resources (e.g. cpu usage, memory usage) and the virtual resources (e.g. utilization level of the virtual links). These monitoring data items are sent to the Global Controller so that it can use the monitoring information in order to make decisions regarding network strategies. In particular, it may decide to add new nodes in order to fulfil the high-level policies and goals which are network operator requirements. In this way, the virtual network topology changes dynamically according to the network virtual resources usage.

The Placement Engine is the component in charge of performing the actual placement of the virtual routers according to the initial topology and the usage of the virtual network elements. This is an important feature because, when we configure a network, considering some initial information, some of these parameters may change during the course of the system's operation and a reconfiguration may be required to maintain optimized collection of information. The decision of the Placement Engine is encoded in an algorithm which can be rather simple, such as counting the number of virtual routers on a host, or it can be based on a set of constraints (e.g. the usage of the virtual links) and policies that represent the network properties. Also, the Placement Engine may be able to utilize or share some algorithmic elements from computer cloud placement algorithms such as [START_REF] Breitgand | SLA-aware Placement of Multi-Virtual Machine Elastic Services in Compute Clouds[END_REF] and [START_REF] Breitgand | Improving Consolidation of Virtual Machines with Riskaware Bandwidth Oversubscription in Compute Clouds[END_REF].

Figure 2 provides some experimental results achieved using the Very Lighweight Network and Service Platform (VLSP) testbed [START_REF] Clayman | User Space Routing[END_REF]. It shows the number of virtual routers allocated on each host (shown on the y-axis) versus the time of the experimental run (shown on the x-axis). The hosts: host 1, host 2 and host 3 are represented by blue, green and yellow lines respectively. Here, we present two different placement algorithms: the algorithm used in Figure 2(a) is a kind of load balancing algorithm as it tries to get a similar number of routers on each host. The algorithm used in Figure 2(b) tries to determine the host that is least busy in terms of virtual network traffic. More details are explained in [START_REF] Clayman | The Dynamical Placement of Virtual Network Functions[END_REF].

Conclusion and prespectives

In this paper, we have argued the main research directions for the management and orchestration of virtualized NFs and services in Future Networks and provided an architectural description of our orchestrator prototype. The results presented here demonstrate that different embedded algorithms in each of the Placement Engines give very different placement strategies for the virtual routers. In future work will be considered other placement algortitms, which we expect to get more complex and to encapsulate multiple metrics.

Fig. 2 :

 2 Fig. 2: Behaviour of different placement algorithms


Leonhard Nobach

David Hausheer

Towards Decentralized, Energy-and Privacy-Aware Device-to-Device Content Delivery

Keywords: Device-to-Device, Content Delivery, Privacy, Energy, Decentralization, Delay-Tolerance, Opportunistic Networking

Device-to-Device (D2D) content delivery is a new approach to directly exchange content between mobile devices, which allows to offload traffic from infrastructure-based networks and thus reduces the risk of congestion. While centralized D2D approaches rely on the mobile operator to discover nearby devices and initiate a content transfer, in decentralized D2D the devices autonomously and opportunistically organize themselves to deliver content to each other. The latter approach is more flexible as it does not depend on a single operator, however, it typically requires more energy for scanning other devices. Another issue is privacy, since the decentralized approach reveals a user's interest for content to all devices in proximity. Therefore, this paper sketches an new approach towards decentralized energy-and privacy-aware D2D content delivery. The proposed approach addresses the energy loss that occurs when constantly and spontaneously scanning multiple unknown devices for content. Furthermore, the paper identifies privacy requirements and proposes first steps towards a privacy-aware D2D solution.

Introduction

As people are sharing more higher-resolution multimedia content, traffic demand in the Internet is constantly increasing. Today, content is transferred mostly from a content provider's server to a consumer's device. Different types of content delivery can be distinguished: Live content is immediately consumed after creation, including a short transmission delay. On-Demand delivery refers to content that is commonly consumed an arbitrary but significant amount of time after creation, whenever a particular consumer requests it. For example, most of the web content is delivered this way. Video-on-Demand (VoD) services deliver movies and video clips on request, which are typically very bandwidth-intensive. Although less bandwidth-consuming, music, applications and software updates are also content types appropriate for on-demand delivery.

Delivering copies of content to a large number of receivers is challenging in terms of network load. Many carriers use IP Multicast to deliver live content to their own customers. However, in the current public Internet, multicast is not widely implemented between carriers. For on-demand content delivery, multicasting is not applicable, as content has to be delivered to every consumer by the time of request. Content Delivery Networks (CDNs) place replica servers in proximity of the access network, which offloads the content provider's uplink and inter-carrier transits. However, the consumer's access network itself is typically not affected by the traffic reduction.

Device-to-Device (D2D) content delivery transmits content from a consumer's mobile device directly to another one in range. This way, infrastructure utilization is reduced especially for the transfer of popular content in crowded areas. Also, the quality of experience (QoE) can be increased in case of bandwidthlimited infrastructures. D2D content delivery only is effective if a certain device density and content popularity is given. If there are few devices in range or the content is unpopular, chances are high that there is no device in range serving the content. D2D content delivery mechanisms can be distinguished by the type of content discovery mechanism used.

Centralized D2D content discovery [START_REF] Bao | DataSpotting: Offloading Cellular Traffic via Managed Device-to-Device Data Transfer at Data Spots[END_REF] [2] [START_REF] Golrezaei | Wireless Video Content Delivery through Distributed Caching and Peer-to-Peer Gossiping[END_REF] relies on the cellular operator locating content in range and triggering the transfer between devices. For that, an operator requires data like the position as well as information about available and requested content. In contrast, a decentralized [START_REF] Ma | A Cooperative Cache-based Content Delivery Framework for Intermittently Connected Mobile Ad Hoc Networks[END_REF] mechanism lets the devices organize the discovery and transfer of relevant content themselves. Such an operator-independent service, when standardized, is available to and communicates with every device, not only the devices under contract with the operator. Furthermore, it can even work in the absence of a mobile infrastructure.

However, current link-layer protocols widely implemented in consumer electronics (e.g., IEEE 802.11 [START_REF]Technology -Telecommunications and Information Exchange between Systems -Local and Metropolitan Area Networks -Specific Requirements -Part 11: Wireless[END_REF]) are focused on low-delay and reliable communication between devices previously known to each other. Using the default 802.11 MAC layer, discovering content on any device currently in range involves an exchange of multiple management frames and unnecessarily frequent medium listening (ATIM window), leading to an increased energy consumption. Additionally, requesting content by broadcasting leads to an unintended disclosure of user interest to all devices in communication range. Attackers may also flood requests for privacy-sensitive content and track devices answering it. Previous approaches did not investigate how these issues can be mitigated, except that they switched to a centralized, operator-dependent solution [START_REF] Bao | DataSpotting: Offloading Cellular Traffic via Managed Device-to-Device Data Transfer at Data Spots[END_REF] [2] [START_REF] Golrezaei | Wireless Video Content Delivery through Distributed Caching and Peer-to-Peer Gossiping[END_REF].

Based on this finding, the goal of this work is to propose a new operatorindependent approach towards D2D content delivery between mobile devices, while addressing energy-efficiency and privacy, starting at the link layer. The remainder of this paper is structured as follows. In Section 2, a modification of the 802.11 data link layer for energy-efficient, opportunistic content discovery is sketched. Also, the aforementioned privacy concerns are addressed and first countermeasures are proposed. Moreover, Section 3 discusses related work, while Section 4 concludes this paper.

Energy-and Privacy-Aware Content Discovery

The proposed discovery mechanism follows a single hop D2D approach. While content delivery can also be done over multiple hops, for the purpose of stability, medium availability, energy conservation, and the lack of incentives for intermediate nodes, this approach is not considered here. The discovery mechanism involves two roles, a content requester (CR) and a content provider (CP), where a device can take both roles at the same time. The CR maintains a predicted table of content identifiers likely to be consumed in the future, while the CP maintains a cache of provided content. Prediction and caching strategies are not part of this paper.

As the devices are previously unknown to each other, they communicate by broadcasting link-layer frames in their proximity, either content requests (active) or content advertisements (passive). The frames contain a list of content identifiers. To be able to receive each other's frames, devices must agree on certain physical parameters like the 802.11 channel and rate, which may be done at roll-out time. In order not to drain the battery, the opportunistic broadcast mechanism works without any previous device scanning, participating in distributed beaconing, or handshake. Instead, a broadcast is only answered by CPs providing (active) or CRs requesting (passive) the particular content, other devices remain silent upon reception. This certainly involves changes in IEEE 802.11's MAC Sublayer Management Entity (MLME) [START_REF]Technology -Telecommunications and Information Exchange between Systems -Local and Metropolitan Area Networks -Specific Requirements -Part 11: Wireless[END_REF]. The changes must not interfere with standard 802.11 operation.

Conserving energy also incorporates the decision when to power on and off the transmitters, referred to as sleep scheduling. Increased wake-up intervals and smaller wake-up periods may conserve energy, but also increase the delay as messages have to stay longer in the buffer to wait for the next wake-up. Fortunately, such a wait-to-send delay in the area of seconds is not a concern for decentralized content discovery. Instead, finding a good way to synchronize these wake-up periods between devices that are spontaneously in contact to each other is a major challenge. An approach suitable to this problem would lead to synchronized listen-sleep periods as depicted in Figure 1.

To increase privacy of the discovery mechanism, two approaches are proposed. First, a clear-text identifier is replaced with a hash-salt combination, where the salt changes in every request. This way, only devices in possession of the content identifier understand the request. Secondly, the usage of anonymous addresses in wireless media hardens the tracking of devices. Therefore, MAC addresses used for opportunistic requests can be randomly chosen and frequently changed.

Related Work

Golrezaei et al. [START_REF] Golrezaei | Wireless Video Content Delivery through Distributed Caching and Peer-to-Peer Gossiping[END_REF] investigate an approach for distributed caching. Although they first propose to establish femtocells controlled by small base-station-like nodes called helpers, they later consider a pure D2D communication system where the mobile devices play the helper role themselves. In the latter, the D2D exchange is completely controlled by the operator, which knows the device's position, as well as the content that is currently cached by every device. Bao et al. [START_REF] Bao | DataSpotting: Offloading Cellular Traffic via Managed Device-to-Device Data Transfer at Data Spots[END_REF] [2] propose a centralized mechanism, where the network operator tracks the location of mobile devices. The operator then identifies areas with a high device density (data spots). Whenever a certain density is given, content requests are mediated by the operator, which initiates a WiFi connection between the requester and a device in proximity having the desired content.

An approach for decentralized content discovery was proposed by Ma and Jamalipour [START_REF] Ma | A Cooperative Cache-based Content Delivery Framework for Intermittently Connected Mobile Ad Hoc Networks[END_REF]. Evaluated costs are focused on bandwidth consumption and disk space. Nevertheless, optimizing energy consumption was not addressed, although this has been done for Bluetooth [START_REF] Wang | Opportunistic Energy-efficient Contact Probing in Delay-Tolerant Applications[END_REF] [START_REF] Drula | Adaptive Energy Conserving Algorithms for Neighbor Discovery in Opportunistic Bluetooth Networks[END_REF].

Boldrini et al. [START_REF] Boldrini | ContentPlace: Social-Aware Data Dissemination in Opportunistic Networks[END_REF] exploit a user's social relationship to decide where to place content. Cost evaluations concern limited bandwidth and cache. Distributed sleep synchronization for energy conservation in MANETs has been addressed by Jiang et al. [START_REF] Jiang | Quorum-based Asynchronous Power-Saving Protocols for IEEE 802.11 Ad Hoc Networks[END_REF], as well as Choi et al. [START_REF] Choi | Adaptive Asynchronous Sleep Scheduling Protocols for Delay Tolerant Networks[END_REF], but these approaches are not focused on broadcast discovery between devices previously unknown to each other.

In the area of privacy, much research has been done and is underway in the area of opportunistic networks (ONs) [START_REF] Lilien | Opportunistic Networks: The Concept and Research Challenges in Privacy and Security[END_REF], but regarding content delivery in ONs, very few exist. Privacy was addressed by Shikfa et al. [START_REF] Shikfa | Privacy in Content-based Opportunistic Networks[END_REF], given prior key distribution and using intermediate nodes.

Summary and Future Work

In this paper, a new approach towards decentralized D2D content delivery has been proposed. The operator-independent approach shows clear advantages as it even works in the absence of an infrastructure. Moreover, the paper sketched a solution how energy and privacy issues can be mitigated.

To identify the situations in which D2D content delivery is effective, likely urban environments with a high device density and providers of popular content, request and position traces of a large cellular operator will be evaluated. In addition, user incentives for providing content via D2D communication have to be provided. Mechanisms to measure D2D contribution and possible rewards have to be designed. Furthermore, the approach sketched in Section 2 will be further developed to a complete protocol. The last steps towards a solution include an energy-and mobility-aware simulation and a prototype implementation. In parallel, social-content interdependencies and their exploitation will be investigated.

Fig. 1 .

 1 Fig. 1. Expected result of sleep scheduling for broadcast messaging. Devices power on at the same time, broadcast content requests in this time window and power off again.

This work has been supported in parts by the European Union (FP7/#317846, SmartenIT and FP7/#318398, eCousin) and the German DFG (CRC 1053, MAKI).


João Marco
email: joaomarco@di.uminho.pt

C Silva

Paulo Carvalho

Solange Rito Lima
email: solange@di.uminho.pt

A modular architecture for deploying self-adaptive traffic sampling

Traffic sampling is seen as a mandatory solution to cope with the huge amount of traffic traversing network devices. Despite the substantial research work in the area, improving the versatility of adjusting sampling to the wide variety of foreseeable measurement scenarios has not been targeted so far. This motivates the development of an encompassing measurement model based on traffic sampling able to support a large range of network management activities, in a scalable way. The design of this model involves identifying sampling techniques through its components rather than a closed unit, allowing to address issues such as flexibility, estimation accuracy, data overhead and computational weight within a narrower and simpler scope. This paper concretises these ideas presenting a modular and self-configurable measurement architecture based on sampling, a framework implementing sampling inherent pieces, and provides first results when deploying the proposed concepts in real traffic scenarios.

Introduction

Performing network measurement tasks in today's networks is a continuous challenge attending to the massive traffic volumes involved, to the wide range of possible monitoring objectives to fulfill, sometimes in a near real-time basis and requiring minimal interference with the normal network operation. Aiming at efficient network measurements, traffic sampling techniques are broadly deployed in strategic network nodes, generically called measurement points (MPs). Their main objective is to select a subset of packets which will then be used to estimate network parameters, avoiding processing all network traffic [START_REF] Zseby | Sampling and Filtering Techniques for IP Packet Selection RFC 5475[END_REF], with the potential cost of affecting measurement accuracy [START_REF] Estan | New directions in traffic measurement and accounting[END_REF].

Despite the substantial research work on packet sampling [START_REF] Tammaro | Exploiting packet-sampling measurements for traffic characterization and classification[END_REF] [8] [START_REF] Zseby | Packet Sampling for Flow Accounting: Challenges and Limitations[END_REF], choosing the best sampling technique depends on traffic characteristics or statistics needed by applications [START_REF] Duffield | Sampling for Passive Internet Measurement: A Review[END_REF]. Moreover, most proposals are focused on specific network measurement tasks, aiming at increasing the accuracy estimation of a single network metric or a small set of metrics, which, in turn, may increase the consumption of computational resources (e.g., CPU, memory and storage capacity).

In this way, the lack of an encompassing traffic sampling architecture able to map a large range of network management measurement needs in a scalable and autonomous way, yet attending to existing computational resources constraints, is evident. Knowing that distinct sampling techniques lead to different computational weight and accuracy levels for each metric estimation, this paper proposes a modular and self-adaptive architecture able to accommodate the selection and configuration of sampling techniques according to the requirements of the network task and resources available.

Measurement Architecture

A self-adaptive sampling-based measurement architecture is envisioned as comprising three planes, as illustrated in Figure 1. The management plane includes tasks deployed directly in MPs or in external management entities (such as in Software-defined Networking approaches). Based on specific requirements of each network task, measurement needs are identified, one or more MPs are selected, and the most suitable sampling technique is chosen and configured. This also involves identifying an information model able to define managed objects in the network, as suggested in [START_REF] Dietz | Definitions of Managed Objects for Packet Sampling -RFC6727[END_REF].

The management plane is also responsible for providing the self-adaptive behavior of the model. Adaptiveness is ruled by a function which, in runtime, balances estimations accuracy and the corresponding computational weight. Taking a set of thresholds for CPU load, memory and data storage consumption, combined with the expected relative error of the metric estimation, the function is able to determine whether to maintain the current sampling technique (and settings) or to introduce a lighter and/or more accurate technique (based on the ongoing requirements and computational constraints).

The sampling plane consists mainly of a modular sampling framework able to assist the deployment of current and future sampling approaches, which fragments the sampling techniques into well-defined components according to sampling granularity, selection scheme and selection trigger. Then, each component is further divided into a set of approaches that, once combined, may allow deploying sampling policies in a flexible and scalable way, as illustrated in Figure 1. In brief, these components are: (i) granularity -identifies the atomicity of the element under analysis in the sampling process: in flow-level approach, the sampling process is only applied to packets belonging to a flow or to a set of flows of interest; in a packet-level approach, packets are eligible as single independent entities; (ii) selection scheme -identifies the function defining which traffic packets will be selected and collected; this scheme may follow a deterministic, a random or an adaptive function; and (iii) selection trigger determines the spatial and temporal sample boundaries, may use a time-based approach, a count-based approach or an event-based approach.

To support adaptiveness, a profiler module (resources analyzer) monitors the resources consumption in runtime, reporting the current status to the management plane, which will decide on maintaining the sampling policy or setting a new one regarding the measurement needs and resource constraints. A new policy may correspond to a new sampling technique or just a change in the configuration parameters, e.g. reducing the sample frequency.

An IPFIX [START_REF] Boschi | IP Flow Information Export (IPFIX) Implementation Guidelines -RFC5153[END_REF] module is responsible for the communication between the management plane and the sampling plane, receiving the sampling settings from the management plane. This module also receives the sampled packets from the network plane, processing them and aggregating relevant fields according to the network task. The aggregation and exporting processes follow IETF guidelines [START_REF] Trammell | Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol -RFC7015[END_REF] [6] and include results from the resource analyzer, which will then be used for self-adaptation.

At network plane, traffic is collected from network interfaces by applying the sample rules defined in the sampling plane. Unprocessed sampled packets are subsequently reported to the sampling plane to be processed, simplifying the network plane.

Ongoing works and results

According to the measurement architecture, presented in Figure 1, the sampling framework and the resource analyzer were developed in Java using libpcap1 , and deployed in a low-cost, open computing device currently used in measurement architectures [START_REF] Young | Archipelago measurement infrastructure[END_REF]. The methodology of tests resorts to a quantitative comparison between the computational burden of multiple sampling techniques and policies in presence of similar workloads. The purpose of this comparison is to provide an initial understanding with regards to the relationship between computational requirements and accuracy as afforded by the various sampling techniques. This will facilitate the design of an efficient adaptive module, based on suitable thresholds for specific measurement needs and resource constraints.

Traffic scenarios consist of three workload periods (low, moderate and high) in the network backbone of University of Minho, Portugal along a typical workday, as shown in Table 1. Due to privacy policies only https traffic was collected, then submitted to different sampling techniques deployed in the sampling framework, i.e., SystC -Systematic count-based [START_REF] Zseby | Sampling and Filtering Techniques for IP Packet Selection RFC 5475[END_REF], SystT -Systematic time-based [START_REF] Zseby | Sampling and Filtering Techniques for IP Packet Selection RFC 5475[END_REF], RandC -Random countbased [START_REF] Zseby | Sampling and Filtering Techniques for IP Packet Selection RFC 5475[END_REF], LP -Adaptive linear prediction [START_REF] Hernandez | Adaptive Sampling for Network Management[END_REF] and MuST -Multiadaptive sampling [START_REF] Silva | A multiadaptive sampling technique for cost-effective network measurements[END_REF].

As shown in Figure 2 Despite the importance of reducing the computational burden of traffic sampling, sampling techniques must still be able to represent the network behavior accurately. Table 1 presents the accuracy results per technique when estimating two metrics useful for traffic characterization, such as mean throughput and number of flows. The results show that the higher storage requirement of SystT delivers a better accuracy in flow identification. Regarding throughput, the relative mean error (RME) is low for all scenarios and techniques (less than 10%). Exceptions are: (i) MuST technique applied to high workload, achieving a significant low error (less than 1%); and (ii) RandC technique applied to moderate workload, with a relative error above 10%. These preliminary results evince the relevance of tuning traffic sampling (choosing technique, configuration parameters and thresholds), in order to meet distinct measurement requirements and constraints. The present research work proposing a modular and self-adaptive measurement architecture will allow enlarging the scope and efficiency of network measurement tasks through traffic sampling.

Low Moderate High

Fig. 1 .

 1 Fig. 1. Architecture description

  (a), SystC and MuST require lower CPU consumption, being MuST less demanding during the most critical work scenario. Regarding memory usage, Figure 2(b) demonstrates similar behavior across all techniques and workload scenarios. The volume of data involved in the sampling process (see Figure 2(c)) is higher for the SystT technique, contrarily to SystC and RandC. Assuming that the computational resource consumption of systematic techniques is proportional to the sampling frequency, Figure 2(d) presents the mean resource consumption for distinct sampling frequencies for SystC technique when applied to the high workload scenario.

Fig. 2 .

 2 Fig. 2. Overall results

http://www.tcpdump.org/

Acknowledgements -This work has been supported by FCT -Fundação para a Ciência e Tecnologia in the scope of the project: PEst-OE/EEI/UI0319/2014.


Jeremy Van Den Eynde

Chris Blondia
email: chris.blondia@uantwerpen.be

Vandeneynde

Cross-layer Optimization with Real-time Adaptive Dynamic Spectrum Management for Fourth Generation Broadband Access Networks

The upcoming fourth generation of broadband access systems (4GBB) needs to address data rates of up to 1 Gbit/s over twistedcopper pairs. Physical layer techniques like dynamic spectrum management (DSM) aid in increasing the data rate by optimizing the space and frequency domain. However, there is room for improvement in the time dimension that both physical and upper layers can use to their advantage. This paper proposes a bidirectional cross-layer approach to optimize DSM using techniques like scheduling and statistical multiplexing, to mitigate crosstalk, the dominant cause of signal degradation. This in turn should lead to better data rates, more stable networks, and "greener" devices.

Introduction

Driven by the emergence of evermore requiring broadband services such as ebusiness, cloud computing, IPTV and video-conferencing the needs for reliable and fast broadband internet access has become essential to life quality, efficiency and organizations. Quality of service (QoS) requirements for these applications become quite challenging, and thus it is important to improve broadband technologies.

The intermediate step to a global fiber-to-the-home (FTTH) instalment, is the hybrid fiber -copper telephone wires, using the existing telephony DSL infrastructure for the so called last mile, identified as the fourth generation broadband (4GBB) access network [START_REF] Odling | The fourth generation broadband concept[END_REF][START_REF] Van Den Brink | Enabling 4gbb via the last copper drop of a hybrid ftth deployment. Broadband[END_REF]. Increasing VDSL2's datarates (of up to 100 mbit/s) to 1 Gbit/s over these copper wires proves a significant challenge. One of the wireline techniques used to boost data rates is dynamic spectrum management (DSM) [START_REF] Song | Dynamic spectrum management for next-generation dsl systems[END_REF]. DSM is developed as a means to solve the crosstalk problem. As twisted-copper pairs of different users are merged inside large cable bundles, electromagnetic coupling between neighbouring pairs leads to signal leakage in other users' signals. This is called cross-talk, and is currently the major cause of performance degradation in DSL transmission [START_REF] Cendrillon | Improved linear crosstalk precompensation for dsl[END_REF][START_REF] Zeng | Crosstalk identification in xdsl systems. Selected Areas in Communications[END_REF].

Despite the word dynamic in DSM, the configuration remains static over time. And thus the time-domain is left unexploited. As the worst-case scenario is envisioned, the settings are very conservative and there is much to gain by taking this dimension into account.

Therefore, we investigate the concept of real-time adaptive DSM, which takes the short time-scale changing environment and requirements into account when calculating the power configuration. This leads to new mechanisms to improve transmission, energy efficiency (e.g. using low-power modes), and stability of the overall network.

However, the physical layer does not have the information that allows for this real-time adaptation and the upper layers could optimize more using physical layer information, hence the need for a cross-layer approach. Cross-layer refers to the exchange of knowledge between layers of the Open Systems Interconnection (OSI) model [START_REF] Bertsekas | Data networks[END_REF], a layered abstraction of the networking protocol stack (e.g. [START_REF] Srivastava | Cross-layer design: a survey and the road ahead[END_REF])

In our envisioned model there is a mutual influence between the physical layer and the upper layers (layer two and up). For example, telephony requires a very reliable and constant bit rate (CBR), while web traffic is of highly bursty nature, can cope with loss but needs to be responsive, and background traffic has high bandwidth requirements but does not suffer from delays. This valuable upper layer information can steer the physical layer into assigning three channels with different data and bit-error rates. The physical layer in its turn can report crosstalk, or share common time-frequency slots with other users, to which the upper layers, such as the scheduler, can make decisions.

The goal of this research is the development of a bidirectional cross-layer real-time adaptive DSM optimization framework for mitigating crosstalk by exploiting the time-dimension.

Approach

In this research we will investigate the upper layers and work in close collaboration with a researcher that looks at the physical layer optimizations.

The first step in tackling the problem consists of defining a framework with scope, and constructing a multi-layer system model that allows for cross-layer optimization. It includes determining the degrees of freedom and mechanisms, parameters and metrics that can be used for uni-or bidirectional cross-layer optimization.

Metrics of interest include the delay, delay variation, loss, Quality of Experience (QoE), power usage and retransmission probability. Not all metrics will apply for all traffic. E.g. some traffic does not suffer from large delay variation.

Most literature considers a unidirectional information exchange. Linking the several layers with a bidirectional channel results in new possible optimizations. This increase of degrees of freedom might result in unmanageable complexity. Restricting parameters or the degrees of freedom help in handling this. Determining the optimal power configuration, for example, is exponential in complexity [START_REF] Vangorp | Optimal spectrum balancing in multi-user xdsl systems with on/off power loading[END_REF]. Limiting the update frequency and set of possible bandwidths can alleviate this.

Upstream and downstream have to be treated differently: the latter can be managed centrally as all information is readily available. The upstream traffic, on the other hand, can not be coordinated locally, and thus information exchange with the central office has to be taken into account.

The second phase will focus on the development of a cross-layer optimization approach for the system model.

Main topics of interest here for the upper layer are scheduling and statistical multiplexing. Statistical multiplexing is the merging of several flows such that the required bandwidth is less than the sum of the required bandwidths of the individual flows. Huang [START_REF] Huang | Statistical multiplexing over dsl networks[END_REF] shows that this can lead to impressive performance gains in cross-layer settings. Multiplexing has to be considered in a centralized cross-layer setting taking all users into account as there is a positive correlation between crosstalk and data rates in a cable bundle. Furthermore, predicting data and channel behaviour over a short time horizon can enhance the allocation of physical resources and allow for using low power modes, such as stable sleep [START_REF] Kamitsos | Stable sleeping in dsl broadband access: Feasibility and tradeoffs[END_REF].

The final step comprises a complete and realistic 4GBB simulator with crosslayer optimizations. Using realistic stochastic and worst-case channel models it will be possible to evaluate QoS performance statements, and identify constraints related to the time dimension such as delay, delay variation, retransmission probability and overhead of the upstream communication. The simulation will then be used to compare different scenarios against the G.fast standardization [9].

Current State

The current model consists of four building blocks: the application manager, the scheduler, admission control and operational controller. They are depicted in Figure 1 together with possible interactions and an example frequency-time slot mapping, the configuration of bits on the wire. Upon a new flow requesting access, the application manager translates this request to a long term traffic descriptor, and probes the admission control for a suitable physical layer configuration. If found the scheduler is updated to support the new flow. The scheduler selects packets for transmission for each traffic class (of which there are high reliability CBR, high reliability VBR, interactive traffic, background and multicast VBR). Each of these packets is then mapped to a timefrequency slot, guided by the operational controller. The operational controller uses convex programming to minimize power usage and maximize the frequencytime slot assignment in function of application requirements over all users.

Application Manager Operational Controller Admission Control Scheduler

Related Work

Previous research is mainly focused on unidirectional cross-layer optimization. For example [START_REF] Gürbüz | Scheduling for next generation wlans: filling the gap between offered and observed data rates[END_REF] takes channel state and queue length into account to schedule for optimal throughput. However, the physical layer does not take any of the upper layers' information into account.

Most literature dealing with cross-layer optimization can be found in the wireless network area [START_REF] Gürbüz | Scheduling for next generation wlans: filling the gap between offered and observed data rates[END_REF][START_REF] Yu | Multicell coordination via joint scheduling, beamforming and power spectrum adaptation[END_REF][START_REF] Chiang | Layering as optimization decomposition: A mathematical theory of network architectures[END_REF][START_REF] Lin | A tutorial on cross-layer optimization in wireless networks. Selected Areas in Communications[END_REF][START_REF] Fu | Decomposition principles and online learning in crosslayer optimization for delay-sensitive applications[END_REF][START_REF] Van Der Schaar | Cross-layer wireless multimedia transmission: challenges, principles, and new paradigms[END_REF]. Approaching DSL as a multi-user system, rather than isolated wires, results in similarities between wireless and DSL, and hence allows us to make use of these results. They are different enough (e.g. mobility, MAC, hidden terminal problem . . . ) that results can not be used directly.

Cross-layer design, such as [START_REF] Lin | A tutorial on cross-layer optimization in wireless networks. Selected Areas in Communications[END_REF][START_REF] Chiang | Layering as optimization decomposition: A mathematical theory of network architectures[END_REF], focuses on the principles of decomposition and will be of value for our research.

Relating to the second phase, C ¸iftçioglu [START_REF] Gürbüz | Scheduling for next generation wlans: filling the gap between offered and observed data rates[END_REF] proposed a predictive block scheduler for a wireless system model. Our aim is to improve this model for a wired setting and provide a more general cross-layer framework.

In contrast to other literature, the FAST copper project [START_REF] Chiang | Fast copper for broadband access[END_REF] focuses on improving DSL. It considers four dimensions: frequency (physical layer allocation), amplitude (shaping at edge), space (network architecture and topology) and time (multiplexing). Whereas FAST focuses on optimizing network performance, we will optimize only the last mile by exploiting the time dimension (scheduling, multiplexing, traffic prediction), and focusing on the QoE.

Preliminary Conclusions and Future Work

This paper presented an approach to developing a cross-layer optimization with real-time adaptive DSM for 4GBB. Incorporating the time dimension, mechanisms like scheduling and statistical multiplexing will allow us to mitigate crosstalk, a major source of signal degradation, leading to better data rates, greener devices and more stable networks.

Future work will focus on a more tight collaboration of the physical layer and upper layers, iterative upgrading of the framework and performing simple simulations to evaluate metrics, continuing along the path as in section 2.

Acknowledgement

This work is supported by funds from Research Foundation Flanders (FWO). The authors would like to thank Marijn Scheir for the collaboration.

Fig. 1 .

 1 Fig. 1. Model, interactions and frequency-time slot mapping