João Rodrigues

Joaquim Silva

Rolando Martins

Luís Lopes

Utsav Drolia

Priya Narasimhan

Fernando Silva

Benchmarking Wireless Protocols for Feasibility in Supporting Crowdsourced Mobile Computing

Recent advances in mobile device technology have triggered research on using their aggregate computational and/or storage resources to form edge-clouds. Whilst traditionally viewed as simple clients, smartphones and tablets today have hardware resources that allow more sophisticated software to be installed, and can be used as thick clients or even thin servers. Simultaneously, new standards and protocols, such as Wi-Fi Direct and Wi-Fi TDLS (Tunneled Direct Link Setup), have been established that allow mobile devices to talk directly with each other, as opposed to over the Internet or across Wi-Fi access points. This can, potentially, lead to ubiquitous, low-latency, device-to-device (D2D) communication. In this paper, we study whether D2D protocols can support mobile-edge clouds by benchmarking different protocols and configurations for a specific application. The results show that decentralized device-to-device techniques can be used to efficiently disseminate multimedia contents while diminishing contention in the wireless infrastructure, allowing for up to 65% traffic reduction at the access points.

Introduction and Motivation

Mobile devices are now ubiquitous [START_REF]Global mobile statistics[END_REF]. The increase in the sheer number of devices has also led to the increase in the density of devices, i.e. more often than not, there will be multiple mobile devices in proximity of each other. Moreover, these devices are now equipped with multi-core processors, multi-GB memory and multiple communication interfaces. This trend has been leveraged by a new class of systems, mobile edge-clouds [START_REF] Drolia | Krowd: A key-value store for crowded venues[END_REF] [3] [4] [START_REF] Yan | mcrowd: A platform for mobile crowdsourcing[END_REF] [6] [START_REF]A security, private internet and tactical cloud at the edge[END_REF] [START_REF] Wait | Darpa creates cloud using smartphones[END_REF]. These systems aggregate computation and storage resources across nearby mobile devices to enable resource-efficient applications.

Simultaneously, new standards and protocols, such as Wi-Fi Direct and Wi-Fi TDLS (Tunneled Direct Link Setup), have been established that allow mobile devices to talk directly with each other, as opposed to over the Internet or across Wi-Fi access points. This can, potentially, lead to ubiquitous, low-latency, deviceto-device (D2D) communication.

We believe that these new D2D protocols can boost the efficiency of mobile edge-clouds. Since these systems are meant for scenarios where devices are in proximity of each other, D2D communication seems like a natural fit. For example, let us consider the following scenario: watching video replays on mobile devices at live events, e.g. soccer match. There is a growing market of apps that provide users within (and outside) the venue with almost real-time statistics and multimedia contents like the number of kilometers a player has run or video replays for goals or interesting events [START_REF]YinzCam[END_REF] [START_REF]Agile stadiums bring digital content to sports fans[END_REF]. If a fan chooses to watch a video replay, the content is downloaded from the central servers through stadium installed access points (Wi-Fi or cellular), and then played on the device. If, however, the venue is crowded, the large number of requests can stress the infrastructure [START_REF] Kapustka | State of the Stadium Technology Survey[END_REF] [START_REF] Erman | Understanding the super-sized traffic of the super bowl[END_REF].

One way to solve this problem is to use mobile edge-clouds. In this way, you and your neighbours may form a local cache for the server contents -users of the service can be encouraged to share in several ways, e.g., sweepstakes of team merchandise or lower rates for the service. For example, before asking the server for a video replay, your app might ask the other phones in the mobile network whether they have a copy of the video. If a copy of the replay is located, your app can retrieve it directly from a neighboring device. Our first hypothesis is that such retrievals can be accelerated through D2D protocols. Moreover, if the retrievals in mobile edge-clouds are done over infrastructural access points, the access points would be congested in-turn leading to high-latency downloads and an overall bad user-experience. Our second hypothesis is that D2D protocols can alleviate such infrastructural stress.

In this paper, we study whether D2D protocols can support mobile-edge clouds by benchmarking different protocols and configurations for a specific application. The results suggest that decentralized, device-to-device techniques can be used to efficiently disseminate multimedia contents while diminishing contention in the wireless infrastructure, e.g., central servers and access points, namely through the use of TDLS and WiFi-Direct.

The remainder of this paper is structured as follows. Section 2 describes the scenarios we are interested in exploring and the experimental setup. Section 3 describes the application we developed to perform the experiments. Sections 2 and 4 describe the experimental setup, the results obtained and discusses their implications. Section 5 overviews related research work and, finally, Section 6 ends the paper with the conclusions and future work.

Assumptions and Scenarios

We make the following assumptions: (a) all the devices are non-rooted since we are interested in improvements that can be readily implemented in current infrastructures and do not rely on invasive procedures for the devices; (b) we do not control the usage of the radio channels and the choice of the radio band, 2.4GHz or 5GHz, for communication; (c) all devices are within radio range and can make requests and transfer contents using direct connections or using an AP or a hot-spot as an intermediate; (d) there is no application-level routing or discovery mechanisms, we only use what is provided by the underlying wireless protocols; (e) in the scenarios that involve mobile servers, the latter have all the files that will be requested by the clients, and that would otherwise be present at the central server in a traditional infrastructure, and; (f) clients know the location of the servers from the start.

We define a set of content dissemination scenarios for downloading video replays from a soccer game in a stadium (Figure 1). In all scenarios we assume WiFi is used for communication. In the case of pure WiFi, all scenarios include a traditional, dedicated, access point that the devices use for communication. When using WiFi with TDLS, the access point is used only for the initial contact between the nodes. In the case of WiFi-Direct, this role is performed by a mobile device known as the "group owner". In the first scenario (WCS -WiFi Central Server) we have a main server, part of the infrastructure of the stadium, acting as the source of the video replays. The server is connected to access points in the stadium via high-speed Ethernet links. Each access point handles tens of devices in the part of the venue it provides coverage [START_REF] Erman | Understanding the super-sized traffic of the super bowl[END_REF]. All mobile devices are clients.

In the second scenario (WMS -WiFi Mobile Server) we remove the main server, and just stick with the access point. Part of the mobile devices in the venue will act as servers (servers only) for the multimedia contents, thus providing the same content as the central server in the previous scenario.

In the third scenario (WTMS -WiFi TDLS Mobile Server) we use the access point only for the first contact between the devices. TDLS then allows the devices to communicate directly and transfer data. Again, part of the devices in the venue will act as the servers for the video replays. As in the previous scenario, mobile servers are not also clients and contain all the content that might be provided by the central server.

In the fourth scenario ( WDMS -WiFi Direct Mobile Server) the configuration is similar to WMS with the access point replaced by one of the devices acting as a hot-spot, known as "group owner". All communication between mobile servers and clients must go through the group owner.

We identified an additional scenario, similar to WTS, in which the access point is replaced with the group owner. Here, however, we use TDLS to allow servers and clients to communicate directly (mostly) without the intervention of the group owner. We did not experiment with this last configuration. We were not able to form networks of more than 5 or 6 devices using WiFi-Direct and thus present only preliminary results for the WDMS scenario. This difficulty arises not only from the fact that we are using non-rooted devices, and thus cannot fully control operating system configurations, but mostly because most network card drivers/firmware are proprietary software.

Test Application

We developed Java/Android applications to implement the clients and servers in the aforementioned scenarios. The servers, both fixed, in the first scenario, and mobile, in the others, follow the standard client-server architecture. The server waits for a connection from a client; when one is received, they launch a new thread that examines the request and transfers the requested file. The mobile clients are tailored to be used with the Android Debug Bridge (ADB) tool. We developed a template from which all client behaviours could be implemented by extending a base class. This class has three main methods that are overridable for different scenarios, namely: startApp, transferFiles and endApp. startApp executes a sequence of checks to ensure that a client will run correctly, e.g., if the device is connected to the correct WiFi network. It also initializes a logger in order to record information about the run, and fills a work queue with the file requests, a permutation of the file names, to be downloaded by the device. Each file is mapped to a set of predefined servers that can provide it. The clients choose one of these for each download. After that, method transferFiles is called to download the files, which are transfered, one by one, after selecting appropriate servers. Once a transfer finishes, the next file on the queue begins to be downloaded. When all files are downloaded, the application calls the endApp method to perform all the necessary cleanup.

The execution of the application by the devices starts simultaneously thanks to a barrier implemented (a shared file is used for this) at the end of the startApp method. The devices also synchronize before ending, again by using a barrier at the beginning of the endApp method. We used a set of shell scripts to automate the execution of the application and to control the devices through the Android Debug Bridge (ADB). The adb command line tool allows to execute ordinary Linux shell commands remotely on Android devices, e.g., ls, cp. This allows, for example, uploading all log files from the devices to a server for processing and commanding all experiments using simple scripts. For better control, we decided to use ADB through the USB interface (instead of WiFi), with all devices connected to the control computer through an USB hub. Figure 2 shows the basic procedure for running the experiments. The procedure takes three arguments: n, the number of devices, m, the number of servers and, l, the number of times the experiment is to be repeated. We start each run by rebooting the mobile devices to ensure that all devices are in similar circumstances and that there are no extra processes running that could interfere with the results. Afterwards, the runServers procedure sends a command to all the server devices to start the local server application. Next, runClients starts the local client application at each client device, that in turn calls the startApp entry point. Once all the runs are performed, the logs are copied from the devices to a desktop computer for analysis.

