Bruno Rodrigues

Thomas Bocek

Andri Lareida

David Hausheer

Sina Rafati

Burkhard Stiller
email: stiller@ifi.uzh.chhausheer@ps.tu-darmstadt.de

A Blockchain-based Architecture for Collaborative DDoS Mitigation with Smart Contracts

Keywords: Distributed Denial-of-Service (DDoS), Security, Blockchain, Software-defined Networks (SDN), Network Management

The rapid growth in the number of insecure portable and stationary devices and the exponential increase of traffic volume makes Distributed Denial-of-Service (DDoS) attacks a top security threat to services provisioning. Existing defense mechanisms lack resources and flexibility to cope with attacks by themselves, and by utilizing other's companies resources, the burden of the mitigation can be shared. Emerging technologies such as blockchain and smart contracts allows for the sharing of attack information in a fully distributed and automated fashion. In this paper, the design of a novel architecture is proposed by combining these technologies introducing new opportunities for flexible and efficient DDoS mitigation solutions across multiple domains. Main advantages are the deployment of an already existing public and distributed infrastructure to advertise white or blacklisted IP addresses, and the usage of such infrastructure as an additional security mechanism to existing DDoS defense systems, without the need to build specialized registries or other distribution mechanisms, which enables the enforcement of rules across multiple domains.

Introduction

In the past years, a rise in DDoS attacks could be observed [START_REF]Akamai: How to Protect Against DDoS Attacks -Stop Denial of Service[END_REF]. DDoS attacks have the simple goal of interrupting or suspending services available on the Internet and its motivations range from personal grudges over blackmail to political reasons [START_REF] Mansfield-Devine | The Growth and Evolution of DDoS[END_REF]. A recent example is an attack conducted against Domain Name System (DNS) servers responsible for domains such as Twitter, PayPal, and Spotify [START_REF]Hackers Used 'Internet of Things' Devices to Cause Friday's Massive DDoS Cyberattack[END_REF] in October 2016. As a consequence, those services became unavailable to many US (United States) users for several hours. Besides the frequency, also the strength and duration of DDoS attacks are growing making them more efficient and dangerous. One reason for the increasing size of attacks is the availability of many reflectors, and i.e., weakly secured or configured IoT (Internet of Things) devices or home gateways [START_REF]Hackers Used 'Internet of Things' Devices to Cause Friday's Massive DDoS Cyberattack[END_REF].

By exploiting legal services on those devices, e.g., the Simple Service Discovery Protocol, the power of a DDoS attack is amplified, and the problem of defense is made more complicated. Thus, the impact of DDoS varies from minor inconvenience to severe financial losses for enterprises that rely on their online availability [START_REF] Peng | Survey of network-based defense mechanisms countering the dos and ddos problems[END_REF]. Various mitigation techniques have been proposed. However, only a few have been considered for widespread deployment because of their effectiveness and implementation complexities. An ongoing IETF (Internet Engineering Task Force) proposal discusses the development of a collaborative protocol called DOTS (DDoS Open Threat Signaling) to advertise DDoS attacks [START_REF] Nishizuka | Inter-organization cooperative ddos protection mechanism[END_REF]. However, this paper proposes an infrastructure of blockchains and smart contracts, which provide the required instrumentation without the need to maintain design and development complexities of such a new protocol.

As with a different direction, the adoption of DDoS protection services, offered by companies such as Akamai [START_REF]Akamai: How to Protect Against DDoS Attacks -Stop Denial of Service[END_REF] or CloudFlare [START_REF] Cloudfare | Cloudflare advanced ddos protection[END_REF], is increasing [START_REF] Jonker | Measuring the Adoption of DDoS Protection Services[END_REF]. Those cloud-based solutions can absorb DDoS attacks by increasing capacity and taking the burden of detection away from the device under attack by exporting flow records from edge routers and switches. Additional analysis is performed in the cloud and packet filtering is used to balance, reroute, or drop the traffic inside the cloud. However, those solutions requires a third party DDoS Protection Service (DPS) provider, which is implying in additional costs and a decrease in service performance. This paper presents the architecture and design of a collaborative mechanism using smart contracts and investigates the possibility of mitigating a DDoS attack in a fully decentralized manner. Thus, service providers interested in shared protection, can not only signal the occurrence of attacks but also share detection and mitigation mechanisms. The objective is to create an automated, and easy-to-manage DDoS mitigation. Three major building blocks are identified to build such a mechanism.

Blockchains and Smart Contracts. This approach proposes an architecture and an implementation of an approach to signaling white or blacklisted IP addresses across multiple domains based on blockchains and smart contracts. The advantage of using smart contracts in a blockchain is: (a) to make use of an already existing infrastructure to distribute rules without the need to build specialized registries or other distribution mechanisms/protocols, (b) to apply rules across multiple domains, which means that even if the AS (Autonomous System) of the victim is not applying these rules, some traffic can still be filtered, and (c) the victim or its AS can control which customers get blocked. The only central element remaining is to show proof of IP ownership.

Software-defined Network (SDN) is an effective solution to enable customizable security policies and services in a dynamic fashion. The centralized network control and its deployment based on the OpenFlow [START_REF] Mckeown | Openflow: enabling innovation in campus networks[END_REF] protocol facilitates the enforcement of high-level security policies moving away from current approaches based on SNMP (Simple Network Management Protocol) and CLI (Command Line Interface). With SDN, flow-rules can be applied to block DDoS attacks, and the closer these rules are applied, and those malicious packets can be dropped, the less DDoS traffic occurs. This work uses SDN-based networks as a use case to perform in a more rapid fashion in ASes the definition and verification of flows to mitigate DDoS attacks. However, the presented solution is not limited to the usage of an SDN-based network, being compatible with detection/monitoring tools able to export attack information to be published in the blockchain.

This paper is structured as follows. Section 2 introduces basic concepts and related work on blockchain and smart contracts. Section 3 presents related collaborative DDoS mitigation strategies. Section 4 presents the architecture detailing its components and basic functioning, as well as describing the implementation details of the proposed solution. Section 5 provides a discussion on the development and results obtained so far. The work is concluded in Section 6 highlighting the significant contributions and discussing future work.

Background

Smart contracts are a piece of software made to facilitate the negotiation or performance of a contract, being able to be executed, verified or enforced on its own. A smart contract alone is not "smart" as it needs an infrastructure that can implement, verify, and enforce the negotiation or performance of a contract by particular computer protocols. It has gained attention in the context of blockchains that provide a fully decentralized infrastructure to run, execute, and verify such smart contracts [START_REF] Bocek | Smart Contracts -Blockchains in the Wings[END_REF]. Therefore, smart contracts need to run on a blockchain to ensure (a) its permanent storage and (b) obstacles to manipulate the contracts content. A node participating in the blockchain runs a smart contract by executing its script, validating the result of the script, and storing the contract and its result in a block.

Although the Bitcoin [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF] blockchain was the first fully decentralized distributed ledger, it is primarily designed for transfer of digital assets, and it is not Turing-complete (e.g., it does not support loops). Such a Turing-complete contract language allows defining rules to allow or block IP addresses that can be interpreted by an SDN controller. While several projects try to address these issues, the Ethereum [START_REF] Wood | Ethereum: A secure decentralised generalised transaction ledger[END_REF] blockchain is the most popular that supports a Turingcomplete contract language, empowering more sophisticated smart contracts. In Ethereum, smart contracts run in a sand-boxed Ethereum Virtual Machine (EVM) and every operation executed in the EVM has to be paid for to prevent Denial-of-Service (DoS) attacks.

