Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing

April, 2021

Practical Implications of Using Dockers on Virtualized SDN

Sugandhi Midha
Research Scholar, ASET, AMITY University, Gurgaon, India.
E-mail: mailmetech@gmail.com

Khushboo Tripathi
Assistant Professor, AMITY University, Gurgaon, India.
E-mail: ktripathi@ggn.amity.edu

M.K. Sharma
Professor, Amrapali Group of Institutes, Dehradun, India.
E-mail: sharmamkhld@gmail.com

Received November 20, 2020; Accepted December 25, 2020

ISSN: 1735-188X
DOI: 10.14704/WEB/V18SI01/WEB18062

Abstract

Containers, Dockers, and Software Defined Networks are one of the prominent topics in
the market these days. In a wish to cater to new business needs of containers with clouds
and linking all it to SDN gives promising results. To solve various issues like multiple
located branch networks, high cost, technical resources required at each location, expertise
requirement, decentralized control of network devices, dependency on separate VLANs
for each branch, difficult traffic management, etc., we surveyed works of literature and
studies for the various existing SDN controllers. In our paper, we have tried to predict the
importance of using Dockers on the SDN Cloud Platform. Various Parameters like
latency, throughput, bandwidth usage, availability, connectivity, packet loss, etc. have
been used to check SDN performance with and without the use of Dockers. We have tried
to provide detailed test analysis and results regarding various performance parameters
based on the simulations on the Google Cloud Platform (GCP). Results on Dockers have
been proven in terms of resource utilization; talk about CPU usage or memory usage;
usage is rising exponentially in the case of VMs as compared to containers. Bootup
latency time in Dockers is also almost half the time taken by VMs.

Keywords

Containers, Dockers, Software Defined Networks (SDN), Google Cloud Platform (GCP),
Network Performance Metrics.

312 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Introduction

Virtualization in clouds and software defined networks answers the inadequacy of the
conventional systems, for example, the absence of adaptability and trouble of
managing systems. Be that as it may, the arrangement is limited by the speed of
improvement, testing, and organization. Therefore, in the current innovation, there is a
lack of fast movement and augmentation which couldn't fulfill the adaptable unique
prerequisites of various clients to the system. To address these issues, an SDN
controller stage dependent on the Docker motor is introduced to arrange virtualization
on clouds. The framework engineering of the SDN controller dependent on Docker is
done for the point by point structure of virtualization arrangement, programming
characterized systems, that permits compartments to convey, which makes it simpler
to scale an application to deal with bigger workloads. Software defined networks
systems make it conceivable to make increasingly complex applications that length
numerous holders, making it simpler to present regular segments like databases. The
adaptable combination and expansion of the system are acknowledged through the
virtualization of physical resources. This group of programming based system
instruments gives overlay systems and virtual steering usefulness. Programming is
infesting a few parts of the present life. Systems administration is likewise associated
with such a procedure and Midha S. and Tripathi K. (2018) and (2019) has been
observed that Software Defined Networking (SDN) is the most delegate case of how
the directing can be overseen by composing programming conceivably running on
universally useful equipment. In the most recent years, even the capacities supporting
the system (for example firewall or burden adjusting) have been software by the
Network Function Virtualization (NFV) design idea, prompting Virtual Network
Functions (VNFs). NFV incredibly profits by the favorable circumstances presented
by SDN engineering since a focal controller can figure out where VNFs are situated in
the network. Bonofigilo et al. (2018) has stated that A Software Defined Network
(SDN) is a rising cloud innovation that gives dynamic systems administration
framework through automatic application programming interfaces (APIs). Figure 1 as
illustrated by Dough Chamberlain (2018) specifies the architecture of Virtual Machine
and Container images on Docker. An operating system runs on each VM. On top of
the physical layer, VMs with different OS such as Linux, UNIX, Windows, Ubuntu,
etc. can be installed. On the other hand, container architecture is built directly on the
kernel, and a common operating system is shared by all applications as mentioned by
SDX Central (2020).

