IMPLEMENTATION & PERFORMANCE AND ANALYSIS OF REAL AND SIMULATED NETWORKS
CSC579 :Â OVERLAY ANDÂ PEER TO PEER NETWORKINGÂ COURSEÂ PROJECT
Learn More
"The inspiration behind this project was to bring many real world components and virtual components to communicate with each other. This sounded very interesting an innovative. We were keen about implementing a network that had both rea; communicating systems and virtual communicating systems. Nothing excites engineers more than trying out scenarios that have never been attempted before. It was not an easy task. We encountered a lot of roadblocks and had to change many things on the way. Failure are like error messages that tells you, to make changes in your program so that the computer can run. Like that we also made many changes from what we had initially planned to have practical deliverables for our course project. "
-Amit, Anju & Jian
IMPACT ON PERFORMANCE & SECURITY OF OFFLINE COMMUNICATION USING P2P NETWORK AND PARAVIRTUALIZATION
Project Proposal (intial idea and Title)
Hi all, on 31st January 2020 we submitted our proposal for this project.
The whole idea is that
with industries pacing towards paravirtualization, we decided to pair this concept with peer to peer
networking for our course project.We are going to extend ad-hoc networking concept into the paravirtual
network of containerized hosts through docker and implement an offline communication (voting
scenario) with real hosts (4 or 5 mobiles) and some containerized application/machines.Ad-hoc peer to peer networking and paravirtualization are two
independent and wide concepts and so we would like to call our approach a ‘hybrid approach’.
Please check out our proposal from the button below
WEEKLY UPDATES
We will take you through the entire journey. From the conceptualization to the realization of our project. We will tell you what we learned, what were the biggest hurdles,where we went wrong. We will update our work on a bi-weekly basis.
WEEK - 1 & 2
Week one was spent in setting up the test environment. This can be broken down into two parts.
On one side we are building a virtual environment using docker on an Ubuntu machine. Docker helps you create as many containers as you want in very less time. Once the ubuntu machine was setup then the docker can be installed using command line and then docker for Ubuntu is pulled from the Docker hub repository.
​
On the other side we are configuring the 'real' part of the test environment. We are using the Bridgify app to test the 'offline voter' scenario. This is just a simple scenario where you can communicate your 'yes' or 'no' answer to a question with others without the use of real internet. Once this scenario works perfectly, we could easily expand it other scenarios. So, in order to use its SDK, we need to have the SDK key, which we already obtained and then cloned the sample code into a local environment using this key.
​
Apart from this we are also researching on some interesting works related to this project and at the same time learning more about the docker technology
​
WEEK - 3 & 4
We divided the entire project setup into the real and virtual setup , as our main intention was to set up a Peek -to-peek network where both real & paravirtual components hosted by docker can co-exist and communicate and we wanted to analyse the performance and security risks associated with such a network.
So, our progress on the real side is that, we have designed and implemented a test app with the BridgeFy app’s SDK. The test app can propagate a message throughout the P2P network with a specified volume of Peers. A web -based data centre is able to trace the progress of the message.
On the virtual end, we have implemented docker containers and are now trying to combine an android emulator onto the docker container.
ROAD BLOCKS
We encountered a main roadblock when we tried to connect the real set up and virtual setup to make the whole network. We are not yet able to connect the virtual and real parts of out networks together.
Though we referred to some publications that claim that it is possible, we realized that it will take more knowledge, time and effort to realize it than we anticipated. All these scenarios that we referred were speaking about the theoretical aspect and not a practical implementation. So, due to time constraints and to have practical deliverables for our project. We decided to alter the objectives of our project a little bit.
THE BACKUP PLAN
What are the alterations we want to make ?-
Instead of making a network that has both real and virtual parts, we decided to have 2 stand alone networks with a real P2P network made with the help of BridgeFy app on mobiles on one side and a virtual network with docker containers on another side.
So, with these 2 standalone networks we are going to simulate the same scenario of broadcast messaging and then compare and analyse the performance of both.
To have a benchmark to compare these to scenarios with. We have decided to design and implement the same scenario with NS-3 which will give a theoretical output , of what the parameter values are supposed to be eg:, for coverage, delay, etc.
So, we would like to change the name of our project to ‘Implementation & performance analysis of Real and Simulated Networks’
WEEK 5 & 6
Week 5 was be spent in checking the feasibility of the new deliverable. We decide to go forward with the idea of implementing the network using NS3 as well as in the real scenario using the new app we designed and implement in real and at last do a contrast and comparison of the 2 different scenarios.
Understanding what is doable and what is not was the main hindrance so far.
​
We decide to use NS3, which is industrially acknowledged to go forward with our theoretical implementation.
By the end of week 6, we had designed and implemented a test app using the Bridgefy SDK, This test app can propagate messages throughout the P2P network with a specified volume of peers.
​
And then on the practical side, the next step was to host a corresponding web-based data center which is able to trace the progress of a message as the message propagates through the network.
​
​
​
​
LET'S GET INTO THE TECHNICAL DETAILS
The NS-3 implementation is Scenario A
The real-world implementation is Scenario B
Though logically speaking, we were supposed to implement the NS-3 simulation first, and then go on to implement the network in the real scenario with the learnings from the simulation. But, as this is a time bound project with deliverables that needed to be set, work on both ends were done rather simultaneously.
WEEK 7 & 8Â
SCENARIO A : NS3 SIMULATION
The program parameters set
​
• Library functions are included
•No: of nodes are defined
•Time duration for simulation -> 15 mins
•Max number of nodes less than  < 250
•Wi-Fi access point nodes and sensor nodes
•Mobility models – Random mobility model and constant mobility model
•CMM used by the Wi-fi access point nodes
•RMM used by the sensor nodes.
FINAL WEEK
SCENARIO A : NS3 SIMULATION DEMO
The program parameters set
​
• Library functions are included
•No: of nodes are defined
•Time duration for simulation -> 15 mins
•Max number of nodes less than  < 250
•Wi-Fi access point nodes and sensor nodes
•Mobility models – Random mobility model and constant mobility model
•CMM used by the Wi-fi access point nodes
•RMM used by the sensor nodes.
FINAL WEEK
SCENARIO A : NS3 SIMULATION RESULTS
Once the program, to send ICMP ping packets to all the sensor nodes in the network via peer to peer network , was successfully implemented for 10 nodes, then we increased the number of nodes to 20, 50 and then 100 nodes and here are our results.
FINAL WEEK
SCENARIO A : ANALYSIS OF NS3 SIMULATION RESULTS
We can observe that as the Data rate increases, the average Round Trip Time decreases.
*Note that time is in the decreasing direction along the x axis.
FINAL WEEK
SCENARIO A : ANALYSIS OF NS3 SIMULATION RESULTS (CNTD.)
We can observe that as the Data rate increases, the number of lost packets increases.
Though, in this theoretical simulation the loss is very minimal, it could indicate much higher losses in a practical scenario.
​
FINAL WEEK
SCENARIO A : ANALYSIS OF NS3 SIMULATION RESULTS (CNTD.)
One of the interesting conclusions we drew from the simulation was that, no matter what the number of participating nodes were, the average Round Trip Time, remained the same for a given Data Rate.
FINAL WEEK
SCENARIO A : ANALYSIS OF NS3 SIMULATION RESULTS (CNTD.)
We can observe that as the Data rate increases, the number of lost packets increases.
Though, in this theoretical simulation the loss is very minimal, it could indicate much higher losses in a practical scenario.
​
WEEK 7 & 8
(SCENARIO B)
We made a lot of improvment over this week on the Real implementation front of the project.
Now, let’s see how we build up the Bluetooth Ad-hoc network with mobile devices, named OVP network, and its corresponding test system, called OVV testing system.
OVP network (Offline voting program) is based on a commercial bluetooth ad-hoc network service library, called Bridgefy SDK, which takes advantage of short ranged bluetooth to enable the application developers to connect their users without any help of the Internet. This is the reason why we call our test program offline, offline to Internet.
-It is useful when big events such like sport games, big lectures, election rallies are held, where the public Internet couldn’t offer congestion-free access or not available for everyone on site. Bluetooth can make up an autonomous network to connect.
WEEK 7 & 8 (CNTD..)
-Our OVP network ideally is designed to accommodate 2-30 nodes. We implemented it on Android mobile devices.
-You can see them on the right diagram. The blue arrowed lines denotes the bluetooth connection.
2) OVV testing system, namely offline voting viewer, is an affiliated system to OVP network. It intends to test and measure the performance of OVP network.
-It’s based on HTTP protocol and offers REST web services to every OVP nodes. Every OVP node device is able to send the status report message to OVV server on the other end of the Internet.
-We implemented it on Django web server.
-You can see it on the previous diagram. The orange arrowed lines denotes the Internet connection to the OVV server.
-
DETAILS OF SCENARIO B
Our OVP network ideally is designed to accommodate 2-30 nodes. We implemented it on Android mobile devices.
You can see them on the right diagram. The blue arrowed lines denotes the bluetooth connection.
OVV testing system, namely offline voting viewer, is an affiliated system to OVP network. It intends to test and measure the performance of OVP network.
It’s based on HTTP protocol and offers REST web services to every OVP nodes. Every OVP node device is able to send the status report message to OVV server on the other end of the Internet.
We implemented it on Django web server.
You can see it on the previous diagram. The orange arrowed lines denotes the Internet connection to the OVV server.
•4 services from OVV
•INIT_BC, ACK_BC
•SEND_E2E, ACK_E2E
•
•Access URL:
WORKING OF OVV & OVP
This page shows the details how OVP to OVP, OVP to OVV interact during the operation and test.
There are 3 types of interaction:
1)BC1, Get-To-Know interaction. It occurs in the broadcast mode. The time sequence diagram here shows the process.
**********************************
1)In the beginning, the OVP master device who starts the voting doesn’t know who is in the vicinity, he sends out a broadcast message. Here is the red solid line pointing to the nearby OVP Client device.
2)At the same time, he reports INIT_BC to OVV web server when he starts this event
3)Secondly, if a client node receives the broadcast message, it responds to the master device with e2e message
4)At the same time, the client node reports ACK_BC to OVV web server.
5)Also, it needs to report SND_E2E to OVV to record the time he originates the E2E message.
6)Finally, master node receives the E2E message from the client node, he reports ACK_E2E to OVV web service ***********************
2)The other 2 interaction are BC2, E2E can been seen as the BC1’s first half and the second half, which are merely involved either broadcast or end to end interaction.
MEASUREMENT PARAMETERS
To measure the performance of OVP network, we select 4 metrics, they are respectively:
1)Transission rate, Rtx
2)Data loss rate, Rloss
3)RTT, round trip time
4)Mobility influnence
​
•Test network topology
•Chain, Mesh
For mobility, we designed 2 test scenes, they are in classroom and on campus.
The variable network topologies are either chaining or meshing.
​
In the project design phrase, we designed 2 sets of test cases to measure the OVP network’s performance in different scenarios. The variables affecting the test cases are data package size, test interval, broadcast and end-to-end transmission modes, node quantity. All test cases are shown in the table on the right.
​
RESULTS OF SCENARIO B
Results at a glance:
•RTT = 0.1 – 2.2 sec
•Rloss < 44%
•RTX = 0.3 – 92 kpbs
•Reality limitation
•Device quantity (2 nodes)
•Test quantity
​
The real-device test, the test result is shown here in the table.
We can see the delay is startlingly long, the loss rate is higher than reasonable tolerance, the transmission rate is far slower than 2.1Mbps of Bluetooth 2.0 specification. This evaluation matches the user experience of Bridgefy’s official sample application which bears long delay and high loss rate. It seems that Bridgefy’s bluetooth network SDK is other than an ideal service for most of upper application developer.
THANK YOU ….
A big thank you for taking interest in our project. If you have any queries regarding our project feel free to reach out to any one of us.
The Team members are :
Anju Rama Krishnan (anjurkrishnan9@gmail.com)
Jian Wang (bamuvic6@gmail.com)
Amit Kumar (maxsteel4@gmail.com)