SDN characteristics provide better network visibility by decoupling the control plane from the data plane and by the centralized management to perform tasks such as network diagnosis and troubleshooting [START_REF] Kreutz | Software-defined networking: A comprehensive survey[END_REF]. In addition to SDN, the OpenFlow protocol [START_REF] Mckeown | Openflow: enabling innovation in campus networks[END_REF] leverages network management by providing a programmable and standardized interface between the data plane and the control plane. It has been recognized that the decoupling of the data plane and the control plane makes SDN a promising solution to enable the enforcement of customizable security services and policies. Various SDN-based solutions have been proposed to deal with DDoS attacks [START_REF] Zhang | Cooperative defence against ddos attacks[END_REF]. A survey on these issues is provided in [START_REF] Scott-Hayward | Sdn security: A survey[END_REF]. However, each security/concern category can be sub-divided in fine-grained aspects e.g., authentication, integrity, network communications. In the following are presented mainly research efforts addressing DDoS attacks in SDN networks.

To analyze the impact of DDoS attacks on network performance, the works in [START_REF] Shin | Attacking software-defined networks: A first feasibility study[END_REF] and [START_REF] Kandoi | Denial-of-service attacks in openflow sdn networks[END_REF] have shown how such attacks may impact on several parameters like the control plane bandwidth (i.e., controller-switch channel), latency, switches flow tables and the controller performance. Other works as [START_REF] Wei | Flowranger: A request prioritizing algorithm for controller dos attacks in software defined networks[END_REF] and [START_REF] Dao | A feasible method to combat against ddos attack in sdn network[END_REF] use the SDN capabilities to implement schemes that allow to detect and mitigate DDoS attacks through packet analysis and filtering. These solutions reduce the impact of attacks, but they may cause an overhead in the flow-tables and the SDN controller. Also, they do not provide any solution to address these particular SDN performance issues as proposed in [START_REF] Dridi | Sdn-guard: Dos attacks mitigation in sdn networks[END_REF] (e.g., flow-tables, and controller overloading). Furthermore, they also do not consider DDoS attacks and the collaboration with AS customers as [START_REF] Sahay | Towards autonomic ddos mitigation using software defined networking[END_REF].

SDN-based solutions allow greater agility to enforce decisions that require a global network view. Therefore, intra-domain security policies and mechanisms to prevent and react to DDoS attacks can be made agiler. By combining the intra-domain capabilities provided by SDN and the inter-domain advantages provided by blockchains and smart contracts, the efficiency to mitigate DDoS attacks in both inter-and intra-domains can be improved.

Related Work

There are four broad categories of defense against DDoS attacks according to [START_REF] Peng | Survey of network-based defense mechanisms countering the dos and ddos problems[END_REF]: (1) attack prevention, (2) attack detection, (3) attack source identification, and (4) attack reaction.

(1) Tries to prevent attacks before they become a problem, i.e. as close to the sources as possible. The obvious method to achieve this for amplified or reflected attacks is for the access provider to filter spoofed packets; (2) Can be a difficult task since certain attacks mask themselves as legitimate user traffic or use various traffic types. Due to this complexity, it can be hard to make a confident decision if traffic is part of an attack or special user behavior, e.g. a flash crowd; (3) Is applied after an attack was detected. This step is important to efficiently contain or re-route the attack as close to its source as possible; (4) The final step involves taking concrete measures against the attack. The better the result from (3) the more efficiently this can be done.

Among the collaborative DDoS mitigation techniques, there are two main approaches using resource management to react against bandwidth attacks [START_REF] Peng | Survey of network-based defense mechanisms countering the dos and ddos problems[END_REF]. The first takes effect within the victim's domain and the second within the domain of the victims ISP, i.e. the AS. Both techniques apply traffic classification and define specific actions for those classes. Both customer and AS resource management schemes need to classify traffic into several types, and then treat them differently. However, it is rather difficult to give an accurate classification as DDoS attacks can mimic any legitimate traffic. In this regard, some sophisticated techniques can be implemented to classify traffic, but a unified reaction strategies implemented both at the AS and the customer can be more efficient than applying just one.

Other works exist for cooperative defense against DDoS attacks. However, it is still an open issue since DDoS attacks are growing in scale, sophistication, duration and frequency [START_REF] Mansfield-Devine | The Growth and Evolution of DDoS[END_REF]. The IETF is currently proposing a protocol [START_REF] Nishizuka | Inter-organization cooperative ddos protection mechanism[END_REF] called DOTS (DDoS Open Threat Signaling) covering both intra-organization and inter-organization communications to advertise attacks. The protocol requires servers and clients DOTS agents, which can be organized in both centralized and distributed architectures to advertise black or whitelisted addresses. A DOTS client should register to a DOTS server in advance sending provision and capacity protection information and be advertised of attacks. Then, the DOTS protocol is used among the agents to facilitate and coordinate the DDoS protection service as a whole. Also, a similar approach to the IETF proposal is presented in [START_REF] Steinberger | Collaborative ddos defense using flow-based security event information[END_REF]. The authors use a similar architecture but using an advertising protocol based on FLEX (FLow-based Event eXchange) format, which is used to simplify the integration and deployment of the solution and facilitate the communication process between the involved domains.

The proposed standard advertises the need for defensive measures in anticipation of or response to attack. The main drawback compared to the approach presented herein is the requirement of additional infrastructure requiring trust and collaboration between ISPs. A collaborative defense approach using VNF (Virtual Network Functions) is presented in [START_REF] Rashidi | Cofence: A collaborative ddos defence using network function virtualization[END_REF]. The authors propose a cooperation between domains that implements VNFs to alleviate DDoS attacks by redirecting and reshaping excessive traffic to other collaborating domains for filtering. In [START_REF] Zhang | Cooperative defence against ddos attacks[END_REF], a gossip-based communication mechanism is proposed to exchange information about attacks between independent detection points to aggregate information about the overall observed attacks. The system is built as a peer-to-peer overlay network to disseminate attack information to other listening users or systems rapidly.

A similar approach was presented in [START_REF] Velauthapillai | Global detection of floodingbased ddos attacks using a cooperative overlay network[END_REF], formalizing a gossip-based protocol to exchange information in overlay network using intermediate network routers. A different approach is presented in [START_REF] Sahay | Towards autonomic ddos mitigation using software defined networking[END_REF], which proposes a collaborative framework that allows the customers to request DDoS mitigation from ASes. However, the solution requires an SDN controller implemented at customer side interfaced with the AS, which can change the label of the anomalous traffic and redirect them to security middle-boxes. In the approach presented in this paper cus-tomers and ISPs can take action to mitigate an attack by interfacing directly with a blockchain providing the necessary trust.

Instead of making use of an existing infrastructure such as the blockchain and smart contracts, approaches mentioned above proposes the development of specific gossip-based protocols. In this sense, the deployment and integration of such solutions become complex since existing solutions need to be modified to support these protocols. The IETF proposal focuses on standardizing a protocol to facilitate its deployment. However, its implementation complexity still exists in distributed and centralized architectures to support the different types of communication. Instead, some of the requirements can be inherited from the natural characteristics of blockchains, smart contracts, and SDN, avoiding the complexities of development and adoption of new protocols.

Proposed System Architecture

This section presents the design principles considered in the architectural design. First, Section 4.1 exemplifies a deployment scenario. Section 4.2 provides a detailed description of its main components. Implementation details are presented in Section 4.3.

Application Scenario

A scenario is presented in Figure 1 illustrating the system architecture. A web server hosted at AS C is under a DDoS attack from devices hosted at various domains (ASes A, B, and C). With a non-collaborative DDoS mitigation approach, the web server relies on defense mechanisms that are implemented at the AS where it is allocated, which in many cases may be distant from the origin of the attack traffic and therefore overloading several domains with attack traffic.

Participants of the collaborative defense (ASes and customers) first need to create a smart contract, that is promptly linked with a registry-based type of smart contracts. Therefore, when attackers overload web server, the customer or the AS under attack stores the IP addresses of attackers in the smart contract. In an Ethereum blockchain a new block is created every 14 seconds, so subscribed ASes will receive updated lists of addresses to be blocked and confirm the authenticity of the attack by analyzing the traffic statistics and verifying the authenticity of the target's address.

