Network-aware Service Placement in Community Network Clouds Mennan - - PowerPoint PPT Presentation

Network-aware Service Placement in Community Network Clouds

Mennan Selimi mselimi@ac.upc.edu

EMJD-DC Summer Event 2nd of June, 2016 Advisors: Prof. Felix Freitag (UPC), Prof. Luis Veíga (IST/INESC-ID)

Activity

Growth of Guifi.net in terms of operational nodes Evolution of the total inbound and outbound Guifi.net traffic over the last 2 years

• started in 2004
• open, free and neutral community network
• non-profit
• non partisan
• without conflict of interest
• growing exponentially at triple digit every year
• more than 30K nodes (31090 nodes, May 2016)
• 50.000 + km of links

Network

• Guifi.net foundation:

Scaling

• extremely dynamic and diverse
• internet for everyone !

Goal

• The vision of cloud-based services in community networks
• We are talking about specific community cloud:
• providing services of local interest
• a P2P cloud made of individual computers and 


home gateways

• hosted in community-owned computing resources
• built in community networks

Community Network Clouds

• no single entity that owns or controls
• to join / leave no need for permission or consent
• small components, energy-efficient, well distributed
• can’t provide the QoS of Google, Amazon

Pros Cons

• low-power devices, unreliable network

Web interface Console

Service Layer

Streaming Storage Network

PeerStreamer GVoD VoIP

Serf Avahi

Tahoe-LAFS Syncthing WebDAV Proxy3 SNP Service DNS Service

Network Coordination

Service Discovery Service Announcement

Community Network

API BASP

User

CLOUDY

CLOUDY

http://cloudy.community/

Cloudy: Community networking cloud in a box

• Debian GNU/Linux distribution aimed to foster 


the transition and adoption of the 
 Community Network cloud environment

• can be installed in VMs or “bare metal”
• service discovery platform
• free, open source software (FOSS)
• user-friendliness and experience
• decentralization

CLOUDY

M.Selimi et al., Cloud Services in Guifi.net. Computer Networks (2015)

0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 10 - 3 10 - 2 10 - 1 10 0 10 1 10 2 10 3 Link traffic in the busy hour [kbps] (log10 scale) ECDF

GSgV-nsl-b828/GSgranVia255nl-c493 GSgranVia255-db37/GScallao3Rd1-9090 UPCc6-ab/UPC-ETSEIB-NS-7094 0.5 1.0 1.5 0.4 0.8 1.2 1.6 0.25 0.50 0.75 1.00 1.25 2 4 6 8 10 12 14 16 18 20 22 24 Hour of the day Link traffic [Mbps]

0.0 0.5 1.0 1.5 1 2 3 4 x (km) y (km) UPCc6-ab GSmVictoria-RK71 UPC

0.0 0.2 0.4 0.6 0.8 1.0 1 10 100 Link throughput [Mbps] (log10 scale) ECDF

GSgV-nsl-b828/GSgranVia255nl-c493 GSgranVia255-db37/GScallao3Rd1-9090 UPCc6-ab/UPC-ETSEIB-NS-7094 22.5 25.0 27.5 10 15 20 25 18 20 22 24 2 4 6 8 10 12 14 16 18 20 22 24 Hour of the day Link throughput [Mbps]

Number of nodes (90) Bidirectional links (291/663) Unidirectinal links (372/663) 25 50 75 100 25 50 75 100 25 50 75 100 25 50 75 100 200 300 100 200 300 Index Presence (%)

Monitoring page: http://dsg.ac.upc.edu/qmpsu/index.php

QMP Topology Node and Link presence Link traffic in the busy hour ECDF Traffic in three busiest links Throughput ECDF Throughput in three busiest links Measurements taken: October 2015 - March 2016

Topology

• growth is unplanned
• nodes often at non-optimal locations
• high diversity in the quality of links
• unreachable nodes due to electric cuts
• re-tuning radios by members
• well connected and adaptive

0.0 0.5 1.0 1.5 1 2 3 4 x (km) y (km) UPCc6-ab GSmVictoria-RK71 UPC

QMP Topology

• mesh topology

• highly skewed traffic pattern
• average traffic observed 70 kbps
• busy hours between 22h-23h, 1.2Mbps

Usage

0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 10 - 3 10 - 2 10 - 1 10 0 10 1 10 2 10 3 Link traffic in the busy hour [kbps] (log10 scale) ECDF

GSgV-nsl-b828/GSgranVia255nl-c493 GSgranVia255-db37/GScallao3Rd1-9090 UPCc6-ab/UPC-ETSEIB-NS-7094 0.5 1.0 1.5 0.4 0.8 1.2 1.6 0.25 0.50 0.75 1.00 1.25 2 4 6 8 10 12 14 16 18 20 22 24 Hour of the day Link traffic [Mbps]

Link traffic in the busy hour ECDF Traffic in three busiest links

Network performance

• average throughput observed 21.8 Mbps
• throughput slightly affected by the traffic
• highly skewed throughput distribution
• link asymmetry: 25% of links have 


deviation higher than 30%

0.0 0.2 0.4 0.6 0.8 1.0 1 10 100 Link throughput [Mbps] (log10 scale) ECDF

GSgV-nsl-b828/GSgranVia255nl-c493 GSgranVia255-db37/GScallao3Rd1-9090 UPCc6-ab/UPC-ETSEIB-NS-7094 22.5 25.0 27.5 10 15 20 25 18 20 22 24 2 4 6 8 10 12 14 16 18 20 22 24 Hour of the day Link throughput [Mbps]

Throughput ECDF Throughput in three busiest links

Services in the network