Experiments and Results

Our experimental setup is composed of the following hardware: 1 Asus RT-AC56U router (AP), 20 non-rooted HTC Nexus 9 tablets, 2 Trust USB hubs (10 ports each) and 1 desktop computer. The layout of the deployment can be seen in Figure 3. The devices were placed on top of a table, side-by-side, in a 4×5 pattern, as in a typical of stadium seats arrangement. They all run Android Lollipop 5.1.1 (API level 22) on top of which our test software was executed. The devices were connected to a control desktop computer via the Android Debug Bridge.

The experiments were setup in such a way that we guarantee that all the content requested by the clients during the runs exists in all servers. In each experiment, clients must download 20 video files, each 3 Mbytes in size from the servers. This size represents a video clip with 10 seconds duration and encoded with H264 video codec using 480x270 (width x height) as the frame size, a typical format used by mobile apps. Before starting the transfer, each client computes a random permutation of the 20 file names using a uniform distribution, to even out the requests for each individual file during an experiment. Accesses are also performed randomly in time, as each client waits a random time interval, within given bounds, before requesting the next file of the sequence. For each scenario, we run a set of experiments with a varying number of mobile servers/clients. Each experiment was repeated 8 times to smooth out statistic flukes. The average download time for each video is represented in the graphs in the next sections, together with the for the 95% confidence intervals. The values for power dissipation are given as the average per download, as measured using the Android API (android.os.BatteryManager) The instantaneous current intensity and the voltage (mostly constant) are read periodically to compute the dissipated power which is then integrated over the complete experiment to get the total energy spent per download.

To characterize the radio environment, we performed a WiFi analysis on our campus and detected that the 2.4Ghz band was extensively utilized by various services, while the 5Ghz band usage was minimal. All the experiments were performed using the 802.11n for packets exchanged between the AP and the devices; 802.11ac was used whenever packets were exchanged device-to-device3 .

Single Server

We start by restricting the experiments to only one server (infrastructural or mobile), and experiment with four scenarios: WCS, WMS, WTMS, and WDMS. The results for WiFi-Direct (WDMS) are just preliminary. We vary the number of mobile clients downloading videos from 1 to 16. Figure 4 shows the average download time per file. Figure 5 shows the total traffic processed by the AP, in the WCS, WMS and WTMS scenarios. For figure 5, given that the amount of traffic for WCS is exactly the same amount as in the case of WMS (we only accounted for outgoing traffic), we decided not to show it for clarity. Note the small 95% confidence interval error bars.

In Figure 4 WMS is clearly the worst performer, taking almost twice as much time comparing to the other scenarios. This is due to the presence of two wireless hops in the communication path, more specifically, from the mobile client device to the AP and then from the AP to the mobile server device. WCS wins as a result of the much faster link between the central server and the AP. As we stated, WiFi-Direct could only be used up to 5 devices -4 clients and 1 server. We present only experiments with 1, 2 and 4 clients. It is hard to extrapolate the behaviour for larger number of clients but for low numbers of clients the results are similar to the best performer (WCS). The behaviour of WTMS is more subtle. While the 802.11z [START_REF]Amendment 7: Extensions to Direct-Link Setup[END_REF] specification extension allows for a peer to have multiple links to different base stations, in practice only 2 channels were available from the server at any given time, leading us to conclude that only one channel is available per radio (since our test devices, Nexus 9, have 2 radios), and thus no multiplexing is performed. This is visible in figure 5, where no traffic is routed through the AP up to 2 clients. The introduction of additional clients only shows limited savings on the traffic being routed through the AP. This is due to the 802.11z's mandatory periodical switch-over to the base channel (the regular AP's WiFi communication channel) to process buffered messages (by the AP).

Given this, if there are only two clients then the two radios can be used to setup TDLS channels. Adding more clients will result in the traffic being routed through the AP, that in turn, will lead to the server device to spend more airtime on one of the available channels to communicate with the AP. This will effectively only allow for 1 offloading channel to be available.

Figure 6 shows the energy consumed per experiment. The figure shows some similarity to Figure 4 which is expected since our application uses almost exclusively the WiFi hardware to send/receive replays; it does not play the videos on arrival, it just stores them. Hence, download time is an excellent proxy for energy consumption. We observed this correspondence for the other experiments we performed and therefore will not present more graphs on energy consumption in this paper. In absolute value, the energy spent in the downloads is rather small. For example, given the 25.5 Wh specification of the battery from the Nexus 9, this is equivalent to about 91000 Joule. The energy spent per download in, e.g., the WCS scenario, with 1 server and 1 client, is about 50 Joule/20 downloads = 2.5 Joule, corresponding to 0.002% of the total charge; this value grows to 0.02% when using 16 clients.

Multiple Servers

We extended our experiments to examine the impact of introducing multiple mobile servers in the mobile scenarios WMS and WTMS. Figures 7 and8 show the results obtained. In WTMS we introduced an extra level of refinement. In one case we let the clients choose a random server for each file to be downloaded from a predefined set -this is shown as WTMS D in the graphs. The alternative process is to statically map each file to a specific server from the start, potentially decreasing competition between clients -this is shown as WTMS S . We increase the number of servers, from 1 to 8, while using a fixed number of clients [START_REF] Erman | Understanding the super-sized traffic of the super bowl[END_REF]. Figure 7 shows the average download time with an increasing number of servers. The introduction of TDLS clearly decreases the download time, with the static assignment performing slightly better than the random assignment. This is due to the better client distribution that the static approach provides, decreasing the possibility of clients overloading a subset of the servers. The results show a slight increase of 20% in the download time with WTMS scenarios from 4 servers relative to the WCS scenario (for 12 clients) (c.f. Figure 4). This, however, is compensated by a 65% decrease in the traffic handled by the AP under WTMS with 8 servers (note that, in WMS as in WCS all traffic goes through the AP). Relative to the WMS scenario we also observe a 33% decrease in the download time.

We resorted to simulation using ns-3 to better understand the behaviour of TDLS, namely, how the number of successful TDLS links varied with the number of available servers in the WTMS (static) scenario. Since there is no native support in ns-3 for TDLS, we had to implement our own code to mimic the behaviour of the radio interfaces. Based on the available documentation and on our empirical experience we deduced that the Nexus 9 allows the use of 2 simultaneous channels that can be any combination of 802.11n and 802.11ac. To simulate this behaviour, we implemented each ns-3 node with 3 network interfaces (2×802.11ac, 1×802.11n), so that at any given time we can have 2 channels as in the Nexus 9. So, although the nodes have 3 software radio interfaces, if we have 1 or 2 clients connected to a server, the server node can only use 2 TDLS interfaces. If more than 2 clients are connected to a server, then we can only use 1 TDLS interface, and all the other connections are done via 802.11n (through the AP). An auxiliary class manages the TDLS connections, parametrized on the percentage of successfully established TDLS links.

We ran several simulations varying the percentage of TDLS connection success. The results show that, to explain the traffic values from Figure 8, the percentage of successful TDLS links must vary from 50% with 1 server to 60%-65% with 8 servers. We attribute this variation to the fact that, with more servers available, there are less clients per server. For example, with 8 servers we have 16 (2×8) 802.11ac channels available and hence, with 12 clients we can more easily establish TDLS connections, despite the extra global radio interference that leads to collisions. Also, it is apparent from Figure 7 that, in WTMS, the performance does not improve significantly beyond 4 servers. To understand why this happens we performed another experiment where we reduced the number of downloads from 20 to 1 and increased the size of the file to be dowloaded from 3MB to 60MB, so that, overall, the amount of traffic is identical.

Figures 9 and10 show the results of the experiment. By decreasing the number of downloads per experiment, we observed a decrease in the amount of traffic going through the AP (figure 10). This lead us to conclude that the initial setup for TDLS channels is causing a significant overhead. Since we are unable to inspect the internal behaviour of the network driver, we infer that the creation of a TDLS channel requires multiple attempts, probably due to contention and interference, resulting in a performance degradation. By decreasing the number of downloads (and thus the number of TDLS tunnel negotiations), the expected behaviour was verified with the introduction of additional servers, namely, each server is able to support 2 distinct channels, with 1 being allocated to the AP base channel in the presence of 3 or more clients. For example, in the case of 4 servers, there were 3 clients statically allocated with each server (statically assigned, represented by WTMS S ), while with 8 servers, we had 4 servers assigned with 2 clients and 4 servers assigned with 1 client.

The download time and amount of traffic tend to lower with the introduction of additional servers, as depicted in figures 9 and 10. However, there is a substantial amount of variation on the results due to the negotiation process of the TDLS links. As stated in 802.11z, if during the setup of a direct link the driver detects a beacon then the negotiation is aborted; or if the amount of traffic on a channel is high enough then the TDLS link could be renegotiated to a different channel, with the traffic between the two peers being redirected through the AP during that time.

Discussion