Once other ASes retrieve the list of attackers and confirm the attack, different mitigation strategies can be triggered according to the security policies and mechanisms available in the domain. Also, it can block malicious traffic near of its origin. Near-source, defense is ideal for the health of the Internet because it can reduce the total cost of forwarding packets which, in the case of DDoS attacks mostly consist of useless massive attack traffic [START_REF] Nishizuka | Inter-organization cooperative ddos protection mechanism[END_REF].

In scenarios involving multiple domains, once collaborative defense nodes receive information about attacks, these can apply mitigation actions in agreement with their security policies. In this sense, an incentive mechanism is necessary to prevent domains from abusing cooperative defense.

Architectural Design

As DDoS attacks continue to increase and vary in their patterns, the need for coordinated responses also increases to detour the attacks efficiently. However, it is important to note that only the collaboration between customers and ASes is an additional approach to existing defense mechanisms. The architecture depicted in Figure 2 is composed of three components:

-Customers: may report white or blacklisted IP addresses to the Ethereum blockchain via smart contracts; -ASes: may publish white or blacklisted IP addresses and retrieve lists containing the published IP addresses, and may implement their DDoS mitigation mechanisms; -Blockchain/Smart Contract: the public Ethereum blockchain (Ethereum Virtual Machine nodes) running Solidity smart contracts, which comprises the logic to report IP addresses in the blockchain.

The architecture is built considering the following principles:

(1) DDoS detection and mitigation countermeasures are provided as on-demand services by either the ASes or third-party services; To mitigate DDoS attacks (1) different techniques can be used upon the detection by ASes or customers, which typically involves analyzing Internet traffic with sophisticated attack detection algorithms, followed by filtering. In this regard, a collaborative approach decreases the overhead of such algorithm in the detection phase using information from other domains. Blockchain DDoS Mitigation appliances (2) both on the customer and ASes are simpler as Ethereum is public and already available technology, which can be used to perform rapid and widespread DDoS advertisement using smart contracts. Services with challenge/response authentication can be utilized by an AS to ensure that the IP address (3) of the customer reporting the attack is the customer under attack, and to enforce the necessary countermeasures (4) by the security policies implemented in the domain.

The smart contract logic illustrated in Figure 3 is deployed as a complementary solution to existing DDoS mitigation mechanisms. However, domains implementing the system should consider the principles mentioned above in its design. First, any domain (e.g., customers or ASes) participating must create Fig. 3. Proposed System Flowchart a smart contract identified with an IP address or range of addresses certified by an authority. Then, the smart contract is registered in a registry-based type of smart contract so that participation can be easily tracked and thus relevant smart contracts can be identified.

Traffic arriving at both the customer and AS can be analyzed and filtered using existing monitoring tools (e.g., NetFlow, sFlow, custom SDN implementations). The Blockchain appliance can be deployed as an additional security feature to any system that implements an apparatus to advertise black or whitelisted IP addresses to the blockchain. The analysis of traffic in a gateway is facilitated by SDN, and therefore the approach is intended to use a monitoring framework based on the OpenFlow protocol.

Implementation Details

Listing 1.1 and 1.2 outlines current implemented features of the smart contract to store source IP addresses that should be blocked or allowed. For simplicity, only IPv4 addresses are shown here. Either the customer or the AS can create the smart contract. In any case, a certificate of IP ownership is required. For the customer, the certificate can be created with an automated challengeresponse system, while the AS requires a certificate matching their entry in the AS registration.

The one that created the smart contract (owner of the account that created the contract) can add other addresses that are also allowed to add IPs to block. Before such address is added, it is checked if the address matches its parent subnet. Both AS and the customer can store src IP with an expiration time. The time is measured in blocks, and the access to the stored data is public and can be viewed by anyone.

Before retrieving a list of IP pairs (source/destination), the verifyIP() function needs to be called to make sure that the target IP address has a proof of ownership. The issuing of a certificate (certOwnerIPv4) is the only remaining central entity in the architecture. After that, any AS (does not need to be the customers AS) can use these IPs to block traffic on its network.

The smart contract needs first to register itself in another smart contract Registry, which stores all relevant smart contracts that should be watched. Thus an AS listens for these changes, and any addition can be monitored and assessed against the network properties of the AS and apply a blocking rule if necessary.

Discussion

The use of the Ethereum Virtual Machine (EVM) allows the multiple domains involved in an attack scenario to invoke functions in a smart contract reporting attacks or maintaining a list of trusted addresses to be operating in case of attack. The support of white or blacklisted IP addresses is a decision that depends on the policies and security mechanisms available in each domain. Therefore, the smart contract was developed to support both lists using a flag indicating which type of address is being reported. The existing and distributed storage infrastructure reduces the complexity in the development and adoption of the approach as it supersedes the design and standardization process of a gossip-based protocol, which needs to be embraced by the various ASes and customers. Also, the EVM smart contracts support in a decentralized and native way the logic to control who is reporting an attack and who are the attackers.

Through a high-level comparison with the ongoing IETF proposal (the DOTS protocol) [START_REF] Nishizuka | Inter-organization cooperative ddos protection mechanism[END_REF], instead of making use of an existing infrastructure such as the blockchain and smart contracts, the IETF proposes from scratch the development of such protocol with several requirements (e.g., extensibility, resilience) to be deployed in a distributed architecture. In this sense, the protocol development becomes complex since it must be deployed in distributed and centralized architectures to support different types of communication (inter and intra domain, i.e, inside the domain of an AS and between ASes). Instead, it is argued that some of the requirements can be inherited from the natural characteristics of blockchains, smart contracts and SDN, avoiding the complexities of development and adoption of new protocols.

However, this smart contract works well for a small number of attacks, while for large-scale attacks, the approach is currently costly the contract size, but will be addressed this issue in a future work to make reference to a larger list of IP addresses. Therefore, to keep the complexity of the architecture low, only the data (e.g., IP addresses) should be stored in the contract, and it may become necessary to add a reference as shown in Listing 1.3, where the full list of addresses can be retrieved. The cost of adding 50 source IPs directly in a freshly deployed contract is 2.5 mio gas (gas is the internal pricing for running a transaction or contract in Ethereum) at the current gas price [START_REF] Fund | Ether unit converter[END_REF] of 20 gwei, which is 0.05 ETH at the current market price of 9.3 USD is in total 0.46 USD, while 100 source IPs cannot be mined in one contract and multiple contracts have to be used as it exceeds the 4 mio gas limit. This paper proposes a collaborative architecture using smart contracts and blockchain to enable DDoS mitigation across multiple domains. As a distributed and primarily public storage, the blockchain determines a straightforward and efficient structure to develop a collaborative approach toward DDoS attacks mitigation. The proposed architecture can be deployed as an additional security mechanism to existing DDoS protection schemes. Therefore, it is not intended to dictate how security mechanisms and policies should be implemented in a particular domain. Instead, it can be combined with existing solutions to reduce the DDoS detection and mitigation overhead by involving multiple domains in the process. Coupled with current solutions, the DDoS detection and mitigation overhead process comprising multiple domains can be reduced.

The architecture enables ASes to deploy their DPS and generate added value for their customers without transferring control of their network to a third party. The main contributions of this new approach are summarized as (a) the design and development of an architecture based on blockchains to advertise DDoS attacks across multiple domains, (b) the adoption and integration of the approach is facilitated since Ethereum and smart contracts are publicly available, and the ability to enforce rules on the ASes-side by the use of SDN, (c) can be utilized as an additional security mechanism without modifying existing ones.

Future work will investigate ways to compress the list, e.g., with a bloom filter, and its advantages and disadvantages. Another limitation is that blocking of destination IPs should be possible only for static IPs. Thus, automated services issuing these certificates of IP ownership need to check for dynamic IPs first, e.g., using services such as SORBS (dul.dnsbl.sorbs.net). Also, the current smart contract supports only one hierarchy. Thus, createCustomerCertIPv4() in Listing 1.1 needs to be extended to allow more hierarchies to map subnets accordingly.

Another major factor towards the practicability of the approach is the fairness among the cooperative domains. If an AS is targeted more times than others, means that one would be using resources of others to protect themselves. Therefore, this relevant aspect will be detailed in a future work to propose a reputation scheme based on the participation of the domains in the cooperative architecture.