313 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Fig. 1 VMs Vs Container Architecture

SDN drastically strengthens the handling capacity of servers as mentioned by Midha

S. and Tripathi K. in their work (2018) and (2019). Use rises, and capacity is denser in
SDNs so basically SDN, in its full fulfillment, expels the go-between layers, making
the product what is organized. Presently applications can have addresses, which are
one of the head advantages of containerized, appropriated situations, utilizing Docker
or CoreOS holders under Kubernetes or Swarm orchestration. Containers as by Adtran
(2020) are a type of working framework virtualization. A solitary holder may be
utilized to run anything from a little microservice or programming procedure to a
bigger application. Barakabitze A. et al (2020) and Adtran (2020) has mentioned in
their work that inside a holder are for the most part the essential executables, parallel
code, libraries, and arrangement documents. Contrasted with server or machine
virtualization draws near, be that as it may, holders don't contain working framework
pictures. This makes them progressively lightweight and versatile, with fundamentally
less overhead. In bigger application arrangements, various compartments might be
conveyed as at least one holder cluster. Container organizing is a technique for
virtualization that isolates out applications into free boxes. Containers can run
enormous, disseminated applications with low overhead. They do this by sharing a
stripped-down working framework part (typically dependent on Linux), making them
more productive than virtual machines (VMs). Containers are likewise less complex
than VMs. Docker is taking a biological system approach.Docker's open-source
undertaking will permit clients to figure out which containers ought to be associated
together for applications. SDN has affected the OpenStack open-source cloud
programming just as virtualization stages like VMware's, and now SDN is coming
snappy and quick to holders.

314 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

This paper discusses the implementation of virtualization on the cloud using dockers
via software defined network. The problem of increasing network traffic and how the
quality is supported by shifting the SDN over dockers is explained with the help of
conducting experiments on the GCP.

Related Work

This section presents a summary of the virtualization in Software Defined Networks.

Not much work has been done on Dockers and Containers of the Network layer but
the following are the main observations of the references used in this work.

Syed et al. (2018) in their work present Kathará, a system dependent on compartments,
which permits to arrange administrators to convey Virtual Network Functions (VNFs)
through the appropriation of developing information planes programmable abilities,
for example, P4-consistent switches. It likewise underpins the concurrence of SDN
and customary steering conventions to set up discretionarily complex systems. As a
symptom, because of Kathará, the authors exhibit that actualizing NFV by methods for
explicit reason hardware is possible and it gives an addition in execution while
safeguarding the advantages of NFV. Additionally, the developing utilization of
compartment advancements is because of the way that they decrease the provisioning
time regarding VMs and it is anything but difficult to track down pre-constructed
pictures to run a wide assortment of administrations. The asset utilization of Kathará is
measured and it is shown that it performs better than structures that execute virtual
systems utilizing virtual machines by a few sets of magnitude as mentioned by
Bonofiglio et al (2018) in their work. This paper depicts a few models made for
containers with conceptual parts. They help sum up the frameworks to deal with
intricacy and heterogeneity; they give a typical jargon and assemble comprehensive
and bound together perspectives on the frameworks. The utilization of UML for
demonstrating improves accuracy. This can prompt better executions regarding the
dependability, security, and interoperability contrasted with specially appointed
strategies. The reference design won't simply encourage crafted by engineers and
security designs yet additionally of any individual who means to guarantee
consistency, protection, wellbeing, unwavering quality, or potential administration for
compartment biological systems and this paper describes the best way to construct
one. Likewise, connections between compartment, cloud, and IoT biological systems
are depicted. This paper is a piece of the authors' work on building up security
reference engineering for holder biological systems. As a piece of the continuous
work, the authors are broadening the reference design introduced in segment 3 to
include security and abuse designs, in this way building up a security reference
engineering for container biological systems, in the style of Gao et al. (2017). A list of
examples is made for containers including structure and security designs just as an

315 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

inventory of abuse designs depicting their dangers. The objective is to encourage

