Window-Based Congestion Control via Sender Notification Packets
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCEv2) protocol lacks effective congestion control mechanisms, particularly in handling delayed Congestion Notification Packets (CNPs), which leads to inefficient data transfer and increased latency due to the inability to accurately determine successfully received packets during read operations.
Innovation Solution
The implementation of a rate control scheme using Sender Notification Packets (SNPs) that include byte count and timestamp information, allowing the sender to adjust the transmission rate based on received acknowledgement packets, thereby improving congestion management and network utilization.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If rate control is used to limit transmission rate based on CNP packets, then congestion is reduced, but transmission efficiency decreases when CNP packets are delayed
Solution Approach 1:
The patent implements a feedback mechanism where the receiver sends Sender Notification Packets (SNPs) containing acknowledgment information back to the sender. This feedback loop allows the sender to adjust its transmission rate based on actual network conditions and receiver status, resolving the contradiction by providing reliable congestion control signals without depending on delayed CNP packets.
Solution Approach 2:
The SNP packet acts as an intermediary mechanism between the receiver and sender. Instead of relying directly on CNP packets for rate control, the system uses SNPs that carry acknowledgment information as a mediator to convey network status, enabling efficient rate adjustment without the delays associated with CNP-based control.
2Reliability
If window-based control limits outstanding packets, then congestion is bounded, but transmission rate cannot be optimized when feedback is delayed
Solution Approach 1:
The patent enhances window-based control by implementing feedback through SNPs that provide real-time acknowledgment information. This feedback enables the sender to dynamically adjust the congestion window size based on actual network conditions rather than relying solely on delayed acknowledgments, thus maintaining congestion bounds while optimizing transmission rate.
Solution Approach 2:
The patent makes the congestion control mechanism dynamic by allowing the congestion window and transmission rate to adjust continuously based on SNP feedback. This dynamic adjustment resolves the contradiction by enabling the system to maintain reliable congestion bounds while adapting transmission speed to current network conditions rather than using fixed or delayed rate limits.
3Device complexity
If Read Response packets are not acknowledged, then protocol complexity is reduced, but sender cannot determine successfully received packets
Solution Approach 1:
The patent introduces feedback by having the receiver send SNP packets that contain acknowledgment information about received packets. This feedback mechanism allows the sender to determine which packets were successfully received without requiring explicit acknowledgment of every Read Response packet, thus maintaining relatively simple protocol complexity while recovering the lost packet receipt information.
Solution Approach 2:
The patent merges the acknowledgment function into the existing SNP packet structure used for congestion control. By combining packet receipt confirmation with congestion control signaling in a single packet type, the system avoids adding separate acknowledgment protocols, thereby maintaining low protocol complexity while enabling the sender to track successfully received packets.
Data Source
AI summary
Examples described herein relate to a network interface device that includes circuitry to cause transmission of a packet following transmission of one or more data packets to a receiver, wherein the packet comprises one or more of: a count of transmitted data, a timestamp of transmission of the packet, and/or an index value to one or more of a count of transmitted data and a timestamp of transmission of the packet. In some examples, the network interface device includes circuitry to receive, from the receiver, a second packet that includes a copy of the count of transmitted data and the timestamp of transmission of the packet or the index from the packet. In some examples, the network interface device includes circuitry to perform congestion control based on the received copy of the count of transmitted data and the timestamp of transmission of the packet.