Services‎ > ‎Usage scenarios‎ > ‎

Emulated network


Cloud with emulated network implications

Objective and motivation

This scenario focuses on the controlled network interconnection of individual services and resources, providing researchers with a tool for testing service architectures and deployments, taking network implications into account through a fully controlled emulated core network on a single testbed. This will provide researchers with the ability to validate their service experiments in terms of network bandwidth usage, network delays, service response times etc.


Extended experimental facility: emulated core network

Figure 1: Extended experimental facility: emulated core network

Background

Full control over the core network is ensured through the Virtual Wall emulation environment and its Emulab management software. The Virtual Wall consists of 100 high-end servers, interconnected by a non-blocking Ethernet switch. The Emulab software allows for repeatable, dedicated and confined experiments and is responsible for swapping in required operating system images, dynamically interconnecting the (virtual) nodes through VLANs on a network topology with emulated network links (with proper capacity, delay and packet loss characteristics).

The Virtual Wall also provides the necessary network monitoring tools to examine network traffic and consumption of memory, CPU, disk load and energy on the different nodes. In addition to the network layer functionality, services can be deployed on the Virtual Wall nodes controlled by the researchers through VM images. These instances can also be monitored (bandwidth, CPU and memory consumption, response times and availability over time) and can be invoked through service request generators. These request generators can be tuned in a variety of different parameters (e.g. spatial request distribution, temporal request distribution, popularity of service instances) and assign the client locations through automated generation of scripts. The same principles as described in the first scenario are applicable, including the service agnostic properties of the BonFIRE testbed to researchers and the requirements for BonFIRE sites. In order to conduct experiments on the BonFIRE testbed, similar steps must be taken as in the  previous scenario. During the service definition step, specific network constraints can be formulated to be enforced in the emulated network.

Enabling software technologies

The Virtual Wall has several components that allow monitoring network and application performance as described below. These provide results for the experiments, and information which can be use for maintenance and smooth operation of the testbed. Each of these components will be upgraded with additional functionality according to the needs and requirements of the BonFIRE experiments. Monitoring of hardware performance. To monitor the hardware performance of a server, a distributed monitoring architecture exists on the Virtual Wall. This monitoring architecture consists of several small monitoring probes that measure power consumption, memory usage, etc. and transmit it to a central server. Each monitoring probe contains a transactional database, to store the measured data in a cyclic manner, and a web interface, to provide visual information (e.g. through real-time graphs). The metrics that can be measured through the architecture are memory usage, CPU usage, transfer rate on the hard drive in terms of read and write operations, incoming and outgoing bit rate on a network interface, actual voltage, total power consumption and environmental temperature (e.g. temperature close to the device).

Monitoring of network performance

Two distinct types of network monitoring probes exist on the Virtual Wall. A Click Modular Router (http://read.cs.ucla.edu/click/) based monitoring probe, and a libpcap (http://www.tcpdump.org/) based monitoring probe. The first one can be used when integration with Click is advisable (e.g. when existing sessions need to be altered through shaping and policing). The latter is emulab Architecture Programmable “Patch Panel” optimized for application specific monitoring situations (e.g. the monitoring of video quality). Both monitoring probes monitor typical QoS parameters such as packet loss ratio, delay and jitter in real-time. Furthermore, the Click based monitoring probes contain different bandwidth measurement algorithms to monitor the used resources. Depending on the envisaged use case, monitoring can occur on session, subscriber and node level. Besides monitoring the actual network performance, the Click based monitoring probe can estimate packet loss, delay and jitter by monitoring intermediaries in the network. This estimation can be interesting if user-experienced network performance must be measured in a network environment where the operator has no control on the end devices (e.g. a laptop in the home network). The accuracy of the estimate is between 95% and 100%.

Monitoring of service performance

A third type of monitoring component allows for monitoring general or service specific characteristics. Generic service layer tools include on one hand service request generators (with configurable parameters such as spatial request distribution, temporal request distribution, popularity of service instances) that assign the client locations through automated generation of scripts. On the other hand, service monitoring software (response times, bandwidth/CPU/RAM consumption over time, availability over time, etc) is available as well. Generic service proxy functionality for shielding remote service instances or for modifying service behaviour (introducing delay, limiting the number of threads, etc) can be used as well. Specifically for video delivery services a similar component is available as for network monitoring. It consists of a libpcap based monitoring probe that monitors and stores information about the video quality of individual sessions locally.

Future improvements

In the later stages of the project, the Virtual Wall controlled emulation environment is opened up to interconnect BonFIRE sites besides individual resources and service components. In order to ensure control over the access links to the Virtual Wall, dedicated layer two tunnels are used to interconnect the external BonFIRE sites to the iLab (through GEANT).