crafted framework planners and designers that are utilizing compartment based
frameworks, help make the environment more obvious for them, and thus make it
simpler to perform security investigation of the framework as said by Syed et al.
(2018). Container innovation gives a lightweight working framework level virtual
facilitating condition as observed by Midha S. and Tripathi K. (2020) and Abdullaliz
et al. (2016). Its rise significantly changes the turn of events and sending standards of
multi-level circulated applications. In this paper, the authors initially present the data
spillage channels they found that is open inside the holders. Such channels uncover a
range of framework wide host data to the holders without appropriate asset
apportioning. By misusing such spilled data, it turns out to be a lot simpler for
malignant foes (going about as inhabitants in the holder mists) to dispatch propelled
assaults that may affect the unwavering quality of cloud administrations. Furthermore,
they discussed the underlying drivers of the holders' data spillages and proposed a
two-phase barrier approach. As shown in the assessment, the answer is viable and
acquires minor execution overhead. The topic of how to adjust security, execution and
ease of use in holder mists need further examination as found by Z. Hu et al. (2015).
Holder cloud administrations have gotten well known for giving lightweight OS-level
virtual facilitating situations. The rise of holder innovation significantly changes the
eco-arrangement of creating and conveying dispersed applications in the cloud. Be that
as it may, because of the inadequate execution of framework asset parceling systems
in the Linux part, there still exist some security worries for numerous compartment
occupants having a similar bit. In this paper, an efficient way to deal with finding data
spillage channels that may open host data to holders is presented. The assessment
exhibits that the proposed arrangement is powerful and causes unimportant execution
overhead. As per Gao et al. (2017), A Container Manager goes about as a significant
level regulator that can coordinate and deal with the execution of holders over various
Hosts that structure a Cluster. A holder administrator deals with the various
arrangement of compartments and their shared conditions and associations by
gathering intently related compartments into sets, named Coherent Units (CUs), which
are overseen as a solitary substance. SDX Central (2020) has found that researchers
are working on how effective dockers and containers are for the network and
application layer for the virtual environments in networking.

Research Objective

“To develop an efficient framework for Network traffic in SDN that supports Quality
of Service by guaranteeing the improvement of performance metrics over VM
networks”

316 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Virtual Machines Simulation on GCP

Google Cloud Platform has been chosen as the platform under test. It is one of the
trusted and popular cloud platforms and supports the various functional features like
infrastructure management, access policy management, topology management,
scaling, routing management, path selection management, etc. required in the
simulation of both environments. For simulation purposes, 5 instances of VMs have
been setup on Google’s infrastructure. All the instances have been created using the
GCP console shell. Each of 5 instances of VMs under test run OpenFlow controller on
them. Figure 2 is listing all the 5 VMs hosted on GCP.

Fig. 2 Virtual Machines Specification

There are different types of machines are available for different requirements as
listening in table1 with their suitability to particular application and environment. We
have used N1 with 1vCPU and 3.75 GB memory which is available for short periods
of bursting. While creating each VM instance, you need to specify the zone, machine
type & operating system of that instance. Each instance is organized in the form of a
project on GCP. All the instances which belong to the same network communicate via
Local Area Network protocol. Talking to a machine outside the network requires the
internet.
Table 1 Machine Type Suitability
E2 N2, N2D, N1 M2, M1 C2
General Purpose General Purpose Memory Compute-
Optimised optimized
For day-to-day Best price For ultra-high For ultra-high
computing at a management/performance with a memory compute-
lower cost variety of available VM instances requirements intensive tasks
• Web serving • Web serving • Large in- • HPC
• App serving • App serving memory • Electronic
• Backoffice • Back office applications databases like Design
applications • Medium-large databases SAP HANA Automation
• Small-medium • Cache • In-memory (EDA)
databases • Media/streaming analytics • Gaming
• Microservices • Single-
• Virtual desktops threaded
• Development application
Environments

317 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

After performing a detailed comparative study of machines as listed in Table 2, for