Fig. 1 .

 1 Fig. 1. Application Scenario

Fig. 2 . 2 )

 22 Fig. 2. Proposed System Architecture


Markus Knecht

Burkhard Stiller

SmartDEMAP: A Smart Contract Deployment and Management Platform

Smart contracts on a blockchain behave exactly as specified by their code. To be sure that a smart contract behaves as expected, the end-user has to either analyze its code or trust a potentially anonymous developer or auditor to do so. This approach proposes a smart contract deployment and management platform that can execute development tools and code quality tools in a trusted way and uses this to reduce the trust required into the smart contract developer or auditor. Additionally, such a platform can provide new capabilities for developers aiding them in the creation of smart contracts.

Introduction

Smart contracts are programs which run in a trusted execution environment provided by a blockchain [START_REF] Vitalik Buterin | A Next-Generation Smart Contract and Decentralized Application Platform[END_REF]. The code of smart contracts can dictate how valuable assets, associated with a smart contract, are handled. A flaw in the code can lead to the loss or theft of the handled assets [START_REF] Vessenes | Deconstructing theDAO Attack: A Brief Code Tour[END_REF]. Developing bug-free software is challenging even for skilled professionals [START_REF] Anand | Software Crisis[END_REF]. Programming languages and tools like formal verification or automated tests can support that process. Before a smart contract is trusted with assets, such as cryptocurrency coins or a ownership certificate, it must be ensured that the code implements the expected and specified behavior. A end-user can ensure this by analyzing the code, by trusting the developer to have implemented the specified behavior, or by trusting an auditor to verify that the code implements the specified behavior. Analyzing the code is not an option for most end-users, because of the complexity of the task as well as the required time.

This paper proposes SmartDEMAP a smart contract deployment and management platform which reduces the trust required into smart contract developers and auditors by imposing restrictions on the smart contracts that can be deployed on it. The restrictions are enforced by executing formal verifiers [START_REF] Edstroem | Safer smart contracts through type-driven development[END_REF][START_REF] Bhargavan | Formal Verification of Smart Contracts: Short Paper[END_REF], compilers, automated bug-finders [START_REF] Luu | Making Smart Contracts Smarter[END_REF], or other development and code quality tools on smart contracts. Such restrictions could consist of a formal proof of some specified properties, enforcing a programming language, or requiring a negative result from an automatic bug finder. SmartDEMAP can reduce the trust needed into third parties, without requiring expertise in software auditing.

SmartDEMAP allows to run development and code quality tools in a trusted way to do deploy-time and run-time checks to increase smart contract quality and robustness. To accelerate the integration into the development process, we propose to develop a custom smart contract programming language that is aware of the existence of SmartDEMAP. Such a language can generate code that facilitates the provided functionality and gives a developer easy access to it. Existing languages can integrate SmartDEMAP by providing libraries to interact with it.

Hypotheses

An investigation into the current state of smart contract development has shown that there currently is a high risk for end-users when interacting with smart contracts, as shown by the "The DAO" incident [START_REF] Vessenes | Deconstructing theDAO Attack: A Brief Code Tour[END_REF], where an attacker exploited a bug to steel 3.6 million in ether. The following hypotheses are premises for developing and analysing SmartDEMAP. In the project it should be researched how well these premises can mitigate the respective risks.

Hypothesis 1: A platform on the blockchain, which provides access to trusted execution of development and code quality tools, enables the development of smart contracts which can manage, verify, and analyze the code of other smart contracts in order to increase their robustness as well as reducing the trust required in developers and auditors.

Sub-hypothesis 1.1: The ability to associate attributes with a smart contract based on a trusted analysis of its code, where the results can be queried and analyzed by other smart contract or external sources, enables the detection of misbehaving smart contracts.

Sub-hypothesis 1.2: A smart contract that controls the compilation and deployment of other smart contracts by using development and code quality tools, allows a developer to add new features or bug fixes to a smart contract after it has been deployed, without the need for end-users to trust the developer.

Sub-hypothesis 1.3: A custom smart contract programming language with the ability of accessing code analysis at run-time can prevent certain exploits.

Related Work

There are two categories of work related to SmartDEMAP. On one hand there are smart contract specific development and code quality tools including programming languages. On the other hand there is research on how resource intensive computations can be executed in a trusted way despite the resource limitations of smart contract enabled blockchains [START_REF] Vitalik Buterin | A Next-Generation Smart Contract and Decentralized Application Platform[END_REF][START_REF] Wood | Ethereum: A Secure Decentralised Generalised Transaction Ledger[END_REF].

For the tools it is important that they work in a reliable way and can not be fooled by a fine tuned input. If a compiler guarantees a certain semantic which do not hold in the generated byte code, then a trusted execution of the compiler will not help either. An earlier Solidity version had such a problem [START_REF] Reitwiessner | Security Alert Solidity Variables can be overwritten in storage[END_REF]. Formal verification [START_REF] Edstroem | Safer smart contracts through type-driven development[END_REF][START_REF] Bhargavan | Formal Verification of Smart Contracts: Short Paper[END_REF] and automatic bug-finding [START_REF] Luu | Making Smart Contracts Smarter[END_REF] are other relevant research topics for SmartDEMAP. Research into these topics is relatively new and the developed tools are not in wide use and geared more towards trained professionals.

SmartDEMAP could change that by allowing users not trained in these tools to still benefit from their results.

Theoretical results already exist concerning the execution of complex computations in a way, such that the results can be trusted [START_REF] Canetti | Practical Delegation of Computation Using Multiple Servers[END_REF][START_REF] Jain | How to verify computation with a rational network[END_REF]. Their currently is a project developing a concrete implementation [START_REF] Teutsch | A scalable verification solution for blockchains[END_REF] based on the theoretical foundations from [START_REF] Canetti | Practical Delegation of Computation Using Multiple Servers[END_REF][START_REF] Jain | How to verify computation with a rational network[END_REF], and will allow smart contracts to trigger a trusted computation and access the result.

One part of the current research promises new tools that can be used to improve the development process and reduce the exploit-ability of smart contracts. Another part promises ways to run complex computations in a trusted way, which can be utilized during the execution of smart contracts. There is no research investigating if and how these two approaches could be combined. SmartDEMAP will close that research gap.

Smart Contract Exploits

In recent years, different exploits have been found which are usable against some of the existing smart contracts [START_REF] Luu | Making Smart Contracts Smarter[END_REF]. The most prominent example is the "The DAO" theft [START_REF] Vessenes | Deconstructing theDAO Attack: A Brief Code Tour[END_REF]. Contrary to centralized software development, smart contracts operate in an open environment where arbitrary adversaries can exist [START_REF] Luu | Making Smart Contracts Smarter[END_REF] and thus attacks can originate from inside the same virtual machine. Additionally, it is substantially harder to correct a bug because smart contract code is unchangeable after it is deployed on a blockchain [START_REF] Vitalik Buterin | A Next-Generation Smart Contract and Decentralized Application Platform[END_REF][START_REF] Wood | Ethereum: A Secure Decentralised Generalised Transaction Ledger[END_REF]. Most problems occur when unknown code is executed, because it may have been deployed by an adversary. Such vulnerabilities can lead to loss or theft of valuable assets and are often hard or even impossible to fix. Most users of such smart contracts do not have the expertise and time to ensure that it is safe to trust the smart contract with their assets.

Platform-based Smart Contract Management

The auditors and developers of smart contracts are often anonymous and their trustworthiness is unknown. Some smart contracts include code which allows a privileged entity to exchange parts of the code. This is done to make it possible to replace code containing a flaw with a fixed version. On the other hand this could be used to inject code that violates a specified behavior.

SmartDEMAP determines a new mechanism, which allows only code to be deployed that does not violate an associated behavior specification. The behavior can be specified as a formal specification and on deployment needs a proof that it conforms to the specification. Other approaches like defining a test suite and only allow code to be deployed that passes the test suite will be investigated in addition to the formal verification approach. This has only a benefit if the formal verification tool or test suite can be run in a trusted way. This reduces the trust required in developers and auditors and replaces it with trust into the tools and their input (formal specification or test suite).