The fastest download time is achieved by the traditional infrastructure, mostly because it uses a very fast wired 1Gbit/s network between the server and the AP, and also because the AP did not reach saturation in our experiments, even with the highest number (16) of clients. However, the use of multiple servers in an ad-hoc network of devices, all within radio reach, allowed significant removal of traffic from the AP, up to a maximum of 65% less traffic using 8 servers. The corresponding download time for files is 20% higher than the one observed for the traditional server/AP infrastructure, which, in absolute figures, for 3MB files, results in a delay of ≈ 1 second. Energy-wise, the cost of transfer is small for the Nexus 9, with a nominal battery capacity of about 91000 Joules, amounting to 0.02% with the maximum number of clients competing for the files. Smartphone batteries have typical capacities an order of magnitude smaller and thus we would expect each download to require a few tenths of percent of the battery. Since each user individually is not expected to make many downloads during a game, battery shortage is, evidently, not a limitation. Thus, the user experience is not significantly diminished by the use of an ad-hoc network of devices to distribute contents while there are considerable gains in terms of removing stress from the AP.

Related Work

Managing the aggregate computational/storage resources of ad-hoc networks of mobile devices, such as smartphones and tablets, has become a hot topic of research in recent years. This results mostly from ongoing technological advances and the widespread use of the devices. Several projects have explored the technology's many angles, e.g., offloading, crowdsourcing, cost models, protocols, security, and its applications to distinct areas, e.g., commerce, learning, health, entertainment [14] [15].

FireChat [START_REF]OpenGarden's FireChat App[END_REF] is a proprietary mobile app, developed by Open Garden, that allows smartphones to organize into a wireless mesh network and exchange messages using available technologies such as Bluetooth or Wi-Fi. The iOS version uses Apple's Multipeer Connectivity Framework [START_REF]Apple's Multipeer Framework[END_REF] that enables services to be advertised and discovered between nearby iOS devices using different wireless protocols. Services can be provided through personal area type-of networks using infrastructure WiFi, peer-to-peer WiFi and Bluetooth.

Bonjour [START_REF]Apple's Implementation of Bonjour[END_REF] focus on three main areas: Addressing (allocating IPs to Devices), Naming (creating alias for each network device) and Service Discovery. The discovery works similarly to a publish-subscribe, where nodes advertise their services which then other nodes can use them. In order for devices in a network to be discovered, upon turning on the bonjour service, they send a announce themselves to the network. At the same time, other nodes in the network, already running a Bonjour Service, periodically ask the network what devices are available.

Alljoyn [START_REF]Alljoyn Framework[END_REF] is an, open source, agnostic network framework that allows different types of devices and apps to discover and communicate in an abstract way, hiding the complexity of distinct network protocols and hardware. Generically, it publishes APIs over the network through a general bus, which permits distinctive network technologies to be used, such as Wi-Fi, Wi-Fi Direct, Bluetooth, Ethernet and PowerLine. To the best of our knowledge only infrastructure WiFi is actually implemented. Regarding the network formation, Alljoyn, uses a super peer paradigm, mesh of stars network, where the leaf nodes are connected to router nodes and these act as bridges to the others router nodes.

Efforts to transform mobile networks into actual computational and/or storage resources have been the subject of fundamental work. In [19] [20] Hadoop was successfully ported into mobile devices connected though WiFi to perform map reduce computations. The goal was to identify the problems that might arise from porting a system developed for full-fledged cloud servers to a resourcestarved cloud of devices. Doolan et al. [START_REF] Doolan | MMPI a Message Passing Interface for the Mobile Environment[END_REF] try a different approach by adapting the well established Message Passing Interface (MPI) for mobile systems, with the goal of performing parallel processing over these platforms.

In [START_REF] Drolia | Motivating mobile edge-clouds[END_REF] the authors study the trade-offs between offloading computation to an infrastructure cloud versus retaining the computation within a mobile edgecloud. They present two diverse workloads for mobile edge-clouds based on the distribution of data and motivate the use of edge-clouds for one of them, specifically when data is inherently distributed in the edge-cloud it is better (in terms of latency and power consumption) to process them in an in-situ manner as opposed to transferring them to the infrastructural-cloud for processing.

Conclusions

In this paper, we study whether D2D protocols can be used to efficiently diseminate multimedia contents in networks of mobile devices. We do this by benchmarking different protocols and configurations for a specific application. Our first hypothesis, that the download speed would be improved with D2D protocols was not vindicated, although the number of devices we used (and had available) was really not enough to take the AP close to saturation, in which case we would expect such improvements. The observed difference and corresponding extra energy usage is small and does not degrade user experience. On the other hand, the experiments suggest that our second hypothesis, that the use of D2D protocols could significantly remove load from the AP, is valid for we observed a decrease in traffic up to 65% for a multiple server configuration.

Thus we conclude that D2D protocols that take advantage of existing wireless technologies can indeed be used to efficiently disseminate multimedia contents and, especially, to diminish the load in the traditional wireless infrastructure, a critical problem for service providers in large sports venues, while maintaining a good user experience.

We plan to expand this line of work to include network overlays in order to create a fully decentralized and self organizing mesh that leverages the different underlying wireless protocols.

Fig. 1 .

 1 Fig.1. a) WCS -central server, access point, mobile clients, using WiFi. b) WMSaccess point, mobile servers, mobile clients, using WiFi. c) WTS -access point, mobile servers, mobile clients, using WiFi/TDLS. d) WDMS -group owner, mobile server, mobile clients, using WiFi-Direct.

Fig. 2 .

 2 Fig. 2. Algorithm for running the experiments.

Fig. 3 .

 3 Fig. 3. The experimental setup.

Fig. 4 .

 4 Fig. 4. Average download time per file.

Fig. 5 .

 5 Fig. 5. Traffic handled by the AP.

Fig. 6 .

 6 Fig. 6. Average energy consumed per experiment.

Fig. 7 .

 7 Fig. 7. Average download time per file.

Fig.

  Fig. Traffic handled by AP.

Fig. 9 .

 9 Fig. 9. Average download time while using a 60MB file.

Fig.

  Fig. Traffic handled by AP while using a 60MB file.

As a note, Android TDLS implementation switches automatically between the 2.4 and 5GHz bands and this is neither controlable and observable from the API.

Acknowledgment

This work has been sponsored by projects HYRAX (CMUP-ERI/FIA/0048/2013), funded by FCT, and SMILES (NORTE-01-0145-FEDER-000020), funded by NORTE 2020, under PORTUGAL 2020, and through the ERDF fund.


Bijun Li

Rüdiger Kapitza
email: kapitza@ibr.cs.tu-bs.de

Marcel Hauschild

Philipp Kessler

Matthias Markiewka

Manuel Natho

BFT-Dep: Automatic Deployment of Byzantine Fault-Tolerant Services in PaaS Cloud

Keywords: Automatic Application Deployment, Platform as a Service (PaaS) cloud, Byzantine Fault Tolerance

Cloud computing has been a massive trend over the recent years and eased the deployment of scalable distributed applications. While initially renting out virtual machines was the predominant form of cloud computing, nowadays Platform as a Service (PaaS) solutions are emerging. The main advantages of the latter are a faster and easier application deployment as well as built-in support for horizontal scalability. However, when it comes to services with more demanding dependability requirements, currently provided deployment mechanisms quickly become insufficient, forcing cloud customers to fall back into manual, self-made strategies. In this paper, we present BFT-Dep, a framework for deploying Byzantine fault-tolerant (BFT) services in a PaaS cloud automatically. BFT-Dep leverages the existing PaaS functionality to address specific deployment requirements and provides tailored support to set up and manage replicated services. It flexibly integrates BFT protocols as an independent service layer, thereby alleviating the complexity that the deployment of such systems entails. An initial prototype of BFT-Dep has been implemented on top of the open-source PaaS platform OpenShift and a first evaluation shows its practicability.

Introduction

Cloud computing [START_REF] Zhang | Cloud computing: state-of-the-art and research challenges[END_REF] offers a new form of resource provisioning, where services and applications are no longer hosted on local computing resources but on shared ones provided by remote infrastructures. Customers, i.e. software developers, are offered with services delivered over the Internet without having to manage and maintain the underlying hardware or system software that hosts these services.

Although delivering virtual machines is the most common form of cloud offering, Platform as a Service (PaaS) clouds [START_REF]Cloud foundry[END_REF][START_REF]Google app engine[END_REF]13,[START_REF] Openshift | [END_REF], are getting increasingly popular. PaaS clouds aim at helping customers to quickly deploy and run their applications without considering infrastructure management tasks. Contrary to lower-level cloud services, non-functional properties like horizontal scalability are often part of the built-in features of these platforms. This makes PaaS clouds particularly appealing for more critical applications. However, if the applications depend on state, current PaaS solutions fall short as they lack deployment strategies for dependable stateful services. When services need to be replicated for high availability, the deployment is not a question of configuring independent service instances anymore, but of setting up and coordinating collaborating and highly interconnected replicas. This becomes even more complex, if the systems are supposed to tolerate not only crash faults but also Byzantine faults. For all that, cloud customers have to implement and maintain custom solutions, contradicting the primary goal of an automatic deployment in PaaS clouds.

This paper presents BFT-Dep, a novel application deployment framework that automatically sets up Byzantine fault-tolerant (BFT) [START_REF] Castro | Practical byzantine fault tolerance[END_REF] applications in PaaS clouds. Based on state-machine replication [START_REF] Schneider | Implementing fault-tolerant services using the state machine approach: A tutorial[END_REF], BFT is able to tolerate crashes as well as arbitrary faults. By encapsulating BFT replicas into PaaS conform services, BFT-Dep simplifies the deployment of replicated applications without requiring changes to the cloud itself, and handles coordination among replicas automatically. An initial realization of BFT-Dep has been implemented as an extension of the popular open-source PaaS cloud OpenShift [START_REF] Openshift | [END_REF] and by using BFT-SMaRt [START_REF] Bessani | State machine replication for the masses with bft-smart[END_REF][START_REF]Bft-smart[END_REF] to enable replication.