various available machine types, we determined the suitable machine type for our
study at hand.
Table 2 Machine Types Comparison
Machine Memory vCPUs Custom Sustained- Local Processors
Types (per Machine use SSDs
vCPU) Types discounts?
General- 0.5-8 2-32 Yes No No • Skylake
purpose GB • Broadwell
(E2)
• Haswell
• AMD EPYC
Rome
General- 0.5-8 2-80 Yes Yes Yes • Cascade
purpose GB Lake
(N2)
General- 0.5-8 2-224 Yes Yes Yes • AMD EPYC
purpose GB Rome
(N2D)
General- 0.95-6.5 1-96 Yes Yes Yes • Skylake
purpose GB • Broadwell
(N1)
• Haswell
• Sandy
Bridge
• Ivy Bridge
Compute- 4 GB 4-60 No Yes Yes • Cascade
optimized Lake
Memory- 24 GB 40-416 No Yes No • Broadwell
optimized E7
ultramem • Cascade
Lake
E2 4 GB 0.25-1 No No No • NA
shared-
core
N1 3.0-3.4 0.2-0.5 No Yes No • NA
shared- GB
core

Various performance measures as stated by Zhang et al. (2018) and Shirinbal S. et al.
(2020) have been conducted on the VMs to explore network performance.

Latency Measure: Ping command is used to not only check the connectivity between
virtual machines but also to measure the packet loss and latency.

318 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

𝑳𝒂𝒕𝒆𝒏𝒄𝒚 = 𝑹𝒐𝒖𝒏𝒅 𝑻𝒓𝒊𝒑 𝑻𝒊𝒎𝒆 (𝑹𝑻𝑻)

𝑳𝒂𝒕𝒆𝒏𝒄𝒚 = 𝑴𝒆𝒔𝒔𝒂𝒈𝒆 𝒔𝒆𝒏𝒕 𝒕𝒊𝒎𝒆 𝒇𝒓𝒐𝒎 𝒗𝟏 𝒕𝒐 𝒗𝟐 + 𝑹𝒆𝒔𝒑𝒐𝒏𝒔𝒆 𝑻𝒊𝒎𝒆 𝒇𝒓𝒐𝒎 𝒗𝟐 𝒕𝒐 𝒗𝟏
Ping uses icmp “echo request” and “echo reply” messages. Figure 3 is listing the
latency measure from e1-vm to eu1-vm which is the total of a request message from
e1-vm to eu1-vm and the return response from eu1-vm to e1-vm.

Fig. 3 Latency measures using ping icmp

High latency is an undesirable property by the user. Ideally, latency is limited by the
speed of light present in that fiber.

Table 3 Ideal Latency and Observed Latency

Locations Ideal Latency Observed Latency Difference

us-west1 – us-east1 37.12 ms 66.55 ms 79%

us-west1 – europe-west1 80.02 ms 139.00 ms 74%

us-west1 – asia-east1 99.59 ms 121.56 ms 22%

us-east1 – europe-west1 67.51 ms 93.40 ms 38%

us-east1-asia-east1 131.44 ms 189.27 ms 44%

europe-west1– asia-east1 95.61 ms 261.98 ms 174%

The latency between Europe-west1 and asia-east1 in Table 3is observed high as GCP
does not have a direct link between both. The ideal latency depicted in the table is
specific to GCP zones and fiber installations.

Packet Loss: Ping is used for measuring the loss of packets sent from the source and
the packet received at the receiver end. Different cases have been considered for
sending packets at different intervals, varying packet sizes, and flooding packets.
𝑷𝒂𝒄𝒌𝒆𝒕 𝑳𝒐𝒔𝒔 = 𝑵𝒖𝒎𝒃𝒆𝒓 𝒐𝒇 𝑷𝒂𝒄𝒌𝒆𝒕𝒔 𝑺𝒆𝒏𝒕 𝒃𝒚 𝒕𝒉𝒆 𝑺𝒐𝒖𝒓𝒄𝒆
− 𝑵𝒖𝒎𝒃𝒆𝒓 𝒐𝒇 𝒑𝒂𝒄𝒌𝒆𝒕𝒔 𝒓𝒆𝒄𝒆𝒊𝒗𝒆𝒅 𝒂𝒕 𝑫𝒆𝒔𝒕𝒊𝒏𝒂𝒕𝒊𝒐𝒏

