Hardware Acceleration for Container Migration on Resource-Constrained Platforms

Abstract

The computing capabilities of client devices are continuously increasing; at the same time, demands for ultra-low latency (ULL) services are increasing. These ULL services can be provided by migrating some micro-service container computations from the cloud and multi-access edge computing (MEC) to the client devices. The migration of a container image requires compression and decompression, which are computationally demanding. We quantitatively examine the hardware acceleration of container image compression and decompression on a client device. Specifically, we compare the Intel ® Quick Assist Technology (QAT) hardware acceleration with software compression/decompression. For scenarios with a local container image registry (i.e., without network bandwidth constraints), we find that QAT speeds up compression by a factor of over 7 compared to the single-core GZIP software and reduces the CPU core utilization by over 15% for large container images. These QAT benefits come at the expense of Input/Output (IO) memory access bitrates of up to 900 Mbyte/s (while the software compression/decompression does not require IO memory access). For scenarios with a remote container image registry, we find that the container push (compression) time savings increase with the network bandwidth, while the container pull (decompression) time savings level out for moderately high network bandwidths and slightly decrease for a very high network bandwidth. Furthermore, QAT acceleration achieves substantial power consumption reductions for container push compression for low to moderately high network bandwidths. Our evaluation results give reference performance benchmarks of the achievable latencies for container image instantiation and migration with and without hardware acceleration of the compression and decompression of container images.

Systematic Approach for State-of-the-Art Architectures and System-on-Chip Selection for Heterogeneous IoT Applications

“…Linguaglossa et al has proposed the extensive overview of the hardware architectures for network function virtualization (NFV) to provide abstractions for accessing components and physical resources into the ecosystem [25]. P. Shantharama et al have demonstrated the Intel QAT hardware acceleration that performs image compression and decompression and achieved high network bandwidth [26][27]. The work in [27] surveyed the emerging hardware platforms for executing softwarized network functions.…”

“…P. Shantharama et al has surveyed the emerging hardware platforms for executing softwarized network functions. There are few works in [25][26][27] that provides a comprehensive survey of hardware accelerated platforms associated for architectural enhancement by reducing the core utilization and expanding the ISA and cache memory access. Table I shows the works carried out in various literature.…”

“…This Paper Kansakar et.al [22] Tosiron et.al [23] Kansakar et.al [24] Tosiron et.al [25] Mike et.al [26]…”

FAST: Flexible and Low-Latency State Transfer in Mobile Edge Computing

“…This facilitates reducing the complexity of the search process. Notably, we set an aspiration criterion: if the aspiration criterion is met, then the move is released (removed) from the Tabu list (Lines [16][17][18]. The aspiration criterion is defined for the case when a better solution than the current best solution is found.…”

“…In order to accomplish the service migration, the VM and container migration schemes transfer: (i) the application states, i.e., the state information that the application itself generated (mainly the variable values of the counters and timers and other intermediate data that characterize the current functioning status of the application at a given time), and (ii) the VM or container states, i.e., the state information that the VM or container generated (e.g., the states of the operating system). The VM or container state information is typically an enormous amount of data, resulting in substantial delays for the MEC service migration with VM and container migration schemes [15], [16]. Furthermore, these VM and container migration schemes are not suitable for novel MEC use cases, such as vehicle platooning and tactile internet, which may require manipulations (e.g., splitting or merging) of the application states (e.g., when a truck leaves or rejoins a vehicle platoon).…”