Research works, which integrate Byzantine fault-tolerance protocols into cloud infrastructures to tolerate Byzantine failures have been proposed [START_REF] Bessani | Depsky: dependable and secure storage in a cloud-of-clouds[END_REF][START_REF] Cogo | Fitch: Supporting adaptive replicated services in the cloud[END_REF][START_REF] Garraghan | Using byzantine fault-tolerance to improve dependability in federated cloud computing[END_REF][START_REF] Verissimo | The tclouds architecture: Open and resilient cloud-of-clouds computing[END_REF]. Also at middleware level, BFT has been combined with multi-tier web services to guarantee their heterogeneous reliability requirements [START_REF] Merideth | Thema: Byzantine-fault-tolerant middleware for web-service applications[END_REF]. Unlike them, our work is targeting the automatic deployment of reliable applications as an enhancement and extension of PaaS cloud functionality thereby making BFT services easier to deploy and manage.

The remainder of the paper is organized as follows: Section 2 explains the system design of BFT-Dep, Section 3 shows an implementation of BFT-Dep on a popular open-source PaaS cloud with interim evaluation results, and Section 4 concludes the paper and indicates future works.

System Design

An integral part of replicated Byzantine fault-tolerant services is the agreement protocol. It is responsible for coordinating the order in which requests must be executed by the stateful replicas to ensure the consistency of non-faulty ones. Consequently, to enable an easy deployment of BFT systems, the agreement protocol has to be integrated into the PaaS platform. BFT-Dep achieves this by introducing a BFT agreement layer that is separated from the application replicas (see Figure 1). The BFT agreement layer can be realized using a common BFT protocol implementation [START_REF] Behl | Consensus-oriented parallelization: How to earn your first million[END_REF][START_REF] Castro | Practical byzantine fault tolerance[END_REF][START_REF] Kotla | Zyzzyva: speculative byzantine fault tolerance[END_REF]. In principle this follows separation of agreement and execution stages [START_REF] Yin | Separating agreement from execution for byzantine fault tolerant services[END_REF] and the typical assumptions for Byzantine fault-tolerant systems are made. A minimum of 3f + 1 replicas are required to tolerate up to f Byzantine faults. Faulty replicas may crash or behave arbitrarily and maliciously. However, they are unable to break cryptographic techniques so that they cannot corrupt authenticated messages without being noticed. Note that enforcing fault tolerance of the cloud infrastructure itself is out of scope, as it is an orthogonal issue and has been addressed before [START_REF] Brenner | Adaptive and scalable high availability for infrastructure clouds[END_REF]. We build the BFT agreement layer by containerizing a BFT protocol, e.g. using Docker [START_REF] Docker | [END_REF], into the software stack of a PaaS platform as a built-in service. Thus a BFT replica can be deployed and operated in the same way as any other service instances of a PaaS cloud. This way, BFT-Dep is able to leverage as much as possible the existing PaaS cloud facilities and is to a large extent immune to cloud architecture changes. When deploying applications, BFT-Dep first creates and configures a set of BFT replicas to establish the BFT agreement layer and then instantiates replicas for the customer's application. BFT-Dep guarantees that the application replicas together with their associated BFT replicas are distributed over different hosts of the cloud for fault independence. Each BFT replica exposes an access entry point to the clients. Upon receiving requests, the replicas of the BFT agreement layer first order them and then forward the requests to the corresponding application replicas. To do so, each BFT replica needs to connect to the application replica that locates on the same host to keep communication latency low. Application replicas then generate replies and send them back to the client through the BFT agreement layer, and the client will eventually verify the replies.

Implementation

We chose OpenShift Origin v3 [17] to implement BFT-Dep. Since BFT-Dep assumes a container-based PaaS model, it is not bound to a specific platform but can be applied to most PaaS clouds built upon containers. Furthermore, BFT-SMaRt [START_REF] Bessani | State machine replication for the masses with bft-smart[END_REF][START_REF]Bft-smart[END_REF], a well-known BFT protocol implementation written in Java, was chosen for evaluation.

BFT Replicas Generation

BFT Image OpenShift uses Docker containers [START_REF] Docker | [END_REF] that are built from Docker images for application deployment and management. A Dockerfile containing all necessary commands is needed for assembling an image. For building the BFT replica image, we use an off-the-shelf Java image as the basis and customize it to import the BFT-SMaRt source code. The necessary ports for connecting to other replicas as well as the associated application replica are declared. We eventually push the built image to a Docker Hub [10] repository, so that it can be conveniently imported to the PaaS cloud as an image stream creating BFT containers.

BFT Pods and Services

In OpenShift, the smallest deployable and manageable unit, the so-called pod, is responsible for holding the runtime environment of a set of containers. In BFT-Dep, we specify a JSON file to explicitly describe the features of BFT replica pods. A unique name as well as a label are assigned to distinguish pods. When creating replicated BFT pods, the BFT image is imported and the ports declared in the image need to be opened by the pod as well. BFT-Dep enforces those pods' allocations by assigning each one to an individual host of the PaaS installation, as replicas should always be distributed to different machines. We achieve this by specifying a hostPort item in the BFT pod description file so that according to the default scheduling policy, pods with the same hostPort number cannot be allocated onto the same host.

The unit service in OpenShift is defined as an abstraction of one or multiple pods, being responsible for exposing a stable service entry point regardless of underlying pod changes. A label selector is used to find all matching pods for the same service. We build BFT services upon individual BFT pods to forward external traffic. A temporary helper pod is used to configure and setup a cluster. It collects IP addresses of all BFT pods to update their host settings and then starts the BFT-SMaRt replica inside each pod. This way, BFT-SMaRt replicas can eventually connect to each other to agree on the order of client requests.

BFT Application Deployment and Networking

In OpenShift, customers use a template (a description file) to package application runtime dependencies for deployment. BFT-Dep offers a specific template for deploying BFT services and replicated applications. When using this template, BFT services are automatically generated and so are the application replicas, while their allocations are enforced by BFT-Dep as explained above. Each BFT service thereby connects to the application replica on the same host via socket connections. BFT services first order the received requests via public IPs, and forward to the corresponding application replicas for execution, and eventually send the replies back to the clients.

Interim Evaluation

We installed OpenShift v3 on a cluster of AWS EC2 instances (all in US East), composed of one master and four plain nodes. Each EC2 instance is equipped with an elastic IP for public accesses from PaaS customers and clients.

We conducted an interim evaluation of our preliminary BFT-Dep prototype using a simple key-value store application and the YCSB benchmark [20]. A workload of combined read and update operations is used for testing three deployment scenarios, as shown in Figure 2: 1) BFT and application deployed on EC2 instances together, 2) BFT and application deployed in OpenShift together, and 3) BFT and application deployed by BFT-Dep separately. Results of average latency indicate that the extra delay of using BFT-Dep introduced by the socket connections between BFT replicas and application services is low.

Conclusion and Future Works

We presented BFT-Dep, a framework leveraging existing PaaS facilities to address reliability demands of stateful application services. By integrating BFT protocols into the cloud platform as a built-in service layer, BFT-Dep offers customers the capability of automatically deploying and coordinating fault-tolerant applications while the PaaS platform itself can be left unchanged. Our preliminary BFT-Dep prototype has been implemented on top of OpenShift. The interim evaluation shows that the overhead that is added by a containerized BFT protocol implementation is low.

For future works, we plan to make BFT-Dep more generically applicable and enable reconfiguration and distribution changes as supported by BFT-SMaRt.

Fig. 1 .

 1 Fig. 1. Architecture of BFT-Dep

Fig. 2 .

 2 Fig. 2. Evaluation of read and update latencies with YCSB benchmark.

This research was supported by Siemens Rail Automation Graduate School (iRAGS).


Laurence Lux

HAL is

Since the articles of each section will be familiar to those who have followed Walsham's work between 2000 and 2010, a detailed summary unnecessary. More importantly, it seems unbefitting to give a fragmented account of a book which is essentially about decompartmentalisation and the breaking down of artificial boundaries. For this is, to my mind, this book's essential contribution: at every turn, Alexandra Walsham breaks down the long-held yet little-evidenced caesuras between pre-and post-Reformation Catholic practice, between recusants and outward conformists, between Catholics and their Protestant neighbours, or between British Catholics and their continental counterparts. Conversely, she re-examines the assumption that lived experience was ever a perfect match for institutional directions, and she argues that the importance of Tridentine instructions has often been overestimated.

Building upon the foundations she cast with her Church Papists, Alexandra Walsham dwells upon the strategies which both lay and clerical Catholics developed to cope with the restrictions imposed upon them by the law. Her own work, like that of others such as Michael Questier's Catholicism and Community (2006), highlights the diversity of Catholic practice with regards to recusancy or conformity; it reveals a level of diversity in Catholic semiseparatism which complexifies our understanding of the Catholic community. Early modern British Catholicism can no longer be seen as a monolith, but rather must be construed as a kaleidoscope, in which the practice was often idiosyncratic, and at times even evolved from conformity to recusancy and vice-versa.