319 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Case 1: Result captured after a Packet sent at an interval of every 20 ms(refer to figure 4).

Fig. 4 Case 1 Ping statistics with 0%Packet Loss

Case 2: Result captured after 1000 Packets sent at an interval of every 50 ms(refer to figure 5).

Fig. 5 Case 2 Ping Statistics with 2% Packet Loss

Case 3: Result captured after Flooding with ping (refer to figure 6).

Fig. 6 Case 3 Ping Statistics with 0% Packet Lossand packets in Pipe

Case 4: Result captured after Sending larger Size packets (refer to figure 7).

Fig. 7 Case 4 Ping Statistics with 1% Packet Loss

320 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Trace Route: It helps in discovering network issues. It uses the TTL (Time To Live)
parameter. TTL count is decreased by 1 whenever it is received by any host on the
network. Once TCL reaches zero, the packet is discarded. It should be set to an
appropriate number so that packet does not even get discarded or unnecessarily loops
on the network. Fig 7, shows the traceback of our VM eu1 (refer to figure 8).

Fig. 8 Trace Route with 60 hops for VM eu1.

MTR (Matt’s Trace-Route): It performs the traceroute as well as possess the

capability of ping to capture the packet loss (refer to figure 9).

Fig. 9 MTR for e1-vm with 0% Packet Loss

Iperf: It has been used to measure performance between different VMs. eu-1 VM is
the server point and the data transmission rate, bandwidth, and interval have been
calculated for all other 4 VM instances clients with the server (eu1-vm) (refer to figure
10 to 13).

Fig. 10 Eu1-vm and e1-vm iperf

321 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Fig. 11 Eu1-vm and asia1-vm iperf

Fig. 12 Eu1-vm and w1-vm iperf

Fig. 13 Eu1-vm and w2-vm iperf

Docker Framework with Containers Simulation Results on GCP

In contrast to VMs discussed in the previous section, the declarative method known as
containers can be used to create VM instances using a template by just mentioning a

322 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Docker image name and some launch configuration. With container deployment, app
deployment is simplified with the following features:

• Auto-Scaling
• Auto-Healing
• Auto-Repair
• Auto-upgrades
• Rolling Updates
• Load Balancing
• Multi-Zone Deployments

Docker Containers share the operating system which makes them lightweight.
Containers are self-contained application packages that support easy portability across
different infrastructure platforms. Deployment becomes easy for Docker Containers as
compared to VMs. Figure 14 is listing all 5 container images used for the simulation
and testing purposes.

Fig. 14 List of Container images

Figure 15 shows the CPU usage with 1 container instance running at idle times.

Fig. 15 CPU Usage

323 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Case 1 Packet Loss: Result captured after a Packet sent at an interval of every 20 ms (refer to
figure 16).

Fig. 16 Case 1 Ping statistics with 0%Packet Loss

Case 2 Packet Loss: Result captured after 1000 Packets sent at an interval of every 50 ms
(refer to figure 17).

Fig. 17 Case 2 Ping Statistics with 0% Packet Loss

324 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Case 3 Packet Loss: Result captured after Flooding with ping (refer to figure 18).

Fig. 18 Case 3 Ping Statistics with 0% Packet Loss and packets in Pipe

Case 4 Packet Loss: Result captured after Sending larger Size packets (refer to figure 19).

Fig. 19 Case 4 Ping Statistics with 0% Packet Loss

Performance Measures - Comparative Results of VM and Docker Containers

