providing umts connectivity to planetlab nodes

ROADS ’08 – Madrid 9th December 2008

FIRE - Future Internet Research & Experimentation

Providing UMTS connectivity to PlanetLab nodes

Alessio Botta, Roberto Canonico, Giovanni Di Stasi, Antonio Pescapè, Giorgio Ventre

Consorzio Interuniversitario Nazionale per l’Informatica CINI Università di Napoli “Federico II”

ROADS ’08 – Madrid 9th December 2008ROADS ’08 – Madrid 9th December 2008 2

Outline

� Context and motivations

� UMTS usage model

� Integration methodology

� Implementation details

� Proof of concept experiments

� Future of UMTS in PlanetLab Europe

� Conclusions


Context and motivations� ONELAB European research project

� www.onelab.eu

� Three objectives: federate, extend, deepen

� Two testbeds operated by ONELAB:

� PlanetLab Europe (PLE), federated with PLC

� Private OneLab, MyPLC testbed accessible to ONELAB partners and used to develop and test new features

� Extend: ONELAB new environments to address the lack of heterogeneity problem in PlanetLab

� Deepen: traffic monitoring and topology discovery tools


Good reasons for UMTS

� UMTS is a third generation (3G) cell phone tecnology

� UMTS as a 3G tecnology is designed to offer both speech and data (at higher rates)�

� Is capable to deliver new kind of services� Video call, streaming video, etc.

� Necessity to test new services in real world scenarios, where UMTS is an Internet access network


UMTS usage model

� An UMTS PPP connection can be established and torn down in a normal slice context

� Only one slice at a time can setup and use the UMTS connection

� Nodes always rely upon a primary Ethernet connection to the Internet used to ssh into the node

� Default route still assigned to the wired Ethernet interface

� A slice user can use the UMTS connection

� specifying the destinations for which the UMTS connection is required

� umts add www.google.com

� by explicitly setting UMTS ppp interface as the source IP address

� ping –I ppp0 onelab01.dis.unina.it


Integration methodology

� UMTS integration first developed in Private OneLab and then exported to PlanetLab Europe

� Supported UMTS PCMCIA cards: Option GlobeTrotter and Huawei e620

� Kernel level drivers integrated into the Linux kernel currently in use in Private OneLab

� Drivers get installed by adding the node to the UMTS nodegroup

� User level PPP daemon and auxiliary tools (gcom, pppd, umts-tools) included in the Private OneLab package repository

� Software packages automatically installed when node is added to the UMTS nodegroup

� Purpose of umts-tools: to enable control of the UMTS PPP connection within an unprivileged slice


Peculiarities of commercial UMTS connectivity

� The use of commercial connectivity was chosen because it is available at almost all PlanetLab Europe sites

� During the ONELAB project it was also used a private UMTS microcell made available by ALCATEL-LUCENT at their Vimercate premises (Italy)

� Peculiarities of commercial UMTS connectivity

� In the case of Vodafone, a public IPv4 address is assigned to the UMTS PPP interface but it allows only client-generated traffic

� Due to some sort of firewalling rules, traffic of protocol P from node X (port x) to UMTS node Y (port y) is only allowed after a packet of protocol P from Y (port y) has been sent to node X (port x)�

� Lessons learned: best practices to properly configure the experiments to circumvent these policies


Implementation details� To overcome the necessity of running the programs that need

root privileges, we have used a new feature recently included in PlanetLab: vsys

� vsys allows a program that runs in the slice context (the umts program in our case) to communicate with another program (backend) that runs in the root context

� vsys creates two named pipe in the slice context

� what the frontend writes in the first pipe is received by the backend program

� what the backend writes in the second pipe is received by the frontend program


Implementation details (2)�� Role of the backend:

� Starts and stops the connection and checks UMTS status using pppd

� Creates a new routing table to be used by the slice with only a default rule (using iproute2) – that's to work out the multihoming issue:

� ip route add default dev ppp0 table umts

� Adds a rule in order to use the routing table just created for each destination specified by the user in the frontend

� ip rule add to <dest_ip/dest_netmask> fwmark <slice_mark> table umts

� Only packets generated inside the slice and directed to one of the destinations specified by the user will get routed through the UMTS interface according to the forwarding rules included in table umts


� The backend program also adds a rule in order to have packets with source address equal to the UMTS interface address routed through the UMTS interface:

� ip rule add from <ip_ppp0> fwmark <slice_mark> table umts

� But how does the user set the source ip address? Ex: wget --bind-address <ip_ppp0> http://some/where/something

� It also adds a rule in the general routing table in order to avoid other slices to use the UMTS interface:

� Discard every packet not marked and using dev ppp0 as output interface

Implementation details (3)�


A proof-of-concept experiment

� Aimed at characterizing a commercial UMTS connection by using the tools we developed

� Two kinds of experiments

� performance of the UMTS up-link in non-saturated conditions (using low-bitrate, UDP, VoIP-like traffic)

� performance of the UMTS up-link in saturated conditions to evaluate the maximum throughput achievable in the uplink direction (1 Mbps UDP traffic)


Experiment setup

��

onelab04.inria.fronelab00.dis.unina.it

uninaprivate_umtsslice

� Traffic generation through the UMTS and the Ethernet interfaces

� Programs used: umts frontend and D-ITG

uninaprivate_nonumtsslice


Experiments setup (2)�� Environment: OneLab Private deployment

� Nodes:

� onelab00.dis.unina.it @ CINI

� onelab04.inria.fr @ INRIA

� Slice: uninaprivate_umts

� Tools: umts frontend, D-ITG, Gnuplot

� VoIP flow

� 73.6Kbps of CBR traffic on UDP

� 64 Bytes of payload + 12 bytes of RTP header

� 1 Mbps flow

� 122 pps with 1024 Bytes of UDP payload


VoIP-like flow measurements

Throughput Jitter

Packet loss Round trip delay


1 Mbps flow measurements

Throughput Jitter

Packet loss Round trip delay


Considerations on the experiments

� The bandwidth is allocated on-demand

� At the beginning, for a few seconds, less resources are allocated

� Acceptable performance for VoIP-like traffic

� The required throughput is achieved on average

� Jitter, after a first period, becomes low enough

� RTT lower than 200ms

� With the 1-Mbps flow the UMTS uplink is completely saturated and

all the performance parameters are heavily affected

� The maximum throughput is 400Kbps ca

� The jitter is between 20 and 40 ms

� The RTT reaches 3.5 s


Future of the UMTS component after OneLab

� Will it be part of PLE after the end of OneLab ?

� The software has been integrated into the OneLab repository, so if we find a PLE member wishing to pay for UMTS connectivity, there is a chance for UMTS to survive

� Expression of Interest in using the UMTS work done in OneLab by KAIST (Korea) in June

� Mobile Telecom European operators might be asked to offer limited UMTS connectivity for experimental purposes

� First contacts with Vodafone R&D

� UMTS connectivity might be paid by slice owners using it

� in a “PlanetLab Gold” future scenario


Conclusions

� A (partial) solution to the problem of heterogeneity in PlanetLab

� Two issues had to be solved� Definition of a proper usage model to a share special

resource without virtualization � Management of the UMTS connection from an

unprivileged slice� To make PlanetLab even more heterogeneous, more

challenges have to be faced� Integration via specialized gateways� Generalization of the testbed data model� Federation of different testbeds (e.g. PlanetLab and Orbit)

providing umts connectivity to planetlab nodes

Documents