Yet, if occasional conformity was a highly effective strategy of survival, it was also a point of controversy, the object of much fear in anti-Catholic publications, and of much anguish and debate amongst Catholics themselves. Conformity touched upon the definition of confessional identity, facing many subjects of the crown with an ethical dilemma which Walsham calls "ordeals of conscience" (103). It also questioned political allegiance and the issue of loyalism, which Stephania Tuttino has studied. Moreover, Walsham shows that we must not continue to consider English society as clearly divided along confessional lines. Communities interacted constantly, more or less successfully, more or less willingly, but the representation of a confessional divide which was inviolable ignores the flexibility, the pragmatism, and the fluidity of the relationships between Protestants and Catholics in early modern England. As Ethan Shagan has demonstrated, Catholics did, in fact, contribute to the building of the nation and of its politics; at local level, they continued to be influential in county politics, even when key English members of the Society of Jesus were involved in international plots and in the writing of political theory justifying the primacy of the pope over the English monarch. Walsham convincingly shows that there existed a complex and nebulous world at the interface of the polarised stances of conformity and loyalism or resistance and subversion.

Adaptability, resourcefulness, but also continuity, are also keywords in Walsham's study of the strategies implemented for an effective mission; focusing, for instance, upon miracles, pilgrimages and the role of angels, the author shows that the supernatural played an important part in the attractiveness of Post-Reformation Catholicism in England and in Wales. The case of Holywell illustrates the elite's tactical decision to build upon the foundations cast long before the Catholic Reformation, to foster popular attachment both to cult and place. Arguably, the supernatural and elements of Pre-Tridentine or pseudo-pagan tradition were instrumentalised in the mission for their power to edify, stimulate and convert. In her studies, Walsham demonstrates that the historiographical insistence upon the Council of Trent as an effective watershed which reformed and transformed Catholic practice has been greatly overstated.

One of the book's leading arguments is that practices were reorganised and recast in order to integrate the restricted access to priests and sacraments. In another historiographical mythbusting effort, the author goes against the long-held assumption that Catholicism was not a religion of the book. Walsham highlights the immense influence of printed works in a mission where clergy were sometimes difficult to obtain and were books played the roles of "dumb preachers" (133). She insists upon the importance of the rise of reading and writing literacy; she dwells upon the role of scripture in the vernacular as well as printed polemics, in conjunction with older modes of communication, to show that in this respect also, the old and the new worked in unison and were not mutually exclusive. This book is therefore a precious publication for any scholar of early modern Catholicism, or indeed of early modern religion at large. I will register only one regret: although the title announces a study of 'Britain', the focus is clearly on England and Wales, with limited reference to Scotland and Ireland. This is due to the very nature of this publication, which gathers articles centred upon England and Wales without the addition of new case studies. However, this book demonstrates once more Alexandra Walsham's ability to draw bridges between domains which have long been thought separate; with this in mind, one can but hope that she will, in time, produce an in-depth comparative study of the British dimensions implied by her outstanding research.


Divya Gupta
email: divya.gupta@imag.fr

Lucas Perronne
email: lucas.perronne@imag.fr

Sara Bouchenak
email: sara.bouchenak@insa-lyon.fr

BFT-Bench: Towards a Practical Evaluation of Robustness and Effectiveness of BFT Protocols

Keywords: Fault Tolerance, Byzantine Faults, Fault Injection, Performance, Robustness, Benchmarking

Byzantine Fault Tolerance (BFT) is an interesting means to make computing systems resilient in presence of failures and attacks. That being said, designing and implementing BFT protocols is a hard and tedious task. This first comes from the inherent complexity of designing BFT distributed protocols, reasoning about their correctness, and implementing the software prototype of the protocols in a consistent and efficient way. Another reason that makes BFT protocols hard and error prone is the lack of tools for testing and evaluating protocols implementations in various and realistic settings. Furthermore, BFT protocols differ in many aspects, ranging from the faulty behaviors they handle, to the communication patterns and cryptographic mechanisms they apply. Thus, a comprehensive benchmarking environment is still missing to easily analyze and compare the effectiveness and performance of these protocols. In this paper, we present BFT-Bench, the first benchmarking framework for evaluating and comparing BFT protocols in practice. BFT-Bench includes different BFT protocols implementations, their automatic deployment in a distributed setting, the ability to define and inject different faulty behaviors and workloads, and the online monitoring and reporting of performance and dependability measures. The experimental results of the evaluation of BFT-Bench show the effectiveness of the framework, easily allowing an empirical comparison of different BFT protocols, in various workload and fault scenarios.

Introduction

Cloud computing environments are now increasingly common. With their expansion, unpredictable events such malicious attacks, network delays, data corruption, and other types of Byzantine faults require specific fault tolerance mechanisms. Byzantine Fault Tolerance (BFT), based on state machine replication, consists in replicating the critical service in several replicas running on different nodes, and thus, ensuring service availability despite failure occurrence [START_REF] Schneider | Implementing Fault-tolerant Services Using the State Machine Approach: A Tutorial[END_REF]. When clients access the service, this is done through a specific BFT communication protocol that ensures that client requests are processed by replicas in the same order.

There has been a large amount of work on Byzantine Fault Tolerance (BFT) protocols. Early efforts have explored the practicality of Byzantine Fault Tolerance, with PBFT protocol [START_REF] Castro | Practical Byzantine Fault Tolerance[END_REF]. Other efforts have been made to improve the performance of the protocols and reduce the cost they induce due to many message rounds and cryptographic operations. Thus, some BFT protocols focus on improving performance in fault-free cases [START_REF] Van Renesse | Chain Replication for Supporting High Throughput and Availability[END_REF][START_REF] Kotla | Zyzzyva: Speculative Byzantine Fault Tolerance[END_REF][START_REF] Aublin | The Next 700 BFT Protocols[END_REF], while other protocols improve performance in presence of failures, each one proposing and applying techniques to counter specific types of faults such as network contention, system overload, etc. [START_REF] Aublin | RBFT: Redundant Byzantine Fault Tolerance[END_REF][START_REF] Clement | Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults[END_REF].

However, there has been very little in the way of empirical evaluation of BFT protocols. Evaluations of the protocols have often been conducted in an ad-hoc way, which makes them difficult to reproduce, and compare with new protocols. Moreover, it is generally admitted that BFT protocols are too complex to implement, thus, re-implementing them each time a new protocol must be compared with existing ones is not realistic.

In this paper, we present BFT-Bench, a benchmarking environment for evaluating performance and robustness of Byzantine fault tolerance systems. BFT-Bench enables the definition of various execution scenarios and faultloads, their automatic deployment in an online system, and the production of various monitoring statistics. This provides a means to analyze and compare the effectiveness of the protocols in various situations. BFT-Bench is an open framework that includes state-of-the-art BFT protocols, and may be extended with new BFT protocols. In addition, the paper presents an evaluation with BFT-Bench, empirically comparing different BFT protocols, and exhibiting their level of performance and robustness in different scenarios.

The remainder of the paper is structured as follows. Section 2 discusses the related work. Sections 3 presents BFT-Bench. Section 4 describes the experimental evaluation, and Section 5 concludes the paper.

Related Work

A Byzantine fault tolerant system is able to counter arbitrary faults, ranging from hardware crash, to message corruption, network congestion, or any other misbehavior. In the following, we review the related work on Byzantine fault tolerance, and BFT benchmarking.

BFT From Theory to Practice. BFT State Machine Replication (SMR) consists in replicating the underlying service in several replicas, to ensure service availability and correctness despite fault occurrence [START_REF] Schneider | Implementing Fault-tolerant Services Using the State Machine Approach: A Tutorial[END_REF]. Such a service handles requests coming from concurrent clients. Thus, to ensure consistency among service replicas, an agreement protocol is applied to guarantee that client requests are executed in the same order by correct service replicas. Reaching an agreement requires 3f + 1 replicas to handle upto f arbitrary faults [START_REF] Pease | Reaching Agreement in the Presence of Faults[END_REF].

BFT Performance Improvement in Fault-Free Conditions. One of the main drawbacks of BFT was its cost. Thus, everal protocols were proposed to enhance the performance of BFT protocols while maintaining their correctness. A first family of BFT protocols aims at improving the performance of the protocols in the absence of faults. They usually run a lightweight version of the protocol in fault-free cases, and switch to a more robust version of the protocol at fault occurrence. This is interesting in scenarios where faults occur rarely, and where it is more interesting to provide priority to fault-free cases. Examples of such protocols are Zyzzyva [START_REF] Kotla | Zyzzyva: Speculative Byzantine Fault Tolerance[END_REF], Chain [START_REF] Van Renesse | Chain Replication for Supporting High Throughput and Availability[END_REF], and Aliph [START_REF] Aublin | The Next 700 BFT Protocols[END_REF], allowing to improve clients request throughput/latency. BFT Performance Improvement in Presence of Faults. Another family of BFT protocols intends to improve performance in presence of faults. Roughly speaking, these protocols provide practical and efficient mechanisms to specifically handle some misbehaviors (i.e., fault types). Aardvark [START_REF] Clement | Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults[END_REF], Prime [START_REF] Amir | Byzantine Replication Under Attack[END_REF], Spinning [START_REF] Veronese | Spin One's Wheels? Byzantine Fault Tolerance With a Spinning Primary[END_REF], and RBFT [START_REF] Aublin | RBFT: Redundant Byzantine Fault Tolerance[END_REF] are examples of such protocols.