Since in this study, performance is the prime focus, various measures have been taken
into considerations such as resource utilization in terms of CPU, memory, I/O, and
Boot-time latency at different interval of times with the different amount of network
traffic such as normal traffic, flooding, repetitive flood, etc. to find the best technique

325 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

among the both. A container is always a favourable option than running a virtual
machine as it is lightweight. Docker is a platform used for creating various containers
for running various resource isolated processes. Our results depict how Docker-based
Containers are better in terms of resource utilization. Table 4 lists the various
performance measures in terms of VMs and Docker Containers.

Table 4 Performance Measures – Dockers Vs VMs

Performance Docker VMs
Measure Containers
Resource Intensive Less More
Architecture Lightweight Heavy
CPU Usage Low High
Memory Usage Low High
I/O Usage Low High
Scaling Up Easy Difficult
Boot Time Latency Low High
Deployment Easy Little cumbersome as compared to
Containers.

Boot-up Latency: Boot-up time is the difference between the time VM or container
started and the time it provided services to the client node. Less boot time yields a
better experience for the user. Table 5 lists the total latency with different traffic loads
for each 6 VMs/Container images. Figure 20 depicts that latency measures for VM and
Docker Containers.

Table 5 Boot-up Latency Measure – Container Vs VM

Component Images Total Time Taken (ms)
VM 6 46
Container 6 23

Fig. 20 Latency Measures – VM Vs Docker Containers

326 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

CPU Usage: It is measured during different times based on flooding the network at
different times with the different amounts of network packets & different sizes of
packets. Figure 21 shows the CPU usage by VM and Container with different amounts
of network traffic. Less the amount of CPU usage, the better the performance is as the
CPU is free to perform other tasks.

Table 6 CPU Usage – Container Vs VM

Component Packet Flow CPU Utilisation
(%)
VM 1000 Packets of 64 bytes sent at an 24%
interval of every 50 ms
Packet Flooding 57%
1000 Packets of 1408 bytes sent at an 70%
interval of every 50 ms
Docker 1000 Packets of 64 bytes sent at an 12%
Container interval of every 50 ms
Packet Flooding 32%
1000 Packets of 1408 bytes sent at an 46%
interval of every 50 ms

Fig. 21 CPU Usage – VM Vs Docker Containers

Memory Utilisation: It is efficiently utilized in the case of Dockers as no separate OS

needs to be installed for any container as compared to VMs which are booted with a
separate OS. Table 7 shows the memory utilization in GB with 2, 4, and 5 images of
VMs and containers. Figure 22 depicts that memory usage is not exponentially rising
in the case of containers as compared to VMs.

327 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

Table 7 Memory Usage – Container Vs VM

Component 2 VMs/2 4 VMs/4 5 VMs/5
Container Container Container
images images images
Memory Utilisation (GB)
VM 4 8 10
Docker Containers 1.15 2.2 2.5

Fig. 22 Memory Usage- VMs Vs Docker Containers

Conclusion & Future Scope

VMs have been used for several decades & have a wide implementation in data
centres. VMs have made it possible to run multiple OS concurrently. Although VM is
beneficial in some aspects it causes overhead on CPU, memory & I/O resources.
Resource utilization efficiency can be improved with the help of lightweight Docker
containers. The container also possesses the capability to virtualize the OS. A
container is the complete package of the application and its binaries & libraries. As a
baseline, we have performed the performance measures on container & VMs. The
performance results were obtained to be better in terms of resource utilization on
containers. Since containers provide the best results but the usage of VMs can’t be
avoided and neglected. VMs have proven to be secure as they use their OS without
being a threat to the host machine. An area that imposes challenges in the usage of
Docker Containers is security concerns which demand more exploration & study from
researchers.

328 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

References

