Switch Congestion Notification Generator for Data Center QoS
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In data centers, existing congestion response mechanisms, such as FECN and BECN bits, suffer from delays and inefficiencies due to the need for round-trip packet traversal and software intervention, leading to slow response times and potential packet loss, which can degrade network performance and customer satisfaction.
Innovation Solution
A system and method that utilizes a network switch and host fabric interface to provide a fast congestion response by analyzing packets at Layer 2, using a congestion notification header (CNH) to throttle oversubscribed flows directly, eliminating the need for round-trip packet traversal and software intervention, and enabling fine-grained, low-latency, hardware-accelerated congestion management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If FECN and BECN bits are used for congestion notification, then congestion can be detected and responded to, but round-trip packet traversal and software intervention cause delays and slow response times
Solution Approach 1:
The patent extracts the congestion notification function from the packet data path by introducing a separate control plane using OAM packets. This allows congestion detection and notification to occur independently from regular data traffic, eliminating the need for round-trip packet traversal through the fabric and enabling faster response times while maintaining reliable congestion detection.
Solution Approach 2:
The patent introduces an intermediary control plane mechanism using OAM (Operations, Administration, and Maintenance) packets to carry congestion notifications. This intermediary layer acts as a mediator between the congested flow and the source, providing fast congestion signaling without requiring the actual data packets to traverse the entire round-trip path, thus resolving the contradiction between reliable detection and fast response.
2Reliability
If congestion response mechanisms use round-trip packet traversal, then congestion can be identified, but packet loss and network performance degradation occur
Solution Approach 1:
The patent extracts the congestion identification function from the data plane by implementing it in the control plane using OAM packets. This separation allows congestion to be identified accurately through dedicated control signaling without requiring data packets to complete full round-trip traversals, thereby preventing packet loss and maintaining high network performance while preserving accurate congestion identification.
Solution Approach 2:
The patent implements preliminary congestion detection by monitoring flow bandwidth consumption against QoS policies before significant packet loss occurs. The control plane proactively identifies congestion conditions and sends notifications to throttle flows, preventing the need for reactive measures that would involve lost packets and performance degradation.
3Reliability
If software intervention is used for congestion management, then congestion control can be implemented, but processing delays and inefficiencies occur
Solution Approach 1:
The patent replaces the mechanical software-based congestion management system with a more efficient control plane mechanism using OAM packets and hardware-assisted flow identification. This substitution eliminates software processing delays by implementing congestion detection and notification in a streamlined control plane, maintaining reliable congestion control while significantly improving processing efficiency.
4Reliability
If fine-grained flow throttling is implemented, then QoS requirements can be met, but complexity in identifying and managing flows increases
Solution Approach 1:
The patent uses the control plane as an intermediary to simplify fine-grained flow management. The control plane receives congestion notifications, identifies the affected flows using flow identifiers in the OAM packets, and sends targeted throttle commands to specific source devices. This intermediary approach enables precise QoS compliance through fine-grained throttling while keeping the implementation complexity manageable by centralizing flow identification logic in the control plane rather than distributing it across multiple data plane components.
Data Source
AI summary
There is included in one example a switch, including: an ingress port to receive data from a source host; a first egress port to send data to a destination host; a second egress port to send data to the source host; and a congestion notification generator (CNG) including: a congestion detector to compute bandwidth consumption of a flow associated with a packet received on the ingress port and assigned to the first egress port, and determine based on the computed bandwidth consumption that the flow is congested; a flow extractor to extract a flow identifier of the flow from the packet; a throttle calculator to calculate a quantitative flow throttle value for the flow; and a header builder to build a congestion notification packet to instruct the source host to throttle the flow.