Proxy server (Internet access) 53.50% Web pages 11.08% VoIP / audio / video / chat / IM 9.33% Data storage server 7.97% Radio / TV stations 3.50% P2P server 3.50% Linux mirrors 2.91% Webcam 2.33% Tunnel-based Internet access 1.94% Mail server 1.16% Weather station 1.16% Games server 0.97% CVS repository 0.38% Server virtualisation (VPS) 0.38%

Bandwidth-hungry services

In total 950 different 
 services

Network graph server 32.94% DNS Server 35.48% NTP Server 17.20% Logs Server 6.45% Bandwidth measurement 0.71% LDAP server 0.53% Wake on LAN 0.35%

Network-focused services User-focused services

Topology

• growth is unplanned
• nodes often at non-optimal locations
• high diversity in the quality of links
• unreachable nodes due to electric cuts
• re-tuning radios by members
• well connected and adaptive
• highly skewed traffic pattern
• average traffic observed 70 kbps
• busy hours between 22h-23h, 1.2Mbps

Usage Network performance

• average throughput observed 21.8 Mbps
• throughput slightly affected by the traffic
• highly skewed bandwidth distribution
• link asymmetry: 25% of links have 


deviation higher than 30%

Proxy server (Internet access) 53.50% Web pages 11.08% VoIP / audio / video / chat / IM 9.33% Data storage server 7.97% Radio / TV stations 3.50% P2P server 3.50% Linux mirrors 2.91% Webcam 2.33% Tunnel-based Internet access 1.94% Mail server 1.16% Weather station 1.16% Games server 0.97% CVS repository 0.38% Server virtualisation (VPS) 0.38%

Bandwidth-hungry services in QMP

In total 950 different 
 services

Given a community network cloud infrastructure, what is an effective and low-complexity service placement solution that maximizes end-to-end performance (e.g., bandwidth) ?

Bandwidth-aware Service Placement (BASP)

S2 S1 S3

• Phase 1: use k-means algorithm to cluster nodes based
• n their geo-location
• Phase 2: find the node with maximal bandwidth

within the cluster - the cluster head

• Phase 3: reassign the nodes to the selected cluster heads

fij - bandwidth of the path, from node i to j partition k of clusters: S = S1, S2, S3 … Sk

Bandwidth-aware Service Placement (BASP)

• low complexity service placement heuristic
• BASP consistently outperforms the currently service 


placement in guifi.net by 35% bandwidth gain

• as the number of services increases, the gain

tends to increase accordingly

Video-streaming Service in Cloudy

• PeerStreamer: mesh-based, video streaming platform, based on chunk swarming
• The source “seeds” the overlay with N copies of each chunk
• Highly dynamic: topology is constantly updated
• Immune to churn problems
• 30 real community network nodes


distributed in the city of Barcelona

• Intel Jetway and Minix NEO Z64


devices running Cloudy

• Camera attached to the source node


(512 kbps bitrate, 30 frame-per-second)

• 2 hours of live video-streaming

Source node running in a Docker container

Video-streaming Service in Cloudy

• video chunk loss decreased up to 3 pp (percentage point) in

the peers side

Distributed Storage Service in Cloudy

• Tahoe-LAFS: open source, secure distributed storage
• Introducer, storage and client nodes
• 30 real community network nodes


distributed in the city of Barcelona

• Intel Jetway and Minix NEO Z64


devices running Cloudy Different workloads: 2 - 64 MB

• client reading times 16% improvement

Introducer

Storage

Client Client Client

Storage Storage Storage

Storage node running in a Docker container

• Provider-independent security

References

Towards Network-Aware Service Placement in Community Network Micro-Clouds

M.Selimi, D.Vega, F. Freitag, L.Veiga. In Proceedings of the 22nd International European Conference on Parallel and Distributed Computing (EuroPar 2016)

Cloud Services in Guifi.net Community Network

M.Selimi, A. Khan, E. Dimos, F. Freitag, R. Pueyes. Computer Networks, 93(2), 2015

Bandwidth-aware Service Placement in Community Network Micro-Clouds

• M. Selimi, Ll. Cerdà, L. Wang, A. Sathiaseelan, L. Veiga, F. Freitag. IEEE Conference on Local

Computer Networks (LCN 2016) (in submission)

Barcelona Topology Graph Guifi.net Lluçanes Topology Graph, guifi.net

Network resilience

Ratio of nodes in Barcelona that do not have web access (no DNS or Proxy access) when top-ranked nodes are removed.

Ongoing work - Service Resilience

Web access :

• DNS server
• Proxy (gateway)

Robustness of the web access service:

• node failures

In collaboration with: Arjuna Sathiaseelan (University of Cambridge) and Davide Vega (University of Bologna)

Conclusion

• Cloud infrastructures are deployed in a real production wireless community network
• A easy to use community distribution might help for massive uptake and provision of

stable key services

• Dynamic and diverse environment for service functioning
• Network-aware Service Placement is a must for QoS !
• traffic
• Future work: service migration
• service overlay diameter (e.g., between 2-3 hops)
• Bandwidth-aware service placement: improves service performance, needs to be

augmented with other metrics

Thank you !

http://cloudy.community/

Mennan Selimi

mselimi@ac.upc.edu

A community networking Cloud in a box

CLOUDY

Demo http://84.88.85.42/ user/pass: guest/guest

http://people.ac.upc.edu/mselimi

Stirling number

• f the second kind

Phase1: K-Means, if k and 
 d are fixed e.g., k=3, d=2 Phase 2: computing cluster 
 heads Phase 3: re-assign nodes

BASP

BASP Complexity