Bonofiglio, G., Iovinella, V., Lospoto, G., & Di Battista, G. (2018). Kathará: A container-
based framework for implementing network function virtualization and software
defined networks. In NOMS IEEE/IFIP Network Operations and Management
Symposium, 1-9. https://doi.org/10.1109/NOMS.2018.8406267
Syed, M.H., & Fernandez, E.B. (2018). A reference architecture for the container
ecosystem. In Proceedings of the 13th International Conference on Availability,
Reliability and Security, Article No 31, 1-6.
Gao, X., Gu, Z., Kayaalp, M., Pendarakis, D., & Wang, H. (2017). Container Leaks:
Emerging security threats of information leakages in container clouds. In IEEE47th
Annual IEEE/IFIP International Conference on Dependable Systems and Networks
(DSN), 237-248.
Doug Chamberlain (2018). Container Vs Virtual Machines. E-Library.
https://blog.netapp.com/blogs/containers-vs-vms/
Zhang, Q., Liu, L., Pu, C., Dou, Q., Wu, L., & Zhou, W. (2018). A comparative study of
containers and virtual machines in big data environment. In IEEE 11th International
Conference on Cloud Computing (CLOUD), 178-185.
https://doi.org/10.1109/CLOUD.2018.00030
Shirinbab, S., Lundberg, L., & Casalicchio, E. (2020). Performance evaluation of
containers and virtual machines when running Cassandra workload
concurrently. Concurrency and Computation: Practice and Experience, 32(17),
e5693.
Midha, S., & Triptahi, K. (2018). Assessing the Quality of Service of POX Controller in
SDN. International Journal of Computational Engineering and Research, 8(8),
21-25.
Midha, S., & Triptahi, K. (2019). Extended TLS security and Defensive Algorithm in
OpenFlow SDN. In IEEE 9th International Conference on Cloud Computing, Data
Science & Engineering (Confluence), 141-146.
https://doi.org/10.1109/CONFLUENCE.2019.8776607
Midha, S., & Tripathi, K. (2021). Extended Security in Heterogeneous Distributed SDN
Architecture. In Advances in Communication and Computational Technology, 668,
991-1002. https://doi.org/10.1007/978-981-15-5341-7_75
Midha, S., & Tripathi, K. (2020). Remotely Triggered Blackhole Routing in SDN for
Handling DoS. In Proceedings of International Conference on IoT Inclusive Life
(ICIIL 2019), NITTTR Chandigarh, India, 116, 3-10.
https://doi.org/10.1007/978-981-15-3020-3_1
SDX Central (2020). An Introduction to Session Smart Routing: 128 Technology.
https://www.sdxcentral.com/resources/sponsored/downloads/an-introduction-to-
session-smart-routing-128-technology/
SDX Central (2020). Network Meet Cloud: Scaling Disaggregated Network Infrastructure
using Cloud Principles.
https://www.sdxcentral.com/resources/sponsored/downloads/network-meet-cloud-
scaling-disaggregated-network-infrastructure-using-cloud-principles/
Barakabitze, A.A., Ahmad, A., Mijumbi, R., & Hines, A. (2020). 5G network slicing using
SDN and NFV: A survey of taxonomy, architectures and future
challenges. Computer Networks, 167, 106984.

329 http://www.webology.org
Webology, Volume 18, Special Issue on Artificial Intelligence in Cloud Computing
April, 2021

https://doi.org/10.1016/j.comnet.2019.106984
Adtran. SDN and NFV The Path Forward for Broadband Access,
https://portal.adtran.com/web/fileDownload/doc/33201
Midha S., Tripathi K. (2020). Data hiding based PKI Authentication Protocol in SDN, Test
magazine journal; Elsevier, 82.
Hu, Z., Wang, M., Yan, X., Yin, Y., & Luo, Z. (2015). A comprehensive security
architecture for SDN, 18th International Conference on Intelligence in Next
Generation Networks, Paris, France, 30-37.
https://doi.org/10.1109/ICIN.2015.7073803.
Abdullaziz, O.I., Chen, Y.J., & Wang, L.C. (2016). Lightweight authentication mechanism
for software defined network using information hiding. In IEEE Global
Communications Conference (GLOBECOM), 1-6.
https://doi.org/10.1109/GLOCOM.2016.7841954

330 http://www.webology.org