User Tools

Site Tools


bestpractice:experiences-experiment

Experiences from experiments

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

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.

Experiences and steps:

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).

Experiment Feasability

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:

  • the NAT in the research devices keeps track of ingoing packets belonging to non existing connections;
  • the second level of NAT (masquerading the island addressing) doesn't support the hairpin functionality.

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.

Experiments

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:

  • RTT between peers;
  • number of video chunks loss;
  • hop counts between peers;
  • neighborhood size.

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.

Anonymous communication with unobservability

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.

Experiments and steps:

Completed:

  • Familiarization with VCT and basic VCT Setup
  • Building customized Nodes in VCT
  • Automatized build of experiment data
  • Familiarization with Tinc and Confine Testbed Controller
  • Guifi proxy access and data collection
  • Benchmarking tools for system infrastructure
  • Blogging Extension for the Chrome/Chromium browser
  • Prototype of browsing behavior extension for the Chrome/Chromium browser
  • Local fountain code evaluation

Ongoing:

  • Continuous evaluation of proxy data
  • Browsing behavior extension for the Chrome/Chromium browser, small scale study
  • Monitoring and data collection tools for the Confine Testbed
  • Benchmark system and protocol in Confine Testbed

Experiments

Browsing Statistics

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:

  • page visits per user by hour
  • ad-related requests encountered per user by hour
  • total number of network users by hour
  • peak traffic generated by hour
  • estimated cover traffic generated by hour
  • system and browser specifications used to access the network

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.

Preliminary results:

  • page visits per user per hour: ~ 5.43
  • ad-related requests encountered per user by hour: ~ 24.24 - 30.6

Status: Ongoing, will update results regularly

Individual Browsing Statistics

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.

Status:

  • finished the first prototype for Chrome/Chromium
  • majority of evaluation tools

Ongoing:

  • small scale study
  • refinement of evaluation tools and the amount of data collected

Fountain Code Parameters

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.

System Infrastructure Benchmarking

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:

  • individual server performance wrt various deployment scenarios
  • packet loss (collision) rate wrt various deployment scenarios and simulated userbase

Status: Ongoing.

Community Access Study

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

Exploitation of information Centric network principles in wireLess cOmmunity NEtworks

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.

Experiment Feasibility

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.

Experiences and steps:

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.

Experiments

Web Service as a Service (WSaaS)

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.

Content Centric Multipath

We design and implement multipath strategies for the information-centric protocol CCN.

More details can be found on this page.

Wi-Fi network Infrastructure eXtension (WiFIX)

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.

Experiences and steps:

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.

Completed:

  • Familiarization with WiBed testbed through its documentation
  • Familiarization with the WiBed testbed tools;
  • Compilation and configuration of the WiBed related software
  • Creation of the image file to be installed in the mesh nodes
  • Preparatory steps at local nodes at INESC

Ongoing:

  • Unicast traffic and signalling overhead tests at the local WiBED testbed
  • Multihop communications and performance comparison between WiFIX, BATMAN-Adv and 11s
  • Evaluate the possibility to use one TP-LINK AP to emulate terminal mobility tests

More info about the WiFIX experiments and configurations can be found here.

Experiment Feasibility

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.

Confidentiality in the open CONFINE world

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.

Experiment Feasibility

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.

Experiences and steps

Completed:

  • Familiarization with virtual CONFINE testbed (VCT).
  • Familiarization with CONFINE testbed and Tinc.
  • Running Tor on VCT.

Ongoing:

  • Running Tor, JAP, SOR and Shalon on CONFINE.
  • Developing automated tests that would measure performance of all four systems on CONFINE. It will be measured in terms of:
    • RTT
    • Throughput
    • Jitter
    • Bandwidth
  • Evaluating results.
  • Development of penetrators that would simulate user behavior in order to compare the systems under realistic load conditions.
  • Comparison of usability of these systems from the end-user perspective.

Experiences:

  • Sliver images that are fully pre-configure are an interesting option that should be better supported, while the option of installing manually at runtime via SSH could be rather a backup solution.
  • In the initial configuration, the rootfs partition is too small for many testing setups.
  • There are occasional connectivity issues with the research devices.
  • The availability of VCT to make the first steps in the CONFINE world is helpful.
  • Some functionality on the CONFINE website could be improved for usability and less ambiguity, e.g. when it comes to setting up the certificates for the Tinc connection.

Based on our own experiences, we created a documentation containing:
(We are updating and expanding this documentation constantly)

Experiments

Tor

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...

Status: ongoing

Java Anon Proxy (JAP)

JAP is the second widely used anonymization network. It uses a set of dedicated mix servers for anonymization. Read more...

Status: onging

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...

Status: ongoing

Shalon

Shalon builds anonymization circuits using SSL and only requires a simple webserver on relays. Read more...

Status: onging

Clouds in Community Networks

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.

Experiences and steps:

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.

bestpractice/experiences-experiment.txt · Last modified: 2014/01/08 11:09 by till.hering