BFT Simulation and Benchmarking. General performance benchmarks have been proposed to evaluate the performance of application servers, web servers, data management systems, etc. Other solutions consider benchmarking dependability to provide a means to characterize system behavior in presence of faults. They consider different underlying systems such as MapReduce [START_REF] Sangroya | Benchmarking Dependability of MapReduce Systems[END_REF], or web servers [START_REF] Durães | Dependability Benchmarking of Web-Servers[END_REF]. Less effort has been done for benchmarking BFT systems. BFT-SMaRt is a replication engine that implements a BFT protocol; it interestingly includes a tool for evaluating the BFT protocol [START_REF] Bessani | State Machine Replication for the Masses with BFT-SMART[END_REF]. However, it is limited to the assessment of that particular protocol. Simulators of BFT protocols were also proposed [START_REF] Singh | BFT Protocols Under Fire[END_REF][START_REF] Lee | Turret: A Platform for Automated Attack Finding in Unmodified Distributed System Implementations[END_REF]; in contrast, in this paper we consider the empirical evaluation of BFT. Thus, there is a need for a comprehensive benchmarking environment to help researchers and practitioners to conduct empirical studies and better analyze and evaluate the performance and robustness of BFT protocols.

BFT-Bench Framework

BFT-Bench framework allows empirical evaluation and comparison of stateof-the-art and new Byzantine fault-tolerance systems. Figure 1 describes the major components of BFT-Bench: (i) several BFT protocols implementations, (ii) fault scenarios to be injected in the underlying BFT system, (iii) load to be injected in the running underlying system, and (iv) monitoring statistics to report performance and dependability statistics the system. Thus, BFT-Bench enables automatic deployment of the experiments in a distributed system that consists of several nodes running the replicas of the BFT protocol, and one or multiple nodes emulating clients sending concurrent requests to the BFT system.

BFT Protocols

BFT-Bench is intended to be an open framework that can be extended with new BFT protocols to evaluate, new fault models. In this paper, the following stateof-the-art BFT protocols are considered: PBFT for being the first practical BFT protocol [START_REF] Castro | Practical Byzantine Fault Tolerance[END_REF]; Zyzzyva, Chain, and Aliph for their performance efficiency in faultfree conditions [START_REF] Kotla | Zyzzyva: Speculative Byzantine Fault Tolerance[END_REF][START_REF] Van Renesse | Chain Replication for Supporting High Throughput and Availability[END_REF][START_REF] Aublin | The Next 700 BFT Protocols[END_REF]; Aardvark, and RBFT as instances of robust protocols that improve performance in presence of failures [START_REF] Clement | Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults[END_REF][START_REF] Aublin | RBFT: Redundant Byzantine Fault Tolerance[END_REF]. These protocols were chosen for their variety of features, their variety of communication patterns as described in Figure 2, and their variety in terms of fault types the protocols prototypes actually handle (see Section 3.2).

Practical BFT Protocol. PBFT's communication pattern is used as a baseline many other protocols such as Aardvark and RBFT [START_REF] Clement | Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults[END_REF][START_REF] Aublin | RBFT: Redundant Byzantine Fault Tolerance[END_REF]. In PBFT, upon a client request the primary sends pre-prepare messages to other replicas with assigned sequence number to the request. Then, prepare messages and commit messages are exchanged to agree on the sequence number. If PBFT suspects the primary to be malicious, it undergoes a view change to replace the primary by another replica.

Protocols Enhancing Performance in Fault-Free Conditions. Zyzzyva is a speculative, high throughput BFT protocol [START_REF] Kotla | Zyzzyva: Speculative Byzantine Fault Tolerance[END_REF]. Its design is meant to bypass the expensive agreement steps of PBFT in fault-free settings. In such scenario, the clients send their requests to the primary in charge of assigning sequence numbers. The primary then forwards the ordered requests to the other replicas, which speculatively execute these requests and send the responses to the clients. If a client receives 3f + 1 consistent matching responses, it commits. Otherwise, clients apply additional steps such as collecting commit certificates and creating proofs of misbehaviors to trigger view change. Chain protocol, as its name suggests and as described in Figure 2(b), follows a chain-like communication pattern where clients send requests to the head replica, which itself sends messages to its successor replica, and so on [START_REF] Van Renesse | Chain Replication for Supporting High Throughput and Availability[END_REF]. Chain greatly benefits from batch optimization where multiple messages are sent in one batch, which improves system throughput, with a peak of performance when the system is completely saturated (i.e., when the network link between any two servers is fully loaded). However, Chain by itself is unable to ensure Byzantine fault tolerance, and must rely on a protocol switching mechanism when subject to failures.

Aliph protocol involves several sub-protocols [START_REF] Aublin | The Next 700 BFT Protocols[END_REF]. Its initial configuration, Quorum, is dedicated to provide high performance if the system does not involve asynchrony, contention, or failures. When facing contention, Quorum is replaced by Chain. Finally, upon occurrence of Byzantine behaviors, Chain is replaced by a backup protocol that handles Byzantine faults, for example PBFT. In Quorum, clients directly send requests to all replicas. These replicas independently execute the requests, updates their local history and reply to the clients. Note that the ordering phase commonly performed by the primary replica is skipped in Quorum, thus providing a better response time. Thus, in Aliph the client side of the protocol is responsible of managing inconsistencies, and relies on a panicking mechanism to trigger sub-protocol switching. Protocols Enhancing Performance in Presence of Faults. Aardvark prototype implements efficient fault tolerance mechanisms for faults such as intentional message delay, network flooding, or clients sending corrupted requests to the system [START_REF] Clement | Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults[END_REF]. To handle these fault types, Aardvark uses mechanisms such as replica blacklisting or digital signatures, to minimize the impact of faulty components on the overall system performance.

RBFT strengthens the architecture of PBFT and incorporates adaptive mechanisms to deal with different faulty behaviors [START_REF] Aublin | RBFT: Redundant Byzantine Fault Tolerance[END_REF]. RBFT runs f + 1 multiple instances of the same BFT protocol in parallel but the requests are executed only by one of the instances called master instance, while other f instances are called backup instances. Each backup instance has its own primary which orders the incoming requests in order to monitor the difference of throughput between the master instance and itself. If the performance at backup and master instance differs by a given threshold at not less than 2f + 1 replicas, the primary replica at master instance is considered faulty and a view change is triggered, where a new primary is elected at every instance.

Fault Injection

In the following, we first describe the fault types that are handed by state-of-theart BFT protocols presented in Section 3.1, and how BFT-Bench injects them in a running system. We then present how to describe a faultload, i.e. fault scenario to be injected by BFT-Bench.

Fault Types Examples

Replica Crash. Upon a replica crash, the replica stops and does not participate in any further communication with the clients or the other replicas of the BFT protocol. In practice, BFT-Bench remotely connects to the target replica node and kills the replica process. Note that the implementation of this fault type injection is BFT protocol-independent, thus, it does not require changes to BFT protocols prototypes.

Message Delay. When a replica starts delaying messages, it slows down all future operations of the protocol depending on these messages, thus, leading to degradation in performance. As a result, this Byzantine behavior is especially critical when it occurs at the primary replica. In practice, BFT protocols prototypes are extended to integrate the injection of this type of fault. When BFT-Bench triggers this type of fault, instead of sending messages according to the protocol specifications, the replica process sleeps during a given delay, before resuming to send any messages to other replicas.

Network Flooding. Network flooding is a common denial-of-service attack. It is meant to overload the network with malicious messages which can not be said invalid until verified. This verification of messages is computation-intensive and prevents the system from focusing on correct messages. In practice, BFT protocols prototypes are extended to integrate the injection of this type of fault. When BFT-Bench triggers this type of fault, the faulty replica transmits corrupted messages of a chosen size to other replicas. System Overload. Overloading the system with a large number of concurrent client requests can affect system performance to a large extent. Although none of the servers behave maliciously in this attack, but continuous increase in concurrent clients can eventually deteriorate the performance or lead to system thrashing. To inject this behavior, BFT-Bench remotely connects to the node in charge of emulating concurrent clients, and starts additional client processes.

Faultload. A faultload in BFT-Bench is described in a file. Each line of the faultload file consists of the following elements: the time at which a fault occurs (relative to the beginning of the experiment), the type of fault that occurs, where the fault occurs, and optionally, additional parameters that depend on the type of fault. A fault belongs to one of the fault types handled by BFT protocols prototypes, and introduced in Section 3.2. A fault occurs in one of the BFT protocol replicas; this replica may be either explicitly specified in the faultload or randomly chosen among the set of replicas.

Thus, a faultload in BFT-Bench may contain the following element to describe the injection of fault of type crash: <[fault trigger time], replica crash, replica x > It may contain the following element to describe the injection of fault of type message delay, specifying among others the delay to be injected, and the duration of occurrence of this type of fault: In this example, the cluster has N + 2 nodes, where N = 3f + 1 nodes are BFT replicas, one node hosts concurrent clients emulator, and one node runs BFT-Bench. BFT-Bench faultload injector uses faultload to determine which type of fault is to be triggered, at what time this fault will be injected, and other required fault parameters. The fault injector runs a daemon that communicates directly with the replicas to trigger faults. For instance, in case of replica crash, the daemon waits until the fault trigger time is reached, then calls remotely interacts with the target replica to actually trigger the fault.

Load Injection