To achieve this, the approach to be designed will follow a blockchain-based path, with a platform for management, analysis, and deployment of smart contracts (SmartDEMAP ). The platform will manage a set of tools and use them to enforce that smart contracts deployed on it fulfill as set of specifiable criteria. Such a tool set contains formal verifiers, compilers, automatic test suites, and automatic bug-finders. These tools are often complex and SmartDEMAP will provide a way to ensure that these tools fulfill their purpose. This indicates that each SmartDEMAP instance needs a entity fulfilling this role. This may be another instance or a known third party (e.g. Microsoft, Amazon, Google) as well as a consortium of people founded exclusively for that purpose. This system reduces the trust needed in the code quality tools and replaces it with trust in the tool verification entity.

Improved Smart Contract Programming Language

SmartDEMAP benefits from a custom programming language, which is aware of it and uses its features during compilation or at run-time. Such a custom programming language can incorporate SmartDEMAP to give additional guarantees by generating the respective run-time checks based on the platforms capabilities. Further it provides a simple way for developers to access the platforms services. A new programming language provides the opportunity to analyze existing languages as well as common exploits of smart contracts programmed in these languages. A smart contract programming language covering this aspect could prevent some exploits and common pitfalls by design.

One currently preferred approach is a language based on a process calculi as suggested in [START_REF] Edstroem | Safer smart contracts through type-driven development[END_REF]. This does prevent by design some of the common exploits, such as the reentrancy exploit that brought "The DAO" to its knees [START_REF] Vessenes | Deconstructing theDAO Attack: A Brief Code Tour[END_REF]. This exploit is prevented because no state is shared between different processes and unlike a function a process cannot be called again if it is still running, and thus, no unexpected state change can occur. This work evaluates if such a language efficiently can be compiled to existing smart contract virtual machines and which exploits could be prevented on the language level.

Methodology

This project is of high importance if smart contract should become safe to use by non-experts. On one hand SmartDEMAP can give them a higher degree of certainty, that it is safe to interact with a smart contract without the risk of unexpected behavior. On the other hand SmartDEMAP and the custom programming language help the developer to deliver smart contracts that are harder to exploit.

The project is approached by developing a model of SmartDEMAP and the custom programming language that describes their respective capabilities and guarantees. Beside the model the platform as well as a compiler for the language are implemented as a proof of the practical feasibility.

The biggest risk involved in the project is that the currently developed tools like formal verifiers as well as the trusted execution infrastructure will not be available in time or do not satisfy the needs of SmartDEMAP. The developed models are used to prove that certain exploits can be prevented fully or at least to which degree if the described platform and the custom programming language is used. The expected proofs are:

1. A proof that it is possible to decide if a unknown smart contract can be called without the risk of becoming vulnerable to certain exploits. 2. A proof that a developer can only deploy code that result in a behavior that conforms to a formal specification. 3. A proof that smart contracts programmed in the custom language are not vulnerable against certain exploits.

The evaluation of which exploits are preventable this way is another expected result from this project. Beside the theoretical results an implementation of SmartDEMAP on the EVM [START_REF] Wood | Ethereum: A Secure Decentralised Generalised Transaction Ledger[END_REF] is expected.


Dennis Kergl
email: dennis.kergl@unibw.de

Robert Roedler
email: robert.roedler@unibw.de

Gabi Dreo
email: gabi.dreo@unibw.de

Towards Internet Scale Quality of Experience Measurement with Twitter

At present, Quality of Experience (QoE) measurements are accomplished by interrogating users for the perceived quality of a service they just have used. Influenced by many factors and often limited by domain or geographical region, this technique has several drawbacks when a general state of QoE for the internet as a whole is prospected. To achieve such a general metric, we leverage user complaints that we observe in real-time in social media. Such approaches have been successfully applied for the monitoring of specific and single services. We aim to extend existing methods in order to create an overall metric, define an internet wide QoE baseline, monitor changes and hence, provide a context for assessing smaller scale findings against a ground truth. The contribution of this work is to demonstrate the feasibility of using social media analysis for generating a meaningful value for quantifying the actual QoE of the internet.

Introduction

Management and operation of communication and networking services rely on holistic knowledge of interrelationships between technical values and perceived service quality. Especially perceived quality of internet services is fundamental for both developing web applications and planning network infrastructure [START_REF] Ahmad | QoE-aware service delivery: A joint-venture approach for content and network providers[END_REF]. The shift from technology-oriented to user-centric development, operation and measurement correlates with the trends of network architectures that evolve from host-oriented to information-centric models, and infrastructure networks from static to Software Defined Network (SDN) technologies [START_REF] Liotou | Shaping QoE in the 5G ecosystem. Quality of Multimedia Experience[END_REF].

On a technical level, there exist plenty of measured parameters that can describe characteristics of network links, protocols, connected systems and applications and form the well-defined Quality of Service (QoS) concept [START_REF]Definitions of terms related to quality of service[END_REF]. Although the International Telecommunication Union (ITU) definition of QoS includes the ability to satisfy stated and implied needs of the user of the service, the QoS concept does not provide insights to users' satisfaction on consumed services. To close this gap and to provide specific and measurable objectives to application and infrastructure developers, the concept of QoE was introduced.

There are many different application domains of the QoE concept resulting in slightly different understandings. Basically, existing work can be classified in either concentrating on specific network technologies, e.g., mobile networks like 3G [START_REF] Ketykó | Performing QoEmeasurements in an actual 3G network[END_REF], 4G [START_REF] Rengaraju | On QoE monitoring and E2E service assurance in 4G wireless networks[END_REF], 5G [START_REF] Liotou | Shaping QoE in the 5G ecosystem. Quality of Multimedia Experience[END_REF], on specific media (e.g., video [START_REF] Venkataraman | Inferring video QoE in real time[END_REF], voice [START_REF] Ho | Testing the IQX Hypothesis for Exponential Interdependency between QoS and QoE of Voice Codecs iLBC and G.711[END_REF]), on specific services like Internet Protocol television (IPTV) [START_REF] Takahashi | Standardization activities in the ITU for a QoE assessment of IPTV[END_REF], Mobile Social Networks (MSN) [START_REF] Dong | Quality-of-Experience (QoE) in emerging mobile social networks[END_REF] and YouTube [START_REF] Wamser | Modeling the YouTube stack: From packets to quality of experience[END_REF], or on the type of service deployment like cloud services [START_REF] Al-Shammari | Defining a Metric for Measuring QoE of SaaS Cloud Computing[END_REF] or peer-to-peer networks [START_REF] Hei | IPTV over P2P streaming networks: the meshpull approach[END_REF]. Also combinations of the aforementioned categories are actively researched, e.g., in [START_REF] Casas | YOUQMON: A System for On-line Monitoring of YouTube QoE in Operational 3G Networks[END_REF].

QoE can be thought of as QoS plus a human factor. This simple definition might be misleading, as modeling of the human factor is an unresolved issue, that includes different fields of psychology like cognitive psychology, memory psychology, and psychophysics [START_REF] Streijl | Mean opinion score (MOS) revisited: methods and applications, limitations and alternatives[END_REF]. That is why QoE measurements often include conducting real-world experiments with test persons, asking them in various ways for their opinion on used services. Using this black box test setting, the inscrutability of the human mind is bypassed and the aimed value is achieved. The disadvantage is the requirement of strictly controlled testing procedures, high personnel demand and lack of scalability.

