Parallel QUIC Packet Encryption via AVX512 Vector AES

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The QUIC protocol's encryption process is inefficient due to the need for two rounds of encryption for each network packet, leading to frequent crypto context switches and suboptimal performance, especially when using existing encryption APIs that require separate calls for each packet.

Innovation Solution

Implementing batch-mode encryption using AVX512 and vector AES instructions to encrypt multiple network packets in parallel with a single API call, reducing overhead and improving performance by leveraging specific hardware capabilities.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If per-packet encryption is implemented using existing encryption APIs, then security is provided for each packet, but processing overhead increases and performance deteriorates due to frequent crypto context switches

Engineering Contradiction:
ImprovesecurityVSAvoidprocessing throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent combines multiple per-packet encryption operations into a single batch-mode encryption operation. Instead of calling the encryption API separately for each packet (which causes frequent context switches), the invention processes a batch of packets together in parallel using vector AES instructions, reducing the number of API calls and context switches while maintaining security for each individual packet.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent replaces the software-based sequential encryption mechanism with hardware-accelerated parallel encryption using AVX512 and vector AES instructions. This substitution leverages CPU hardware capabilities to perform multiple encryption operations simultaneously, eliminating the bottleneck of software-based per-packet processing and reducing crypto context switch overhead.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Reliability

If separate encryption API calls are made for each packet, then encryption is applied correctly to each packet, but the number of API calls increases leading to increased overhead

Engineering Contradiction:
Improveencryption correctnessVSAvoidAPI call overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The invention merges multiple separate encryption API calls into a single batch-mode encryption API call. By processing a batch of packets together in parallel using vector instructions, the system reduces the number of API calls from N (one per packet) to 1 (one for the entire batch), significantly reducing overhead while ensuring each packet is encrypted correctly with its own key and IV.

Inventive Principle:
Principle #5Merging (Combining)

3Productivity

If parallel encryption of multiple packets is implemented, then processing speed improves, but hardware capabilities and instruction support are required

Engineering Contradiction:
Improveencryption throughputVSAvoidhardware dependency
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent changes the operational parameters of the encryption process by utilizing specific CPU instruction sets (AVX512 and vector AES). By optimizing for these specific hardware capabilities, the system achieves significant performance improvements in parallel encryption throughput. The invention accepts hardware dependency as a trade-off for achieving high-speed parallel processing, targeting systems that have these instruction sets available.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP4492758A1Encryption acceleration for network communication packets
Publication Date: 2025.01.15 INTEL CORP
  • EP4492758A1 patent drawingFigure 1
  • EP4492758A1 patent drawingFigure 2
  • EP4492758A1 patent drawingFigure 3~4

AI summary

An apparatus includes an interface to memory, and a processor to execute one or more instructions. The instructions cause the processor to receive, via an application programming interface (API), a plurality of packets, respective packets of the plurality of packets comprising a respective header and a respective payload. Further, the instructions cause the processor to determine, by a QUIC protocol stack, to encrypt the plurality of packets in parallel. Further, the instructions cause the processor to encrypt the payloads of the plurality of packets in parallel. Further, the instructions cause the processor to encrypt the headers of the plurality of packets in parallel.