The workload is first characterized by number of concurrent clients sending requests to the BFT system. Client requests are executed in FIFO order in a closed loop, where a clients submits a request, waits for the request to get processed and receives a response, before sending another request. The workload is also

Monitoring

BFT-Bench produces performance statistics for evaluating and comparing the performance of BFT protocols. Throughput and Latency are the main performance parameters considered when evaluating Byzantine Fault Tolerance protocols, both experimentally and theoretically. Latency is the time elapsed from the moment a client submits a request until the complete response is received by this client. Throughput is measured as the number of client requests handled by the system per unit of time. Latency and throughput are measured by BFT-Bench at the client-side, and thus include network communication times between the client and the replicas. Furthermore, BFT-Bench produces low-level system monitoring information such as cpu, memory and network usage, that can help better explaining the behavior and possible bottlenecks of the system.

On Extensibility of BFT-Bench

BFT-Bench is an open framework intended to help BFT protocol designers and practitioners to easily evaluate their protocols. BFT-Bench includes, among others, existing implementations of BFT protocols. In this paper, we illustrated the use of BFT-Bench with several state-of-the-art BFT protocols prototypes. In the following, we describe how to integrate a new BFT protocol prototype to BFT-Bench, and benefit from its benchmarking features. Although most of the components of BFT-Bench framework are general and can be easily reused for new BFT protocols, there are some exceptions that we describe below. Workload injection is based on the client emulator program that comes with a BFT protocol prototype. Such a program is pretty simple, and its reuse to allow dynamic workload variation as provided by BFT-Bench is straightforward. For the implementation of faultload injection for faults like replica crash or system overload, the implementation is independent from the actual BFT protocol prototype. This is not the case of faults of type message delay or network flooding that need an extension of the underlying BFT protocol prototype.

Experimental Evaluation

Experimental Setup

The experiments presented in this paper were conducted on a cluster of Grid'5000 [START_REF] Cappello | Grid'5000: A Large Scale and Highly Reconfigurable Grid Experimental Testbed[END_REF]. Each node hosts two Quad-Core Intel Xeon E5420, with 2.50 GHz, 8 GB of RAM, and 160 GB of storage; nodes are connected through 1 GB Ethernet. BFT-Bench framework currently includes six BFT protocols, namely PBFT, Chain, RPFT, Aardvark, Aliph, Zyzzyva [START_REF] Castro | Practical Byzantine Fault Tolerance[END_REF][START_REF] Van Renesse | Chain Replication for Supporting High Throughput and Availability[END_REF][START_REF] Aublin | RBFT: Redundant Byzantine Fault Tolerance[END_REF][START_REF] Clement | Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults[END_REF][START_REF] Aublin | The Next 700 BFT Protocols[END_REF][START_REF] Kotla | Zyzzyva: Speculative Byzantine Fault Tolerance[END_REF]. We used the original C++ code of these protocols. When needed by the evaluated BFT protocol, multiple virtual network interfaces are created on a single physical network interface controller to exploit the robustness of protocol, e.g., Aardvark, RBFT.

For each protocol under evaluation, four nodes are used for running the replicas of the service (i.e., application), thus, f = 1. Two other nodes are used for the experiments, one for emulating the clients that concurrently send requests to the replicated service, and one node for hosting BFT-Bench. Similarly to stateof-the-art evaluations, each replica runs an echo service [START_REF] Castro | Practical Byzantine Fault Tolerance[END_REF]. Client request size and client response size are 4 KB each. Furthermore, to emulate the computation performed by the service, a delay of 100 (±10%) µs is introduced before sending the response to the client. The results of the experiments are obtained after a warm-up phase of 180 s, to let the system reach a stable stage before actually measuring the behavior of the system. The graphs presented in the following are obtained after the warm-up phase.

Evaluation in Presence of Replica Crash

In this use case, five concurrent clients access the replicated service, when the crash of the primary replica of the service occurs. Thus, the following faultload is provided to BFT-Bench, which triggers a fault at time 300 s: <300 s, replica crash, {primary}> Figure 4 presents the measured latency and throughput. Upon crash of the primary, PBFT induces a sudden increase in latency, and throughput drops sharply. This is due to the view change mechanism used by the protocol to replace the faulty primary. Aliph follows the same pattern since it switches to PBFT upon fault occurrence. Upon crash, Chain cannot maintain its pipeline structure as the successor of the crashed server never receives any message. In theory, Chain must switch to PBFT upon crash, but unfortunately this mechanism is not present in the Chain prototype. Zyzzyva prototype implements only the fault free version of the protocol and, thus, does not deal with fault occurrence. In Aardvark and RBFT where clients broadcast requests to all replicas, and because of the absence of a crash handling mechanism at client side, this fault is not handled.

Evaluation in Presence of Message Delay

In this use case, a replicated service is accessed by two concurrent clients, when the service starts misbehaving by inducing intentional and unjustifiable message delay. The following faultload is provided to BFT-Bench to inject this misbehavior in the running replicated service: <300 s, message delay, replica x , (500 ms, 300 s)> Here, starting from time 300 s there is a message delay of 500 ms, and this misbehavior continues during 300 s (i.e., until the end of the experiment). Since the BFT protocols under evaluation use different architectures and communication patterns, message delays are introduced by BFT-Bench in different ways to these protocols, as explained in the following. For instance in case of PBFT, Aardvark, RBFT, and Zyzzyva, a delay is injected at the primary replica-side, when this replica receives a client request and sends the initial message to other replicas for processing that request (i.e., usually known as the pre-prepare phase in these protocols). In case of Chain, a message delay is injected before the head replica initiates the communication protocol with the other replicas. For Aliph which does not have a dedicated replica (i.e., no primary, no head), a chosen replica induces message delay. Figure 5 presents the results of these experiments. We can observe that the impact of this type of fault is different from one protocol to another. For instance, Figure 5(a) shows that message delay faults induce a latency increase of two orders of magnitude for PBFT, Zyzzyva, Aliph, Chain protocols, and a latency increase of one order of magnitude for Aardvark. Interestingly, due to its robustness to this type of fault, RBFT is able to smoothly tolerate this misbehavior without a perceptible impact on performance.

Evaluation in Presence of Network Flooding

In this case, ten clients concurrently access a replicated service, when the service starts misbehaving by inducing network flooding. The following faultload is provided to BFT-Bench to inject this misbehavior in the running replicated service: <300 s, network flooding, replica x , (4 KB, 300 s)> Thus, starting from time 300 s, replica x starts sending corrupted messages of size 4 KB to other replicas, during 300 s. Figure 6 presents the results of these experiments. Interestingly, Aardvark and RBFT are robust in case of such misbehavior. They are able to detect that a replica performs network flooding, and counter it by black-listing that replica [START_REF] Clement | Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults[END_REF][START_REF] Aublin | RBFT: Redundant Byzantine Fault Tolerance[END_REF]. In contrast, PBFT has bad performance in case of network flooding, since it is not able to tolerate this type of misbehavior. Aliph, which switches to PBFT when faults occur, demonstrates similar behavior as PBFT, although for clarity purposes its results after fault occurrence are not included in Figure 6.

More Complex Scenario

This use case illustrates a more complex scenario where a fault tolerant service faces a Byzantine fault, in addition to service contention. Here, the following Thus, the replicated service is first accessed by two concurrent clients. Then at time 200 s, the service starts misbehaving by inducing abnormal message delay of 500 ms, during 600 s (i.e., until the end of the experiment). In addition, the service load increases from 2 clients at the beginning of the experiment to 5 clients at time 400 s, and then to 10 clients at time 600 s. And as described in Section 4.1, client request and response message sizes are 4 KB.

Figure 7 presents the results of the experiment. We can observe that RBFT is able to transparently tolerate the Byzantine fault of type message delay when service contention is not too high. However, when 10 clients concurrently access the service, RBFT is no more able to handle contention and terminates. In case of Aardvark, the Byzantine fault tolerant service is able to face message delay fault, but at the expense of a performance overhead of one order of magnitude. Interestingly, Aardvark smoothly handles service contention increase without a perceptible impact on performance. This holds up to a given service load, where with 10 concurrent clients, Aardvark is no more able to handle contention, and terminates. Zyzzyva and Chain are able to face the Byzatine fault of type message delay. But they induces a high performance overhead of two orders of magnitude when such a fault occurs. In addition, when the service has a high contention (10 concurrent clients), Chain-based replicated service is three orders of magnitude slower, while Zyzzyva crashes. PBFT and Aliph (which switches to PBFT upon fault occurrence) have similar behavior after the occurrence of the fault at time 200 s, with a drop of latency of two orders of magnitude. After a while, PBFT and Aliph undergo a view change, i.e. they replace the faulty primary by a new primary. This has a direct impact on service performance which drastically improves.

Conclusion

Performance and dependability are important requirements of today's computing systems. Byzantine Fault Tolerance (BFT) is a general approach to make these systems, theoretically, tolerate arbitrary faults. BFT protocols were extensively investigated in the last years, and various prototypes were proposed. However, to the best of our knowledge, there is no practical solution to precisely identify the varying nature of Byzantine behaviors, no general tool for real-time injection of these misbehaviors in a system, and no reusable environment for the empirical evaluation of various BFT protocols. This paper presents BFT-Bench, the first framework for evaluating BFT implementations under different faulty behaviors and workloads. BFT-Bench framework includes several state-of-theart BFT protocols, automatically deploys them, injects different types of faults at different rates, and produces performance and dependability measures. The evaluation results show that BFT-Bench is able to successfully compare various BFT protocols, in various faulty behaviors. We wish to make BFT benchmarking easy to adopt by developers and end-users of BFT protocols. BFT-Bench framework aims to help researchers and practitioners to better analyze and evaluate the effectiveness and robustness of BFT systems. Although this paper concentrates on presenting the current version of BFT-Bench with some BFT protocols and their related fault types, we believe that the proposed approach can be easily extended to other BFT protocols, and other faulty behaviors.