In order to address these shortcomings, this paper is about the question of whether it is possible to turn complaints of globally distributed social media users into valuable signals for inferring perceived levels of web service quality. With a positive outcome, continuous QoE measurement at large scale would become feasible and advanced questions might be identified. With Twitter, people can publish messages (tweets) using various devices and follow other users to subscribe to their tweets. The public Twitter Application Programming Interfaces (APIs) offer programmatic access to public tweets in a well-documented JavaScript Object Notation (JSON) format. Twitter is the most widespread service of its kind and, due to its openness and popularity, current subject of research in several disciplines covering a broad range of examined topics [START_REF] Zimmer | A topology of Twitter research: disciplines, methods, and ethics[END_REF]. In this work, we investigate the feasibility of using tweets as an indicator for QoE drops. Twitter users are not a representative share of all internet users. More than that, we expect the population to be biased in various ways. This is a restriction to our approach, which let us detect only complaints about problems without providing an unbiased base line. Nevertheless, we expect the outcome to be actionable in a way that subsequent work can build upon it and support the presented use cases.

The remainder of this paper is organized as follows. Section 2 gives an overview of QoE metrics for web services, how measurements are performed, and which shortcomings exist in current methods. Also, use cases are presented and requirements to the solution are derived. In Section 3 we investigate existing approaches on leveraging social media content for detecting disruptions of web services. A description of our experimental setup, message processing and signal extraction methods to receive correlations between web services and user experience are presented in Section 4. In Section 5, we give insights to the generated data and evaluate our findings with respect to the research question that is raised. The results are concluded in Section 6 and future work is outlined.

Assessing accurate QoE metrics is a challenging problem. Schatz et. al. give comprehensive insights in [START_REF] Schatz | From packets to people: Quality of experience as a new measurement challenge[END_REF]. They define two different kinds of testing techniques for QoE: The first kind is made of subjective tests, typically conducted in a controlled laboratory setting but also as field tests or using crowdsourcing methods. All of these methods aim to gather answers from humans to predefined questions and include the downside of being costly, time-consuming and require careful planning. The second kind of tests is objective measurement that include measuring physiological aspects of test persons or technical parameters of the utilized systems and infrastructure. These assessment methods need to be mapped to a resulting user experience score, requiring a proper model. Whilst also being affected by the drawbacks of the subjective methods, the big advantage of objective methods is the possibility of automation and therefore, some degree of scalability.

Modeling and formalization of QoE

QoE is defined as a metric for the relationship of a person that interacts as user with an application [START_REF] Moorsel | Metrics for the Internet Age : Quality of Experience and Quality of Business Metrics for the Internet Age : Quality of Experience and Quality of Business 1 . Quantitative Evaluation in the Internet Age : What is Different ?[END_REF][START_REF] Kilkki | Quality of Experience in Communications Ecosystem[END_REF]. While QoS focuses on the relationship between systems, the authors recognize that a change in QoS only affects QoE if a person's expectation is affected. Analogous to this approach, also the concept of Quality of Business (QoBiz) is introduced, the value of which only is affected by changes in QoE if a company's revenue is impaired. The key finding of these publications is that values of different quality aspects can be seen independent, even though they build upon each other, so that only weak coupling between these metrics can be assumed.

Web QoE metrics and assessment

In contrast to QoS that is well defined and standardized [START_REF]Definitions of terms related to quality of service[END_REF], and even adapted to specific technologies like mobile networks [START_REF]QoS aspects for popular services in mobile networks[END_REF], QoE is much harder to quantify. A common factor of most approaches, is the assignment of an average value for perceived quality on a scale from 1 to 5 (representing bad, poor, fair, good, and excellent), what is known as the Mean Opinion Score (MOS) [START_REF]Methods for subjective determination of transmission quality[END_REF].

Streijl et. al. give a comprehensive summary of methods, applications, limitations and alternatives of the MOS in [START_REF] Streijl | Mean opinion score (MOS) revisited: methods and applications, limitations and alternatives[END_REF]. They describe the influence of psychological aspects, test design, testing methods and even the choice of scales to the result of MOS measurement. Stating the costly and time-consuming nature and limited scope of subjective quality tests, they also review objective models that exist in various types (e.g., arithmetic models, statistical models, parametric network planning models). While these models can be considered correct, as long as the calculated MOS lies within the confidence interval of the subjective MOS, the authors conclude that slight broadening of distortions results in higher complexity and disagreement between perceived qualities.

Challenges of objective methods for network related QoE

The ITU outlines a framework for estimating end-to-end-performance in IP networks in [START_REF]Estimating end-to-end performance in IP networks for data applications[END_REF] and recommends to focus on technical metrics like bandwidth, delay and packet loss rate in order to gain insights to perceived web quality. While concluding that perceived quality can be derived with a correlation that is high enough for most use cases (> 0.9), more detailed methods for addressing factual challenges and considering a higher number of variables have been published during the last years. Most of these approaches incorporate in some way the complexity of human emotion, that are not considered in the framework of the ITU. Some of the human mind's complex relationships have been researched in context of QoE: Egger et. al. show in [START_REF] Egger | Time is bandwidth' ? Narrowing the gap between subjective time perception and Quality of Experience[END_REF] the direct applicability of the Weber-Fechner Law (see [START_REF] Hecht | The visual discrimination of intensity and the Weber-Fechner law[END_REF] for a brief historical outline) to the relationship of waiting time and download experience. They proof this finding empirically for simple waiting tasks and furthermore, they also investigate the applicability of logarithmic relations between bandwidth and mean opinion score for more complex tasks like web browsing. Instead of a logarithmic relationship, rather an exponential relationship was discovered, as has also been shown before by Fiedler et. al. in [START_REF] Fiedler | A generic quantitative relationship between quality of experience and quality of service[END_REF]. The explanation for this outcome lies in the complex, non-linear models of network-level page load times, which were investigated in detail by Belshe [START_REF] Belshe | More Bandwidth Doesn't Matter (much)[END_REF]. Also, a memory effect has to be considered as psychological influence factor as described in [START_REF] Hossfeld | The memory effect and its implications on Web QoE modeling[END_REF]. With [START_REF] Egger | Waiting times in quality of experience for web based services[END_REF] Egger et. al. provide a condensed summary of many of the intertwined aspects. From these insights into technical and psychological background of perceived web quality, we can derive that a purely technical approach to measure web QoE is a hard problem.

Use Cases

To demonstrate the tangibility of the problem statement, we look at the following exemplary stakeholders that can benefit from internet wide QoE measurements.

Network Providers need to optimize investments on new infrastructure in a way that costs are minimized while turnover is maximized, aiming at ultimately maximizing profit. QoE is a valid metric for customer satisfaction, which in turn we imply is positively correlated with turnover. Due to this correlation, optimizing for QoE is more target-oriented than optimizing for technical QoS parameters. The knowledge of a base level of customer satisfaction and the ability to detect changes is key either to assess the effect of investments already carried out and to identify weak points in network infrastructure that are most in need for further investments. Service Providers that offer their business to worldwide customers, often rely on both own and third-party infrastructure to deliver contents. Ensuring continuous availability and convenient response times, as two key service level metrics, is business-critical to them. Their challenge in monitoring customer experience is manifold: Services are frequently added and changed so that automatic or synthetic monitoring of technical key performance indicators often lags behind and covers only a small fraction of all service functions. Also a service provider would like to be aware of a shift of customers' experience during the lifetime of a service. Challenging is that the underlying infrastructure is very heterogeneous in most times, not only because of thirdparty services but also because of implementing novel cloud technologies as demanded by service expansion. In case of a problem, they also want to identify whether the problem affects only their own service or services of other providers as well to communicate accordingly to their customers. Security Actors may observe disruptions of network segments or services of central importance for the reliability of internet infrastructure as a result of large-scale attacks. In such scenarios, it is crucial to gain as much information as possible as quickly as possible. This is to make up the information advantage of the attackers and become able to successfully deploy counter measures in a timely manner. To know whether, which, where and to what extend web services are affected, can support this process effectively.

Requirements

To conclude the former stated shortcomings and limitations of current approaches, we derive the following requirements on real-time QoE measurement at internet scale, matching the demands of the presented use cases.

Related Work

In order to examine to which extend the identified requirements are met by existing approaches and also to eventually identify the open points that have to be considered, we give the necessary overview of the most significant work in the relevant fields.

Measuring QoE

