ICACT20220041 Slide.25
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Thanks for your attention ! Welcome any comment or question.
|
|
ICACT20220041 Slide.24
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Here are the references cited in my presentation.
|
|
ICACT20220041 Slide.23
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Our test result has demonstrated that the model using SR-IOV and CPU-pinning outperformed the bare-metal model with CPU-pinning by 30%, in terms of network throughput and package processing. On the other hand, the Cloud-native model using Calico performed worse than the bare-metal model with CPU-pinning, while the bare-metal model without CPU-pinning performed the worst. The subpar performance of the model using Calico can be explained by the need for more hardware resources as well as more time to encapsulate packets and route them to network cards. Meanwhile, SR-IOV helped containers directly connect to NIC; packets therefore bypassed the kernel stack in order to deliver high performance.
The optimistic results informed our decision to employ SR-IOV and CPU-pinning in the production deployment of vOCS4.0.
Besides SR-IOV, DPDK is gaining traction as a means to improve computing efficiency and packet throughput. DPDK consists of libraries to accelerate packet processing by offloading TCP packet processing from the operating system’s kernel to processes running in the user space. This capability has prompted us to tinker with DPDK, beside SR-IOV, in the pursuit of a better vOCS. We will also look into the optimal disk I/O for Kubernetes with high IOPS applications.
|
|
ICACT20220041 Slide.22
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
I will now proceed to the end of my presentation by discussing some potential future works
|
|
ICACT20220041 Slide.21
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Resource usage and system performance among different network models are listed here. The result shows that CPU-pinning compounded the CPU workload. In both the bare-metal model and the Cloud-native model using SR-IOV, CPU utilization reached 46% and 45% respectively. Meanwhile, the two remaining models were slightly more resource-conscious, approaching approximately 40% in CPU utilization. The result also confirms the synergy between CPU-pinning and SR-IOV. In fact, the Cloud-native model using SR-IOV and CPU-pinning achieved 70.000 TPS, 1.5 times the TPS obtained by the bare-metal model without CPU-pinning (which was only 50.000 TPS). Therefore, this model may help vOCS serve significantly more customers. Interestingly, the latency did not go up but rather dropped to 2.87 ms. That said, the differences in latency among the four models were negligible.
|
|
ICACT20220041 Slide.20
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
We implemented the CHF with four different network models:
•The bare metal model, CPU-pinning not applied
•The bare metal model, CPU-pinning applied (the evaluation baseline)
•The Cloud-native model using Calico, CPU-pinning applied
•The Cloud-native model using SR-IOV, CPU-pinning applied
All implementations of the CHF followed the same deployment architecture, as shown in Figure 11. The test client generated the charging traffic to the CHF network charging gateway (CGW) pods. The traffic included both balance inquiries and a mixture of initiate, update and terminate charging operations across data, voice as well as messaging services. Containers were run on three physical nodes with Intel 8260, which have ninety-six 2.4GHz threads and 256GB RAM. Each pod used two vCPU and 6GB RAM. Horizontal Pod Autoscaler was used during the entire test. The Kubernetes version was 1.18, and the Aerospike version was 4.13 in all deployments. Twenty million simulated accounts were provisioned over six Aerospike nodes. Three metrics were considered: throughput (in TPS - transaction per seconds), latency (in milliseconds) and CPU utilization (in %).
|
|
ICACT20220041 Slide.19
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In this section, I will describe the simulation environment and our test result
|
|
ICACT20220041 Slide.18
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, I will talk about another important component, the microservice chassis library. Kubernetes implements the decoupling architecture in which services are separated from each other. The connections between them are established via service discovery as well as an internal Domain Name System (DNS). These network interactions contribute to longer request and response times, as well as higher latency overall. A Service of LoadBalancer type is attached to an Ingress Controller, a set of Ingress that defines where to forward traffic. Each traffic to a service container that passes through the Ingress controller may aggravate the container’s network connectivity overhead. The microservice chassis library alleviates this issue as it lets applications discover the addresses of service containers and connect to them directly. The chassis accommodates scaling by updating the set of container addresses. As a result, network latency should be adequately lessened for telecommunication applications. Besides, we also apply another technology as CPU pinning to improve the performance of network models. What is CPU pinning ? CPU scheduling algorithms in operating systems usually elect a process to use the CPU at a given time, while the other processes are put on hold. The wait time can accumulate into discernable latency when the operating system has to handle many processes, including application processes or containers. In the case of a heavy workload, the operating system’s native CPU scheduling may jeopardize the performance of 5G Core, whose processes may have their resources temporarily taken away. To fix this problem, CPU-pinning can be used to manually assign a fixed set of CPU cores to a process or a container. The process or container then owns a fixed number of vCPU for its whole lifecycle and no longer has to wait for others. Eliminated wait time is of course conducive to enhanced performance. As you can see, every pod or service in this testbed model uses 2 vCPU and 6 GB RAM.
|
|
ICACT20220041 Slide.17
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This is the deployment architecture for CHF in vOCS 4.0, and also the testbed model we used. It consists of 3 main components:
• Connectivity layer:
– Load balancer: an external-facing physical load balancer that receives traffic from other 5G services.
– CGW: a gateway that receives incoming traffic via load balancer then converts it to a usable format.
• Business logic:
– OCP: a component that handles calculation tasks.
• Data management:
– ABM: a proxy that processes queries into the database.
– Database: two Aerospike active-active database clusters, each containing information of 10 million subscribers.
|
|
ICACT20220041 Slide.16
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The Charging Function (CHF), a crucial module of 5G core, encompasses support for both prepaid and postpaid billing within the same charging system. Our test focused on the performance of the CHF. The CHF has three layers:
• Connectivity: stateless sets of components that interface with external entities via an API gateway.
• Business logic: a stateless set of application layers that include business logic, policy engine and other necessary services.
• Data management: the data access layer handling multiple backend storages (such as Database).
|
|
ICACT20220041 Slide.15
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Similar to Virtual Machine, containers on each worker node are sharing a virtualized single port of the NIC via software emulation. Figure 9b shows the container-based network model, with the container’s network port connecting to NIC via CNI and Container Network Plugin. The multiple layers of emulation predictably worsen container overhead. Furthermore, surging network traffic is a burden to the CPU, taking up computing resources meant for other applications.
SR-IOV enabled physical network functions to be shared without software emulation. It provides two function types: The Physical Function and Virtual Function. The Physical Function, a PCIe function of a SR-IOV compatible NIC, configures and manages the SR-IOV functionalities, such as enabling virtualization and exposing Virtual Functions. Directly accessible to the operating system, each Virtual Function represents a virtualized instance of the NIC and has its own PCI configuration space. Virtual Functions share physical resources on the NIC with each other and with the Physical Function. Thanks to SR-IOV, the container can directly send and receive packages to/from Virtual Functions in the user space instead of the kernel space. Taking CNIs out of the equation also removes the associated computing cost and latency.
|
|
ICACT20220041 Slide.14
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
We implemented the CHF with three major network models: bare metal, Calico and SR-IOV. Now, I will present the first 2 models and the SR-IOV model in the next slide.
In the bare metal model, all the components of vOCS run on the same operating system, sharing physical resources like CPU, RAM, and Network. This model does not suffer from the extra overhead caused by virtualization. However, heavy workload and frozen applications can impact the system as a whole, leading to degradation in quality of service.
Calico is a common Container Network Interface (CNI). So, what is CNI ? Kubernetes offers the option to integrate different network solutions through CNI plugins. A CNI plugin inserts a network interface into the container’s network namespace. It also makes necessary changes to the network configuration on the host. The plugin also assigns an IP address to the interface and setup routes that are consistent with the IP Address Management section. It does so by invoking the appropriate IP Address management (IPAM) plugin.
Calico creates overlay networks and establishes connections between pods across the nodes, but it also manages network security and administration. The Calico node agent consists of two main components: Felix and BIRD. Felix runs on machines that host endpoints and ensures that only valid traffic crosses endpoints, by programming routes and iptable on the host. BIRD is the BGP (Border Gateway Protocol) daemon that distributes routing information to other nodes. Calico supports three routing modes: Native, IP-in-IP, and VXLAN. The network model using Calico applies the IP-in-IP encapsulation type only to traffic crossing a subnet boundary. The rationale behind using Calico in our test bed was that it offers a satisfactory bandwidth while not prone to resource exhaustion.
|
|
ICACT20220041 Slide.13
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In the next section, I will give you an overview of the network models we considered in our research
|
|
ICACT20220041 Slide.12
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
We aim to emulate the success seen in VMs using NFV with SR-IOV, so we implement SR-IOV in cloud-native network-intensive 5G applications. Our test was undertaken within the Charging Function (CHF), a module in what is to be vOCS 4.0 for 5G. CHF is an apt candidate for the purpose of our research because it requires the lowest latency for a smooth-running vOCS.
Three metrics were considered: throughput (in TPS - transaction per seconds), latency (in milliseconds) and CPU utilization (in %).
Our solution using SR-IOV and CPU-Pinning has boosted the network throughput by 30%, in comparison with the Calico-enabled Kubernetes deployment.
|
|
ICACT20220041 Slide.11
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Study [6] indicated that SR-IOV have cut down virtualization-induced bandwidth loss by 2% and latency by 10% in VMs
|
|
ICACT20220041 Slide.10
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Performance of different network models has attracted considerable interest in the realm of virtualization. Some researches have investigated this topic specifically in the context of Kubernetes deployment.
For instance, Kumar and Trivedi in study [4] noted that Calico maintained adequate bandwidth for transmitting packets with low resource utilization.
On results regarding SR-IOV, Jie Zhang in study [5] compared bandwidth utilization and latency experienced by VMs with SR-IOV, VMs with PCI passthrough, and containers with PCI passthrough. Nevertheless, the article’s comparisons left out containers with SR-IOV, and the authors did not comment on resource consumption.
|
|
ICACT20220041 Slide.09
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Now, I will quickly go over previous contributions made by other authors and how our research
|
|
ICACT20220041 Slide.08
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Network Function Virtualization (NFV) with Single Root Input/Output Virtualization (SR-IOV) has been documented to provide better network performance on VMs. Thanks to SR-IOV, multiple operating systems can share a physical interface via Virtual Functions (VFs) on the same Network Interface Card (NIC). SR-IOV enables network traffic to bypass the software switch layer of the Hyper-V virtualization stack. Because the VF is assigned to a VM, the network traffic flows directly between the VF and VM. As a result, the I/O overhead in the software emulation layer is diminished and achieves network performance that is nearly the same performance as in non-virtualized environments.
|
|
ICACT20220041 Slide.07
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
5G is set to cater both to a myriad of new services (such as AR/VR, Mobile Edge Computing) and to traditional services (such as Voice, Data, and SMS). An inefficient charging system would be the bane of a network meant for an ever-escalating number of transactions. Currently, we are using a real-time cost calculator called Viettel Online Charging System, or vOCS for short, to track telecommunication service usage. The current version, vOCS 3.0, is running on bare-metal servers without enhanced network solutions such as Calico and SR-IOV. In addition, another version deployed in the form of virtual machines in 2020, vOCS DR, works simultaneously with vOCS 3.0. The performance required of 5G has rendered our current bare-metal deployment glaringly unfit. In fact, the next version, vOCS 4.0 for 5G, calls for a much-needed cloud migration.
|
|
ICACT20220041 Slide.06
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Following the same trend, the place of containerization in 5G is inevitable and irrefutable. To leverage the cloud architecture, the 5G core relies on modularized and containerized cloud-native network functions, which enable highly flexible scaling and function lifecycle management. Currently, 5G Core products offered by Samsung are built on cloud-native, microservice-based technology. To get this result, Samsung has actively cooperates with other partners, and participates in organizations such as Cloud Native Computing Foundation (CNCF), which leads the de-facto standard for cloud Technology. They have also taken part in Open Network Automation Platform (ONAP), a telco-oriented open source project
|
|
ICACT20220041 Slide.05
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The Cloud Native Computing Foundation (CNCF) Cloud Native Survey takes the pulse of the community to gain a better understanding of where and how cloud native technologies are being adopted. CNCF surveyed its extended community during May and June 2020 and received 1,324 responses.
In 2020, 92% of respondents say they use containers in production, an extraordinary 300% increase from just 23% in the first survey in March 2016. This is also up from 84% of respondents in 2019 and 73% in 2018. Again, we see steady growth in the number of containers that organizations run. Those using more than 5,000 containers hit 23% in 2020, up by 109% from the 11% we saw in 2016. 61% now use more than 250 containers, up from 57% in 2019.
91% of respondents report using Kubernetes, 83% of them in production. This continues a steady increase from 78% last year and 58% in 2018. Of those using Kubernetes, two to five remains the most common number of production clusters, with 39% reporting that quantity, down from 43% last year. There was an increase in those using more than 11 production clusters from 24% in 2019 to 28% in 2020, and a 56% increase from 2017.
|
|
ICACT20220041 Slide.04
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
First, we will talk about containers and Kubernetes. A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. Kubernetes is a container-based deployment platform with many benefits such as elasticity, durability, ease of management, and cost-effectiveness.
Cloud-native containerization is replacing Virtual Machine (VM) as the preferred method of application deployment. However, the network requirements involved, including high performance and low latency, prove to be a barrier to the deployment of 5G applications. Cloud-native Network Function (CNF) enables network functionalities to run in containers instead of on traditional bare metal servers.
|
|
ICACT20220041 Slide.03
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The first section is about the role of network performance in virtualization, and why it matters in the context of 5G
|
|
ICACT20220041 Slide.02
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The presentation will go as follows. First, I will introduce the problem that we aim to address. Then, I will briefly talk about previous efforts related to our research, before discussing why our contribution is meaningful. The third and fourth sections will describe our solution and the result we obtained with it. Finally, I will close my session with some comments on future research directions.
|
|
ICACT20220041 Slide.01
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Hello everyone, my name is Dinh Tam Nguyen. I am currently a cloud engineer in Viettel High Technology Industries Corporation and a master student at Hanoi University of Science and Technology in Vietnam. I am very glad to present my research named “Enhancing CNF performance for 5G core network using SR-IOV in Kubernetes”.
|
