This article explores the computing and communication overhead of network processing in Internet of Things (IoT) devices, focusing on containers, a major building block for the edge computing. Our experiments reveal that containers on IoT devices suffer$\sim 2.6\times $higher CPU usage for SoftIRQ processing, ~59% less network throughput, and$2\times $higher per-packet latency on average than native processes. While several existing studies enhance networking performance, they often sacrifice interoperability by requiring special hardware or modifying networking semantics or APIs. Thus, we design and implement a kernel networking accelerator, called SCON, that maintains interoperability, crucial for IoT devices. SCON addresses major bottlenecks in container networking through system-level profiling. We evaluate SCON with three types of IoT devices. On the Raspberry Pi 4, SCON reduces the latencies of major IoT application protocols (e.g., HTTP and MQTT) by$\sim 10\times $, achieving a similar level of latency to the native process. Further analysis shows that SCON reduces CPU usage for SoftIRQ processing by ~26%. We also report similar improvements on the other two IoT devices. Our conclusion is that SCON is unique in significantly reducing the computing and communication overhead of container networking in IoT devices while maintaining interoperability. Furthermore, it works consistently across different types of devices, whether wired or wireless, and regardless of heavy or sporadic traffic.

Container virtualization is recognized as indispensable for realizing the vision of edge computing due to its advantages. However, OS-level virtualization suffers from a relatively low degree of security. Recently, microVM technology has emerged in response to this deficiency to provide stronger isolation and security while delivering performance comparable to the containers. In this work, we aim to gain a better understanding of microVM's suitability for edge computing in comparison with containers. We conduct extensive experiments on diverse workloads to test how microVMs compare against containers in several aspects. Through rigorous measurements and analysis, we extract several important findings. Despite having a more complex architecture than containers, microVMs perform comparably to the containers in terms of I/o performance. MicroVMs can even outperform containers in certain I/O workload types by 69%. Network I/O performance of microVMs can be 3x better than containers. We provide our findings and insights on the performance characteristics of microVMs on edge.

This article investigates how to satisfy network performance requirements that are crucial in achieving the service level objectives (SLOs) in clouds. Traditional techniques for network performance management have a limited ability to satisfy the network SLOs. Our in-depth analysis reveals that the fundamental reason comes from decoupling of the CPU scheduler and the network traffic controller as the current CPU scheduler is not aware of such network requirements but only provides a fair-share amount of CPU to all containers. Thus, the container cannot perform the amount of network processing as needed to satisfy its SLO when the CPU allocation is insufficient. In this article, we propose Autothrottle that dynamically adjusts the CPU allocation for the containers to satisfy their network SLOs. The key element of Autothrottle is a throttle algorithm that autonomously determines the amount of CPU for each container needed to satisfy the requirement. We implement Autothrottle in the Linux kernel and evaluate it with massive real-world workloads such as Apache Kafka. Our evaluation results show that Autothrottle successfully satisfies the given network SLO only with a 2% gap while the existing scheme achieves 20% less than the SLO. We further observe that Autothrottle also reduces the CPU overhead in network processing by 19%, improving the network throughput by 27% compared to the existing scheme.

It is widely believed that software routers based on commodity operating systems cannot deliver high-speed packet processing, and a number of alternative approaches (including user-space network stacks) have been proposed. This paper revisits the inefficiency of kernel-level packet processing inside modern OS-based software routers and explores whether a redesign of kernel network stacks can improve the incompetence. We present a case contrary to the belief through a redesign: Kafe-a kernel-based advanced forwarding engine that can process packets as fast as user-space network stacks. The Kafe neither adds any new API nor depends on proprietary hardware features, but the Kafe outperforms Linux by seven times and RouteBricks by three times. The current implementation of the Kafe can forward 64-byte IPv4 packets at 28.2 Gbps using eight cores running at 2.6 GHz. Our evaluation results show that the Kafe achieves similar packet forwarding performance to Intel DPDK while consuming much less CPU and memory resources.

In clouds, virtual switch (vSwitch) is in charge of packet forwarding between virtual machines (VMs). However, kernel-based vSwitches show throughput degradation for intensive packet processing; this becomes a bottleneck for the network performance of clouds. DPDK-based vSwitch (DPDK vSwitch) [1] has been developed to resolve the performance problem. Although it exhibits high throughput, DPDK vSwitch has two weak points. First, it consumes excessive memory. DPDK vSwitch uses huge page to reduce the number of memory operations, and this design causes high memory consumption even when the traffic is low. According to [2], memory determines the available number of VMs per single physical server. Thus, saving the memory decreases the capital expenditure of clouds. Second, security is another concern of the DPDK vSwitch, because its data plane is exposed to user space with the shared memory [3]. Therefore, the isolation of packets across VMs cannot be guaranteed. To overcome the excessive memory use and security concern, we propose a new kernel-level vSwitch (KVS) based on Linux. KVS do not use huge page nor bypass kernel stack. Instead, KVS applies the following key ideas to enhance the throughput.