There are several approaches to derive MOS for specific applications from measurable network parameters and traffic monitoring, most of which include elaborate field trials interviewing test persons. In [START_REF] Casas | YOUQMON: A System for On-line Monitoring of YouTube QoE in Operational 3G Networks[END_REF] [START_REF] Mok | Measuring the quality of experience of HTTP video streaming[END_REF]. They measure the MOS in a sophisticated experimental setup under strictly controlled test conditions. Furthermore, they present first results for a correlation between video category (i.e., sports, news, comedy, music video) and the perceived quality, while keeping technical attributes like stall times and re-buffering frequency fixed. The dependency between MOS and video category is a good example of the human factor in MOS measurement and shows the non-linear connection between technical values and perceived quality. Both publications show the need for access to core network components to automatically measure a QoE score. While fulfilling some of the requirements, these approaches cannot adapt to new services and are strongly dependent on the underlying network topology.

The same authors investigate in a recent work the quality of crowd-sourced approaches to QoE measurement [START_REF] Mok | Detecting low-quality workers in QoE crowdtesting: A worker behavior based approach[END_REF]. Though being relatively cost-effective, for long running settings, costs are still a disadvantage. Advantages over one-time experiments are, e.g., the ability of conducting an ongoing assessment of certain services, and due to using humans as sensors, adaptability to changes in the assessed services. A disadvantage is still the management effort for planning, supporting and evaluating the questionnaires. Also the quality can be an issue, as the authors investigate in the paper.

Using Twitter to detect outages

Principally, not only Twitter is suited as a data source for detecting opinions about web services. Other social media platforms offer also a wealth of user generated content. The decisive criterion for choosing Twitter is easy accessibility of data. This is meant in a technical manner, as Twitter offers a well-documented API with free and open access for many use cases. Apart from that, using Twitter is motivated in the text-focused format of the data that can be exploited with well-established techniques.

Motoyama et. al. were the first to leverage the unique characteristics of Twitter messages for detecting outages of internet services [START_REF] Motoyama | Measuring online service availability using twitter[END_REF]. They identified terms that qualify tweets to report about service outages by investigating tweets that occurred in temporal correlation with major service outage reports in the media. To further refine their filter, they developed a heuristic that leveraged customs of Twitter users, like using hashtags that include the word fail. To clean up the derived signals, they made use of exponential smoothing and gave insights into their chosen parameters to achieve optimal results. Their outcome is to be able to identify outages of online services by observing between 4 and approximately 200 reports about a specific service outage. The suggested solution was later implemented by Augustine and Cushing [START_REF] Augustine | Outage detection via real-time social stream analysis: Leveraging the power of online complaints[END_REF]. They used the approach to monitor outages and network problems of the NETFLIX content delivery network. They were able to evaluate the accuracy of their system because a list of outages of the monitored web service was available to them and showed the practical applicability and value of leveraging tweets for their use case.

Qiu et. al. evaluated the relationship between tweets and customer care tickets that both address mobile network experience issues [START_REF] Qiu | Listen to Me if You Can: Tracking User Experience of Mobile Network on Social Media[END_REF]. They found that tweets, relating to the same problem, preceded customer care tickets by approximately 10 minutes. Furthermore, tweets reported a wider range of problems while also addressing a slightly different set of problems. Qiu et. al. mapped the problems reported via Twitter to incidents they knew from the ticket system. In addition to the already known incidents, they were able to identify short-term problems that have not been reported via the ticket system. Summing up their findings, we emphasize that these correspond with our motivation to exploit tweets for measuring QoE in real-time: Timely detection of drops in experience, high sensitivity for a broad range of problems and open availability of continuous monitoring data.

Open points

We conclude the review of related work with summarizing how the formulated requirements are met in Table 1. A global baseline for an internet wide QoE score is not provided by any of the mentioned publications. Furthermore, to the best of our knowledge, there is no such approach in existing scientific literature. While the approaches that use network parameter measurements to obtain an MOS are able to map the results to a continuous scale between 1 and 5, the approaches that leverage social media messages to detect outages are only able to make a binary decision between service available and not available. Also to the best of our knowledge, there is no approach so far that would investigate other service disruptions like increased latency. Network measurement based approaches have an obvious dependency on the underlying technology. In contrast, approaches that use humans as sensor are free of this dependency. Also, human based test methods are able to adapt to new services and service changes. In the case of crowd-sourced test methods, questionnaires and manuals have to be adapted. Provided that services and technology conditions are stable, all methods can be used for continuous monitoring. Though crowd-sourcing methods have limited real-time response times, as the setup and management overhead can be significant. We address the identified open points in the following way. In contrast to existing work, our approach aims to isolate a signal that is suitable for inferring an internet wide QoE score, rather than concentrating on a specific service. Furthermore, we add distinction between a total loss of availability and response time of a service, which can be used to derive a graduated score of disruption, rather than a binary decision. According to existing approaches that use social media content and therefore humans as sensors, we also use tweets to meet the remaining requirements.

Experimental setup

In this section, we briefly describe the source of the analyzed data, the ETL process (i.e., extract, transform, load), and used methods of feature isolation, data smoothing and signal extraction. All steps were performed using two midclass notebooks and one office workstation, equipped with 4-12 CPU cores at 2.7 GHz-3.16 GHz and 8 GB-32 GB RAM. For loading and analyzing the data, these systems formed a small cluster running Elasticsearch on Apache Lucene as main database supported by a powerful indexing and search environment, and Kibana for gaining insights into the data. Once the data has been loaded, typical requests involving a keyword filter took approximately 60-80 seconds.

Data Source

In order to gather a reasonable data set for our analysis, we used Twitter's public API. Combining several API methods, we captured and requested tweets that have been created in the time interval from 13-Feb-2017 12:00:00.000 UTC to 02-Mar-2017 08:59:59.999 UTC. The obtained data set is not complete in the sense that a complete data set would include every single tweet that has been published during the considered period. First reason is, for being able to analyze textual content efficiently, we dropped all tweets with a language attribute that differs from en (i.e., English). This restriction is not as strict as it may seem. First, English is the most used language on Twitter, and second, internet related issues are often reported in English, even if it is not the native language of the reporting user. A possible reason might be that error messages are mostly in English and are simply cited by reporting users. We have observed this behavior very often in our data set. In addition, there are several more reasons for the data set not being complete: Besides public tweets there are direct tweets between users. Direct tweets are private and not accessible by anyone else but the sending and the receiving user. Another category of tweets that we missed consists of such tweets that have already been deleted at the time of our request. Ultimately our data set lacks of tweets that we simply did not cover with our query parameters.

Taking into account that a productive implementation of our findings, if appropriate, would most certainly also use the public Twitter API, working on an equivalent data set with common shortfalls appears to be justified. Beyond this, an eventual implementation should be able to work on a much smaller data set than we used to examine the feasibility of the concept.

Figure 1(a) shows a typical Twitter-Day for English content of our data set. We are able to show the amount of total tweets in the firehose (i.e., the stream of all public tweets), taking advantage of the nature of Twitter's sample stream that we described in [START_REF] Kergl | On the endogenesis of Twitter's Spritzer and Gardenhose sample streams[END_REF] and also captured for this analysis. Also the proportion of our data set can be derived from the figure.

Furthermore, we have the requirement to our data of being as random as possible. This is due to a limitation in Twitter's Streaming API: If requested with a set of keywords (that seems appropriate for our problem at the first glance), Twitter will deliver all tweets that contain these keywords, applying a logical OR between the requested keywords and there is no possibility to use a NOT operator for this request. However, according to the documentation of the Streaming API, Twitter caps the delivery rate of this stream to 1% of the current firehose rate. Hence, if the hit rate of our filter exceeds this limit, we would not be able to derive an accurate result value due to capped measurement values. Whether this limitation is a real problem or practical systems could rely on Twitter's Streaming API, can be derived from Figure 1(b): The histogram shows the distribution of the resulting percentage of the firehose for all 5 minute intervals of our data set when we use the keywords that are presented in the next section. According to this analysis, we would hit the limit of one percent in more than a half of the time.