Fig. 2 .

 2 Fig. 2. Examples of communication patterns of BFT protocols

  <[fault trigger time], message delay, replica x , ([injected message delay], [fault occurrence duration])> A faultload in BFT-Bench may also contain the following element to describe the injection of fault of type network flooding, specifying among others the size of the message used for flooding, and the duration of occurrence of this type of fault: <[fault trigger time], network flooding, replica x , ([flooding message size], [fault occurrence duration])> The overall architecture of BFT-Bench fault injection is presented in Figure 3.

Fig. 3 .

 3 Fig. 3. Architecture of Faultload Injection

Fig. 4 .

 4 Fig. 4. Performance evaluation in presence of replica crash

Fig. 5 .

 5 Fig. 5. Performance evaluation in presence of intentional message delay

Fig. 7 .

 7 Fig. 7. Performance evaluation -combination of message delay and system overload

  Performance evaluation in presence of network flooding. Results of Aliph after fault occurrence are not included; Aliph switches to PBFT when fault occurs and demonstrates similar behavior as PBFT.

			Fault-free scenario with 10 clients	PBFT Chain RBFT Aardvark Aliph Zyzzyva Continuous Network Flooding	Throughput (#requests/s)	1000 2000 3000 4000 5000	RBFT Aardvark Aliph Zyzzyva PBFT Chain	Fault-free scenario with 10 clients	Continuous Network Flooding
							0	100	200	300	400	500	600
				Time (s)				Time (s)
			(a) Latency				(b) Throughput
	Fig. 6. faultload is used by BFT-Bench:
	<200 s, message delay, (replica x , 500 ms, 600 s)>
	And in order to increase service contention, the following workload is provided
	to BFT-Bench:
	<0 s, 2, 4 KB, 4 KB, 100 µs, 400 s>
	<400 s, 5, 4 KB, 4 KB, 100 µs, 200 s>
	<600 s, 10, 4 KB, 4 KB, 100 µs, 200 s>
		1000	PBFT
			Chain
			RBFT
			Aardvark
	Latency (ms)	10 100	Aliph Zyzzyva	System Overloading with 5 clients	System Overloading with 10 clients
		1
			Fault-free scenario	Continuous Message Delay
			with 2 clients
		0.1
		0	100 200 300 400 500 600 700 800
				Time (s)

Acknowledgement

This work was supported by AMADEOS (Architecture for Multi-criticality Agile Dependable Evolutionary Open System-of-Systems), a collaborative project funded under the European Commission's FP7 (FP7-ICT-2013-610535). The

experiments were conducted on the Grid'5000 experimental testbed, developed under the INRIA ALADDIN development action with support from CNRS, RE-NATER and several Universities, as well as other funding bodies.


Laurence Lux-Sterritt

published or not. The documents may come

L'archive ouverte

Margaret Cavendish, Relation véridique de ma naissance, de mon éducation et de

  ma vie, traduction, annotations et postface de Constance Lacroix, préface de Line Cottegnies. Paris, Éditions Rue d'Ulm, « Versions françaises », 2014. 137 p. ISBN 978-2728805136. 14 € Laurence LUX-STERRITT Aix Marseille Univ, LERMA, Aix-en-Provence, France Avec la traduction de la Relation véridique de ma naissance, de mon éducation et de ma vie, Constance Lacroix révèle au public francophone l'autobiographie que Margaret Cavendish rédige à l'âge de 33 ans et où elle se remémore une enfance heureuse, évoquant tour à tour ses parents, Elizabeth et Thomas Lucas, ses soeurs et ses frères. Cette évocation d'un passé idéalisé jette un voile pudique sur les événements des guerres civiles qui ont pourtant durement affecté sa famille, dont l'arrestation se fait avec une violence extrême. Durant ces années de conflit, la vie de sa mère est menacée, la demeure familiale mise à sac, et le caveau profané à deux reprises. Pourtant, peut-être afin de ne pas ternir le souvenir d'une fratrie qu'elle honore, Cavendish ne s'attarde pas sur ces humiliations mais choisit de mettre l'accent sur des détails plus glorieux ; elle donne tout son soutien à l'aristocratie et à la cause des royalistes dans un texte qui, pour être publié en 1656, devait cependant respecter les précautions imposées par la censure du Parlement. Le titre de Relation est en fait peu représentatif d'un texte qui n'est guère narratif. Il s'agit plutôt ici d'évoquer et d'honorer la mémoire de ceux qui ont marqué la vie de Margaret Cavendish. Parmi eux, les figures les plus importantes sont sans nul doute celles de son époux, William Cavendish (marquis puis duc de Newcastle) et son beau-frère, Charles Cavendish. Ce sont là deux hommes qu'elle admire sans retenue, qu'elle revendique comme ses mentors, et dont elle fait un portrait quasi-hagiographique dans ce texte qui devient alors une sorte de memorial book, confiant à la postérité la carrière et les vertus des défunts. Pourtant, si elle fait l'éloge de la famille et des hommes en particulier, la Relation véridique est avant tout un document où le moi et l'ambition triomphent. Margaret Cavendish s'y présente tour à tour sous les traits d'une jeune fille de nature timide et peu à l'aise en société, puis en humble élève d'un illustre époux et d'un beau-frère qu'elle révère et qui éveillent en elle une vocation littéraire. Cette auto-représentation paraît bien surprenante de la part d'une femme qui publie en son nom, et plus encore quand on considère que ses mémoires s'inscrivent dans une littérature de l'égo dont l'époque se défie dès qu'elle dépasse le cadre de l'écrit religieux. Comme le montre Constance Lacroix, le personnage qui occupe véritablement le centre de la scène est bien celui de Margaret Cavendish, autour duquel tous les autres gravitent : c'est elle la « véritable héroïne, sujet et objet du discours » (88). Tandis que Blaise Pascal déclarait : « Le moi est haïssable », Margaret Cavendish au contraire se plait à explorer les traits de sa propre personnalité et revendique sans faux semblant une ambition dévorante. Celle qui aspire « à être le plus achevé et exact de tous les ouvrages de la Nature » de son vivant, déclare souhaiter ardemment perdurer après sa mort, pour atteindre « le pinacle de la Gloire, qui est de vivre dans le souvenir de la postérité.» (47) C'est là la raison d'être même de cet égodocument surprenant où les déclarations d'humilité et d'inaptitude qui siéent aux femmes de l'époque côtoient les moments où celle qui se qualifie d'auteure -dans un néologisme qui lui appartient-se place au même rang que César et Ovide, dont elle ne fait que suivre l'exemple en couchant sa vie par écrit (49). La Relation véridique est un récit bref (39 pages dans la présente édition) mais qui recèle de multiples défis pour la traductrice, puisque Margaret Cavendish est coutumière de longues phrases à la syntaxe complexe voire confuse. Constance Lacroix a donc entrepris un travail qui relève de la gageure, et dont elle s'acquitte parfaitement. L'appareil citrique de l'ouvrage se compose de 97 notes explicatives et d'une riche postface, d'une cinquantaine de pages, intitulée « 'Vivre dans le souvenir de la postérité'. Margaret Cavendish ou le refus de l'effacement ». Lacroix remet tout d'abord la Relation véridique dans le contexte plus général de l'oeuvre de Cavendish et revient sur la rédaction et la publication de Natures Pictures, avant de s'attarder plus particulièrement sur ce qu'elle nomme « le moi écrivant », puis sur le désir de gloire de l'auteure. Cette partie de l'ouvrage offre une fine analyse de l'autobiographie traduite, tant d'un point de vue linguistique que littéraire, et prend soin de ne pas oublier que même les textes les plus iconoclastes ou les plus singuliers sont issus d'un contexte qui les détermine. Pour comprendre la Relation véridique, il faut donc se pencher sur la question des femmes et sur le statut de l'écrivain au dix-septième siècle, mais aussi sur l'actualité agitée des guerres civiles et sur les tourments que traverse de l'aristocratie royaliste à laquelle Cavendish appartient. Cet ouvrage est le compagnon idéal de la traduction de The Blazing World, publiée pour la première fois en français en 1999 (Le Monde glorieux) par Line Cottenies, qui met ici son expertise au service d'ici une préface plaçant la duchesse de Newcastle dans son contexte social et littéraire. Elle y met en exergue les traits saillants d'une personnalité volontiers décrite comme excentrique, ambitieuse et parfois orgueilleuse, à la fois façonnée par les conventions de son siècle et peu encline à les respecter toutes, mue par une pulsion d'écriture qu'elle refuse de réprimer malgré l'opprobre de ceux qui la disent folle. La collaboration de nos collègues sur cet ouvrage montre tout ce que l'étude des textes de Cavendish a encore à offrir, et laisse espérer pour l'avenir d'autres traductions d'une oeuvre qui, malgré ses quatorze volumes, demeure encore aujourd'hui peu étudiée en France.