1 Introduction
Cloud computing has become a ubiquitous way of assuring an affordable infrastructure
for today’s new or developing companies. Even tough technology has matured in recent
years, there are still requirements that cannot be fulfilled by providers. This comes
either from economical or technological limitations. Academic research focused on these
issues and, by leveraging open-source software, aims to create architectures that can
interoperate with cloud providers and deliver more flexibility to the users.
One such initiative is Kangaroo, developed as a joint international project between
VU University Amsterdam, University of Florida and Universite de Rennes [1]. It was
developed as a solution to three issues currently present in the cloud providers services:
No fine granularity in selection of virtual machine (VM) types, limited or no control
over VM placement, lack of standardized API. The project proposes a tenant-centric
architecture on top of resources of different clouds by employing nested virtualization.
Kangaroo promotes vertical scaling: End-to-end network performance is much better
between co-located nested VMs and larger VMs are often more cost-efficient. The main
technologies used are Openstack [2] for managing the nested VMs, Skippy [1] for pro-
viding an abstract API for users regardless of the underlying cloud provider and IPOP
for end-to-end connectivity. Once resource limits are reached within a VM, nested VMs
have to communicate with their counterparts on different VMs. IPOP is used to manage
this connections by creating an overlay over the network that connects the underlying
VMs.
IPOP is an ongoing project that aims to provide a secure, cheap and simple to configure
end-to-end connection between users [3]. IPOP’s architecture, inspired by Software-
Defined Networking(SDN), allows for flexibility and straightforward implementation of
new extensions. Virtual links are created and managed by IPOP-tincan module. Links
are created between users that are identified as peers, using XMPP [4] as a peer discovery
protocol. In order to assure connections even when the users are behind a Network
Address Translation(NAT) device, STUN [5] and TURN[6] protocols are used.
Preliminary tests have been done in order to verify the project setup, using a 1 Gbps
link between two servers running IPOP. We noticed that there is a difference between
network throughput when two users are communicating directly (i.e. 950 Mbps) and
when they are using IPOP (i.e. 550 Mbps and 160 Mbps when security is enabled).
While we expect a small performance overhead due to a level of indirection (i.e., up
to 10%), this initial measurements show around 6x degradation in performance with
security, and 42% degradation in performance without security. Once the causes of this
performance penalty are identified, we can improve IPOP’s performance substantially.
If IPOP proves to be an architecture that can support a performance close to what
is available on direct links, then a larger user adoption can follow and more use cases
become feasible.
2
