This page is under on-going edition and describes experiences and ways that were followed to run experiments of different projects using the Community-Lab facility. More details to some of the described experiments and contact persons can be found in Experiments selected (1st open call).
|Open Source P2P Streaming for Community Networks|
|Anonymous communication with unobservability|
|Wi-Fi network Infrastructure eXtension (WiFIX)|
|Exploitation of information Centric network principles in wireLess cOmmunity NEtworks|
|Confidentiality in the open CONFINE world|
|Clouds in Community Networks|
The goal of the experiment is demonstrating that Community Networks can support advanced multimedia services such as real-time video and TV distribution.
The study of efficient video streaming techniques will be done through the Open Source P2P streaming software PeerStreamer.
The project will produce a stable version of the application tailored for Community. The experiments will give useful indications on design and dimensioning of the networks as well as on the best practices to implement streaming services with various delay constraints on top of Community Networks.
Installation of VCT and experiments on a dedicated machine to run experiments before deployment on the community-lab;
Preparation for experiments with real slivers in Community-Lab.
Experiments on functional tests using the IPv6 version of PeerStreamer either among the Community-Lab's slivers or with UniTN peers connected through tinc.
A new PeerStremer source has been setup in UniTN to increase the video streaming offer in the Community-Lab when possible. The source will be moved within the Community-Lab upon the availability of resources.
Investigation of IPv4 network connectivity limits in the Community-Lab related to both single and multiple NAT levels. Issues with nested NATs have been identified. P2P communications are sensitive to NAT punching limitations.
Assessing communications among slivers on different islands and between slivers and UniTN external peers (not connected through tinc).
Currently not all experiments are feasible due to the particular Confine network configuration. These difficulties are related to the specific IPv4 NAT behaviour in the tesbed which prevents proper P2P communications:
To fix the first issue a patch to the RDs image has been discussed in the mailing list and added in the testing branch of the Confine project.
The second issue seems harder to solve since it depends on the specific device capabilities.
Currently we have two version of PeerStreamer, using different strategies to deliver contents. We performed the tests using both of them in order to verify the resulting overlay and the reception accuracy of the video chunks among the involved peered slivers.
Taking in mind the architecture of the Confine testbed we developed new modules in order to make tests even with the IPv6 infrastructure.
So we basically have two main branch of experiments:
Tests have been performed tracing the following parameters:
In order to evaluate different strategies for delivering the contents, tests has been also performed mixing resources belonging to the Confine testbed with others belonging to our laboratory in the University of Trento. For each test, an instance of PeerStreamer was running on the slivers of our Confine slice, logging the data related to the communication in a local file for further analysis.
Further information are available in our OSPS wiki.
In this project we propose to study the practical applicability of an online advertising network called AdLeaks through the CONFINE testbed. AdLeaks leverages the ubiquity of unsolicited online advertising to provide complete sender unobservability when submitting disclosures. AdLeaks ads compute a random function in a browser and submit the outcome to the AdLeaks infrastructure. Such a whistleblower’s browser replaces the output with encrypted information so that the transmission is indistinguishable from that of a regular browser. Its back-end design assures that AdLeaks must process only a fraction of the resulting traffic in order to receive disclosures with high probability. We have implemented the AdLeaks system design and we have evaluated it through mathematical analysis and micro-benchmarks.
The main objective of this experiment is to observe, gather and evaluate statistical data regarding browsing behavior of testbed users and their user-agents. In cooperation with our Guifi partners multiple proxies were setup to record browsing behavior. These proxies recorded access logs that will help us determine:
Since the proxy setup does not record active users, we were forced to cross-reference Measuring Web Page Revisitation in Tabbed Browsing and Google Web Metrics to extrapolate the number of people using the proxy.
Status: Ongoing, will update results regularly
The data collected by the Guifi proxies (input to the “Browsing Statistics” experiment) is fine grained enough for the statistics calculated there. The data is however not fine grained enough for the simulation of individual users (as whistleblowers). This however is crucial to determine how collisions occur (See “Fountain Code Parameters” and “System Infrastructure Benchmarking”).
For this reason we need to evaluate individual browsing behavior of users. To achieve this we develop a browser extension that monitors the browser sessions of users, which will be integrated with the blogging extension from the community access study. To prevent users from feeling spied on, the extension should collect the minimal amount of data that is necessary, should aggregate the individual results as far as possible and should display the collected and submitted data to the users in a meaningful form.
In the first stage we implement a first prototype that captures as much as possible and run a small scale study within our working group. From the results we want to learn which data is absolutely necessary for our purpose. Using these results we will integrate the prototype in the blogging extension and start the large scale study with CONFINE users.
The goal of this experiment is to verify the parameter choices resulting from the local fountain code evaluation in the network. The local evaluation utilized random packet loss, while the packet loss characteristics on the network is still to be determined in the System Infrastructure Benchmark (see below).
Status: Ongoing. Local evaluation completed.
In this experiment we plan to benchmark our system under different deployment scenarios utilizing wired and wireless connectivity for decryptors.
We want to learn two characteristics of our system:
We will open a deployment of our anonymous blogging infrastructure and browser extension to the community of testbed participants and advertise its use, determine opt-in or opt-out in compliance with CONFINE policies, monitor the systems performance and stability and perform maintenance tasks while collecting statistics on the system's use. In particular, we plan to collect information regarding client side resources available for cryptographic computation.
Status: Ongoing, extension and servers for blogging ready for deployment
Our experiments seek to exploit the instruments of an Information Centric Network (ICN), namely in-network caching and routing-by-name, to shorten the multi-hop path through a dynamic replication of information and services, on community devices. Following an evolutionary approach, ICN functionality is deployed over IP, without compromising the operating regime of IP-based community services.
We prototype a community web hosting service, named WSaaS, that uses storage and computation resources of community user’s hosts, to dynamically replicate Web pages of community users.
We use Community-Lab facility to carry out comparative experimentations, ICN vs. IP, showing performance improvements obtained both for basic point-to-point data transfer and within the community web hosting use-case.
This experiments and CCN-related ones are actually feasible in Community-Lab and experimentation is ongoing. The experiments are running on a set of ~20 nodes with community-public addresses in real World community traffic conditions.
Familiarization and usage of the Virtual CONFINE Testbed
The VCT tool helped to assess the possibility of deploying ICN tool.
Creation of slivers in the Community-Lab testbed.
Source code: https://redmine.confine-project.eu/projects/clone
The aim is to implement a distributed Web Server based on CCNx.
The scenario is a Wireless Community Network (WCN) using OLSR as the routing protocol, and specifically, the olsrd implementation.
The nodes run the CCNx ccnd daemon, which provides support for Content-Centric networking and caching, and the OLSR olsrd daemon. The routing-by-name is supported by the CCNinfo olsrd plug-in, developed by us (CNIT), which allows for the diffusion of arbitrary names inside an OLSR network, coupled with a routing by name agent responsible of updating the FIB of the ccnd.
Provided in this way content-centric networking support, to implement the WSaaS we make use of a standard HTTP browser. We setup the browser to use a modified version of the HttpProxy component (included in the ccnx distribution), which translates HTTP GET requests into CCN Interests. These may be satisfied locally by cached ContentObjects or forwarded, using the Content-Centric network facilities, to other ccnd instances or to CCN repositories. If multiple synchronized repositories are present in the network, the content-centric routing will provide the nearest, achieving Content Delivery Network-like behavior.
The repository bootstrapper converts Web resources stored on the filesystem to ContentObjects transferred to a CCN repository (ccnr) instance, computing HTTP headers (e.g. mime type) and using a coherent naming scheme.
More details can be found on this page.
We design and implement multipath strategies for the information-centric protocol CCN.
More details can be found on this page.
INESC TEC has defined a solution for WMN, named Wi-Fi network Infrastructure eXtension (WiFIX), that considers (1) unicast, multicast, and broadcast routing, (2) channel assignment, and (3) multi-hop medium access control aspects, in order to support existing and new applications on top. WiFIX overcomes the disadvantages of existing WMN solutions, namely by: I) reducing routing signalling overhead; ii) considering a new approach for multicast/broadcast traffic diffusion that takes advantage of Wi-Fi built- in unicast data rate control and delivery guarantee; iii) defining a topology-aware channel assignment algorithm that increases WMN performance and scalability; iv) considering a multi-hop scheduling mechanism overlaid on the 802.11 MAC, which enables efficient and fair WMN multi-hop medium access;
Experiments in Community-Lab aim to complement our evaluations of WiFIX with real-world, large-scale WMN experiments.
With the Confine consortium, the option of the WiBed testbed was found in order to enable in an easier way part of our requirements for our experiments.
More info about the WiFIX experiments and configurations can be found here.
The WiFIX experiments are not feasible over the existing Community-Lab, namely because there are no enough nodes available in the current Community Networks to form a large-scale wireless mesh network. In order to overcome this limitation, for time being we are using WiBed, an indoor WMN testbed at UPC that will have up to 50 mesh nodes.
Our experiments look at data protection and confidentiality issues by evaluating and analyzing to which extent existing privacy-preserving routing techniques applied on the Internet can be transferred and tailored to the needs of community-based networks.
To this end we want to test which of the available privacy-preserving routing techniques can be efficiently deployed in the community-based networks. We put our focus on lightweight methods developed by ourselves (SOR and Shalon) that are specially designed for environments with limited resources, lack of a central point of trust, and that are able to deal with a high churn rate. We compare those systems with the established Tor and JAP anonymization systems.
The described experiments are feasible in Community-Lab and experimentation is ongoing. The present number of stable nodes, however, prevents us from getting representative results.
It would further be welcome to have a simple option to run commands on a number of slivers in parallel (similar to pShell in PlanetLab) and to have larger root file systems on slivers, as required to install software like Java.
Based on our own experiences, we created a documentation containing:
(We are updating and expanding this documentation constantly)
Tor is the most widely used anonymization network on the internet. It is based on a set of central Directory Authority servers and a large number of relays run by users. We use it as the main reference to evaluate our own systems. Unlike its normal configuration, we run a private Tor network, isolated from the global network, i.e. only for the users within the community network. Read more...
Java Anon Proxy (JAP)
JAP is the second widely used anonymization network. It uses a set of dedicated mix servers for anonymization. Read more...
SSH-based Onion Routing (SOR)
Unlike Tor or JAP, SOR does not require any special software running on relays. Instead, it uses existing SSH software to build anonymization circuits. Read more...
Shalon builds anonymization circuits using SSL and only requires a simple webserver on relays. Read more...
This project aims to provide community services organised as community clouds. Experimentally-driven research, using the Community-Lab testbed will be used for the evaluation of the community cloud.
Remote researchers have access to the Guifi community network.
Confine controller creates slices of VMs. These slices can contain VMs on geographically distant cloud resources.
VM templates could be customized for our purposes and can be deployed through the Confine-controller to our VMs.
Additional hardware for cloud resources could be added to the Guifi community network through the Community-Lab infrastructure.
Due to the open source policy of the CONFINE project which facilitates easy access to all source code, the potential for federation of Confine-controller with Cloud management platforms can be explored.