Transmit-Side Scaler Using Thread-Based Queues for Packet Flow Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In connection-oriented systems, the scheduling and queuing of outgoing network packets are challenging due to slower flows hindering faster flows, as the flow associated with an outgoing packet is not readily identifiable on the transmit side, leading to potential order retention issues and throughput reduction.
Innovation Solution
A transmit-side scaler is introduced, utilizing a token area memory to associate user applications with transmit queues and an active threads table to identify and manage process IDs, allowing for the proper queuing of packets and generation of new queues when necessary, ensuring accurate flow mapping and scheduling.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If outgoing network packets of several flows are multiplexed into a single output queue to retain packet order, then packet order is maintained, but slower flows slow down faster flows reducing overall throughput
Solution Approach 1:
The patent divides the single output queue into multiple per-flow queues by using flow identifiers (process ID, thread ID, socket ID) to route packets to appropriate queues. This segmentation allows each flow to have its own queue, eliminating the situation where slower flows block faster flows while maintaining packet order within each flow.
Solution Approach 2:
The patent introduces an intermediary mechanism (the flow identification and routing system using process ID, thread ID, and socket ID) that mediates between packet generation and transmission. This intermediary correctly identifies and routes packets to appropriate queues based on flow characteristics, enabling independent queue management for different flows.
2Device complexity
If a single output queue is used for all flows, then device complexity is reduced, but scheduling efficiency deteriorates due to flow interference
Solution Approach 1:
The patent segments the queue structure into multiple per-flow queues managed through a hash table that maps flow identifiers to queue indices. This provides fine-grained control over packet scheduling while maintaining manageable system complexity through efficient hashing and indexing mechanisms.
Solution Approach 2:
The patent implements dynamic queue management where the system can adaptively handle different flow characteristics. The hash table dynamically routes packets to appropriate queues based on their flow identifiers, allowing efficient scheduling that adapts to varying network conditions and flow patterns.
3Measurement precision
If flow identification is performed using process ID and thread ID, then packet routing accuracy is improved, but memory requirements increase due to token area and active threads table
Solution Approach 1:
The patent performs preliminary actions by pre-establishing token areas for processes and maintaining active threads tables before packet processing occurs. This allows rapid flow identification during packet transmission without requiring extensive real-time analysis, reducing the memory burden during active processing.
Solution Approach 2:
The patent makes the identification structures universal by using process ID and thread ID as key identifiers that work across different applications and flows. The token area and active threads table serve multiple purposes: flow identification, queue routing, and packet ordering, reducing the need for separate specialized data structures.
Data Source
AI summary
Embodiments of a transmit-side scaler and method for processing outgoing information packets using thread-based queues are generally described herein. Other embodiments may be described and claimed. In some embodiments, a process ID stored in a token area may be compared with a process ID of an application that generated an outgoing information packet to obtain a transmit queue. The token area may be updated with a process ID stored in an active threads table when the process ID stored in the token area does not match the process ID of the application.