Data Extraction

The extraction challenge is typically twofold: First, we have to identify relevant terms, that appear in tweets of our interest. Second, tweets containing the identified terms have to be collected from the data set to form generating components for the desired signal.

Inevitably, at first we have to define what characterizes a tweet of interest.

As Twitter is to be leveraged as a sensor for drops in web QoE, tweets that represent a suitable signal combine the following Properties:

1. Related to a specific web service (no need to mention which in particular). 2. Describe present reduction of availability or speed of (parts of) a web service. 3. May be formulated as a question, may use humor, sarcasm, or irony. 4. Do not notify about intentional down time.

Hereinafter the occurrence of a tweet of interest will be referenced as event.

As a starting point for suitable terms to identify events, we analyzed and used phrases presented in [START_REF] Motoyama | Measuring online service availability using twitter[END_REF]. The first filter approach used the following Conditions for tweet content (not case sensitive):

1. Must contain: website OR site OR server 2. Must contain: down OR unreachable OR error While Condition 1 identifies tweets about web services, Condition 2 restricts the result set to terms that most likely describe the problem component of Property 2. Using only these two conditions, a one-time training set of 400 tweets showed a selectivity of 0.77.

After this manual review we optimized the filter choice for selectivity. As a result, these additional Conditions were added to the filter: 3. Must NOT contain: (going to be OR will be OR was OR is not) down 4. Must NOT contain: (close* OR shut* OR take* OR took OR torn) down 5. Must NOT contain: (clean OR count* OR dress OR low OR right OR scroll OR settle OR sit OR top OR written) down 6. Must not be a retweet of an original tweet.

Condition 3 was added to ensure the temporal relation of Property 2. To address Property 4, Condition 4 was introduced. The conditions were further restricted by introducing Condition 5, covering the most common semantic ambiguities of the term down, and by Condition 6 as retweets in the training set in most instances did not fulfill the listed properties. Finally, this set of conditions was evaluated against a test set of 840 tweets that is distinct to the training set. For the refined condition set, a selectivity of 0.88 was identified, yielding 12% false positives. We consider this rate as being sufficient for conducting a proof of concept, considering the simplicity of our approach.

Data Smoothing

The time resolution we applied for this analysis is 5 minutes. We could have chosen smaller intervals, but then occasional random disconnections of the Twitter stream, network anomalies or other random errors, would have a more significant effect on the results. Hence, we have chosen this general smoothing. Furthermore, we can observe increased activity at every full hour and also at every half hour. The latter does not weight as much as the first. To address the artificially generated bursts in the data set, we applied an exponential weighted moving average (EWMA) with a half-life period of 15 minutes (α ≈ 0.206) and used this value for further calculations. The frequency of the analyzed tweets also shows a typical variation during a day.

For determining a baseline of reports about service outages or service restrictions like increased response time, we need to apply an appropriate metric. Due to the nature of tweet distribution that is not unique across a day, we cannot simply count the number of event occurrences and use this value as a baseline. Since reports of events underlie the same daily rhythm as the firehose and are correlated with the biological rhythm of the sensors, we have to normalize the event count to the current activity. This is achieved by using the proportion between all events and all non-event tweets as metric. Hence, the ratio of event occurrences in a specific time interval in comparison to the total number of tweets in the same time interval qualifies as the desired metric. The simple formula for the wanted score in time interval n is event

-ratio n = |events| n |EWMA(tweets)| n -|events| n . (1)
To address temporal spikes in the total tweet number, we applied the smoothing described in the preceding section to the total number of tweets and Figure 2(a) show the distribution of the event ratio in our data set for the outage event defined above. Figure 2(b) shows the event ratio distribution for slow events, for that we changed Condition 2 to the term slow only. The mean value for the down report ratio can be identified as 2.25 × 10 -5 , while the median is 1.66 × 10 -5 . Using the median as a baseline seems appropriate, as there have been major outages taken place during the capturing of the data set. The mean value for the slow report ratio is 1.58 × 10 -6 , while the median is 2.56 × 10 -7 . The significant difference between median and mean is a clear indicator for outliers, that can be confirmed by the event ratio histogram that shows occurrences of event ratios that are multiples of the median. Table 2 lists an excerpt from the top 50 event ratios and informs about the causing event, that we identified by textually analyzing the specific period.

Conclusion and Future Work

We have been able to define a global baseline for down report and slow report frequencies. Therefore, there are two main contributions of this work to mention: 1. A practical system for monitoring the overall internet web QoE is feasible and can be implemented using Twitter analysis. This fulfills Requirement 1 that most likely has not been addressed by any existing work. 2. Not only outages of web services, but also degradation of web service quality can be detected. This fulfills Requirement 2 that has not been completely covered by existing publications. The remaining requirements have been matched by using humans as sensors.

The presented primary findings about the feasibility of using social media posts for gaining internet wide insights to QoE aspects in real-time denote an important step towards more detailed analysis of affected networks, domains and technologies, constituting a necessary requirement for novel approaches to improve overall network and internet security, e.g., as suggested in [START_REF] Kergl | Detection of Zero Day Exploits Using Real-Time Social Media Streams[END_REF]. As follow up research questions, we are already investigating whether root causes of drops in QoE can be identified by using additional information contained in tweets, for instance, analyzing geographical origin of the complaints might lead to insights about regional problems and using the contained information about which client software was used to create the tweet might give further hints on whether mobile or fixed networks or both are affected by drops in perceived web service quality. Furthermore, mapping complaints to specific web services in an automated fashion seems to become feasible, while still being a complex problem. This would allow to drill down the QoE measurements to individual domains and accordingly to underlying networks and technologies.

  Tweet Frequency for 5-minute-bins for a typical English subset of 24 hours. Event ratio using OR-linked keywords.

Fig. 1 .

 1 Fig. 1. Properties of the derived data set

Fig. 2 .

 2 Fig. 2. Event ratios of the analyzed data set. The right most spikes, that constitute a multiple of the average ratio, are related to Amazon's S3 outage during the capture time of the data set.

  Casas et. al. present YOUQ-MON, an approach to calculate the MOS for YouTube videos in 3G networks by passively monitoring network packets within the network core. To evaluate the model, they conducted a field trial with 16 different videos to compare the calculated MOSs with the ones perceived by test persons. Mok et. al. investigate how network path qualities (i.e., bandwidth, roundtrip time (RTT) and loss rate) affects QoE of Hypertext Transfer Protocol (HTTP) video streaming

Table 1 .

 1 Assessment how the requirements are met by existing work.

		Casas	Mok'11	Mok'16	Motoyama	Qiu	Augustine
	Requirement (see Sec. 2.5)	[5]	[23]	[24]	[26]	[27]	[3]
	1: Global baseline
	2: Detect score changes
	3: Independent of technology
	4: Adapt new services
	5: Continuous monitoring
	6: Results in real-time
	Requirement =not met, =partially met, =fully met

Table 2 .

 2 Excerpt from top 50 highest event ratio intervals. Events manually evaluated.

	#	Time	Event Ratio	Median Multiplier	Causing Event
	1 28-Feb-17 18:30 0.000456	27.5	Amazon S3 Outage
	2 28-Feb-17 18:10 0.000424	25.6	Amazon S3 Outage
	3 28-Feb-17 18:15 0.000374	22.5	Amazon S3 Outage
	4 28-Feb-17 18:00 0.000371	22.4	Amazon S3 Outage
	5 28-Feb-17 18:25 0.000352	21.2	Amazon S3 Outage
	16 27-Feb-17 11:30 0.000275	16.6	Error message on hilton.com
	24 02-Mar-17 10:50 0.000246	14.8	Vainglory game server maintenance
	37 02-Mar-17 12:25 0.000204	12.3	Booking problem on qatarairways.com
	42 27-Feb-17 12:10 0.000188	11.3	Booking problem on klm.com
	50 02-Mar-17 12:35 0.000141	8.5	Amazon S3 Outage