A programmable switch-based network congestion signal conversion method and system

Abstract

This invention discloses a network congestion signal conversion method and system based on a programmable switch. In the outbound direction, each flow is identified by recognizing the ECN (Entry-Level Congestion) identifier in the outbound packets, and the congestion status of the corresponding flow is determined based on the ECN identifier. In the return direction, timestamp-based RTT (Round-Trip Time) measurement related packets are identified, and when the congestion status is valid, the timestamp field used for RTT calculation is rewritten in a controlled manner, allowing the sending end to observe an increased equivalent RTT. Therefore, the congestion control logic can be used solely to reduce or suppress the rate of increase in congestion. This invention converts ECN-type congestion information from the network side into RTT-type congestion information that can be directly used by the end side. Transparent forwarding is maintained when the switch is not congested, and unified feedback is issued in advance when the switch becomes congested or is about to become congested. This reduces the sending end's dependence on ECN / CNP processing logic and reduces the risk of conflicts caused by the coexistence of multiple congestion signals.

Description

Technical Field

[0001] This invention relates to the field of electronic information and data center network technology, and in particular to a method and system for network congestion signal conversion based on a programmable switch. Background Technology

[0002] Congestion control is a key mechanism for ensuring the stability of Remote Direct Memory Access (RDMA) network transmissions. Industry-standard congestion control signals include those based on Round Trip Time (RTT), those based on Explicit Congestion Notification (ECN), and those based on In-Band Network Telemetry (INT). To improve congestion control accuracy, the industry commonly adopts a combined ECN and RTT deployment scheme.

[0003] However, due to the inherent differences in their triggering mechanisms, feedback paths, and feedback granularity, the joint deployment of ECN and RTT results in the sending end needing to maintain multiple sets of processing logic, significantly increasing the CPU and network card load. Furthermore, the inconsistent congestion judgment standards for different signals can easily lead to speed adjustment conflicts, which can damage network stability. In wide-area and other non-full ECN support scenarios, compatibility is poor, and deployment and maintenance costs are high.

[0004] Existing improvements to ECN and RTT joint deployment solutions, such as adopting signal priority scheduling or merging some logic through software optimization, have not fundamentally reduced the amount of logic maintenance required at the sending end, nor have they improved congestion response delays or fully utilized the transmission characteristics of return packets. Summary of the Invention

[0005] To address the shortcomings of existing ECN and RTT joint deployment schemes, this invention provides a network congestion signal conversion method and system based on a programmable switch. Through a congestion signal conversion mechanism implemented on the network side, the sending end can achieve timely and consistent perception of network congestion without adding end-side processing logic.

[0006] On the one hand, a network congestion signal conversion method based on a programmable switch is provided, including: Real-time capture of outbound data packets in the data stream transmitted in the RDMA network; Identify the ECN identifier information in the outbound packets and determine the congestion status of the corresponding flow based on the ECN identifier information; When a flow is determined to be in a congested state, the most recent return message of the flow to the programmable switch is obtained, the RTT timestamp information in the return message is extracted, and the RTT measurement value is rewritten. The rewritten RTT value is sent to the sending end, where the RTT detection logic identifies it as a congestion signal and responds accordingly.

[0007] Furthermore, based on the ECN identification information, the following status information is maintained for the corresponding flow: FlowKey, window packet counter. ECN-tagged message counter The congestion flag (cong_flag), the congestion level flag (Cong_Level), and the corresponding RTT rewrite index are also included.

[0008] Furthermore, the determination of congestion events includes: directly detecting the CE flag in the outbound packet header; if the CE bit in the ECN field is set, then the packet is determined to correspond to an ECN congestion event.

[0009] Furthermore, the determination of congestion events also includes: the programmable switch determines whether the outbound packet should be regarded as a congestion packet based on the local queue length, queuing delay, buffer occupancy status, or preset ECN marking policy.

[0010] Furthermore, based on the most recent return packet arriving at the programmable switch, the RTT timestamp information in the return packet is identified, and the RTT measurement value is rewritten, including: The programmable switch identifies return packets and determines whether they are RTT measurement-related packets; if not, it forwards them directly; if they are, it parses the FlowKey. Read the congestion status Cong_Level of the FlowKey. If Cong_Level is 0, forward directly; if Cong_Level is not 0, calculate the rewrite increment ΔRTT, which is obtained by the ECN-RTT congestion signal conversion calculation method.

[0011] Furthermore, the ECN-RTT congestion signal conversion calculation method includes: The number of data packets forwarded within the observation window of the programmable switch and the number of packets with ECN tags ,calculate ; Programmable switches calculate using table lookup functions .

[0012] On the other hand, a network congestion signal conversion system based on a programmable switch is provided, including: Message capture module: Captures all data packets in the data stream transmitted in the RDMA network in real time, including outbound and return packets; Congestion status determination module: Identifies ECN identification information in outbound packets and determines the congestion status of the corresponding flow based on the ECN identification information; Congestion signal conversion module: When a flow is determined to be in a congested state, the RTT timestamp information in the most recent return message to the programmable switch is identified based on the return message of the flow, and the measured value of the RTT timestamp information is rewritten. Congestion signal identification module: The rewritten return message is sent to the sender, and the sender's RTT detection logic identifies it as a congestion signal and responds accordingly.

[0013] Furthermore, an electronic device is also provided, including: Memory, used for non-transitory storage of computer-readable instructions; and Processor, for executing the computer-readable instructions, When the computer-readable instructions are executed by the processor, they perform the method described in the first aspect above.

[0014] In another aspect, a storage medium is also provided for non-transitory storage of computer-readable instructions, wherein when the non-transitory computer-readable instructions are executed by a computer, the method described in the first aspect is performed.

[0015] In another aspect, a computer program product is also provided, including a computer program that, when run on one or more processors, is used to implement the method described in the first aspect above.

[0016] The above technical solution has the following advantages or beneficial effects: This invention proposes a congestion signal conversion method and system based on a programmable switch. The programmable switch maintains the congestion status for each flow. When an ECN congestion event is detected for a flow on the outbound path, the timestamp field in the RTT measurement-related message for that flow is rewritten in a controlled manner on the return path. This allows the sender to reduce or suppress the rate of increase in advance based solely on the RTT congestion control logic, reducing the ECN processing burden on the sender and lowering the risk of multi-signal collisions. This invention converts ECN-type congestion information from the network side into RTT-type congestion information that can be directly used by the end side. It maintains transparent forwarding when the switch is not congested and issues unified feedback in advance when the switch is congested or about to become congested. This reduces the sender's dependence on ECN / CNP processing logic, reduces the risk of collisions caused by the coexistence of multiple congestion signals, and can adapt to deployment scenarios where intermediate networks do not fully support ECN. Attached Figure Description

[0017] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0018] Figure 1This is a flowchart of a network congestion signal conversion method based on a programmable switch as described in Embodiment 1; Figure 2 This is a schematic diagram illustrating an application scenario of the network congestion signal conversion method based on a programmable switch as described in Embodiment 1. Detailed Implementation

[0019] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0020] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments of the invention. The terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] In this embodiment of the invention, "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of this invention, "multiple" refers to two or more.

[0022] Furthermore, to facilitate a clear description of the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0023] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0024] All data acquisition in this embodiment is carried out in accordance with laws and regulations and with user consent, and the data is used legally.

[0025] The key objects and terms required for definition in this invention include: A flow is a communication entity that can be identified and maintained in an independent state on the switch side. It can be identified in one of the following ways: 1) A five-tuple including source IP, destination IP, source port, destination port, and protocol number. 2) RDMA / RoCE related fields: such as QPN, PSN, UDP port, and IP header fields. This disclosure uses a FlowKey to uniquely identify a flow, which can be obtained by hashing the above-mentioned identification fields.

[0026] Outbound and Inbound Directions: The outbound direction refers to the direction of data or requests from the sender to the receiver. The inbound direction refers to the direction of ACK, RTT response messages, or other feedback carrying timestamps from the receiver back to the sender.

[0027] ECN congestion event: The switch detects that the CE flag in the ECN field of the outbound packet is set. In optional implementations, the ECN congestion event also includes the case where the switch performs ECN marking on the outbound packet based on local port queue length, queuing delay, buffer occupancy, or marking probability policy.

[0028] RTT Measurement Related Messages: Message types that can be used by the sender to calculate RTT, and must contain at least timestamp information. Typical forms include: 1) Independent RTT probe messages and response messages, with the response message carrying both send and receive timestamps. 2) ACK messages carrying a timestamp field, with the sender calculating RTT based on the send and receive timestamps. This disclosure does not limit the specific message format, as long as the switch can recognize it and perform controlled rewriting of the timestamp field used for RTT calculation. Furthermore, in some implementations, RTT measurement related messages may carry a timestamp field written by the sender and echoed by the receiver, thus making RTT calculation dependent only on the sender's local clock domain, without requiring clock synchronization between the sender and receiver.

[0029] Timestamp field: A set of fields used for RTT calculation, abstracted as... and . This represents a timestamp written by the sending end or used to characterize the time of transmission. This represents the timestamp written by the receiver or used to characterize the time of reception. RTT calculation can typically be expressed as... Or its equivalent form.

[0030] Furthermore, this disclosure does not strictly require the sending and receiving ends to perform time synchronization. If the sending and receiving ends do not perform time synchronization, the sending end can use adjacent RTT measurement messages to calculate the offset between two consecutive RTT measurements for congestion measurement.

[0031] Example 1 Remote Direct Memory Access (RDMA) technology boasts advantages such as low latency, high bandwidth, and low CPU utilization, making it a core network technology for high-speed data transmission between servers within data centers. It has been widely applied in fields such as artificial intelligence training and inference, distributed storage, and high-performance computing. In RDMA networks, congestion control is a crucial mechanism for ensuring network transmission stability, preventing link overruns, and improving transmission efficiency. Currently, the mainstream congestion control signals in the industry are mainly divided into three categories: congestion control signals based on Round-Trip Time (RTT), congestion control signals based on Explicit Congestion Notification (ECN), and congestion control signals based on In-band Network Telemetry (INT).

[0032] RTT-based congestion control signals determine network congestion by detecting the round-trip time (RTT) of data packets from the sender to the receiver and back to the receiver. When the RTT measurement increases, network congestion is identified, and the sender reduces the transmission rate accordingly. ECN-based congestion control signals are implemented by network switches detecting link congestion. When congestion occurs, the switch marks the data packet header with an ECN identifier. The receiver recognizes this identifier and sends a Congestion Notification Packet (CNP) to the sender. Upon receiving the CNP, the sender reduces the transmission rate. INT-based congestion control signals embed real-time network link status information, such as link utilization and queue length, into service data packets. This allows the sender to dynamically adjust the transmission rate based on this real-time information, making it suitable for applications requiring high accuracy in congestion detection.

[0033] To further improve congestion control accuracy, RDMA networks are increasingly adopting a combined deployment of ECN and RTT congestion control signals to achieve joint congestion control. For example, in high-speed data center networks, RDMA network cards support hardware timestamps and offer open programmable congestion control interfaces, allowing users to customize and develop high-speed congestion control algorithms. Using a combination of RTT and ECN for congestion control yields better control performance than a single congestion control signal. In wide-area RDMA transmission scenarios, because data center network switches support ECN but the wide-area core network does not, the transmitting end typically employs a congestion control strategy that primarily uses RTT measurement and secondarily uses ECN measurement. However, ECN and RTT have inherent differences in triggering mechanisms, feedback paths, and feedback granularity, requiring additional coordination mechanisms at the end to avoid congestion control conflicts when using both signals together.

[0034] Analysis of the existing deployment architecture with multiple congestion control signals coexisting, combined with practical application scenarios, reveals the following core technical flaws: First, the increased load on the transmitting end leads to a decrease in data transmission efficiency. Because the transmitting end needs to simultaneously maintain processing logic and rate adjustment logic based on multiple congestion control signals such as RTT and ECN, and each set of logic requires independent hardware resources and software processes, the resource utilization of the transmitting end's CPU and network interface card (NIC) increases significantly. This not only increases the hardware deployment cost of the transmitting end but also indirectly weakens the low latency and high bandwidth advantages of RDMA technology. These problems are particularly prominent in high-concurrency, high-data-volume transmission scenarios. Furthermore, on some hardware platforms that only open RTT-type programmable congestion control interfaces and not ECN event interfaces, the deployment method of multiple signals coexisting will further increase the technical implementation threshold.

[0035] Secondly, conflicts can easily occur between different congestion control signals, leading to incorrect rate adjustment operations by the sender and disrupting network transmission stability. Because ECN and RTT signals have different congestion judgment criteria and response timings, inconsistent congestion states may occur at the same time. For example, when a switch detects minor link congestion, it marks the data packet with an ECN and notifies the sender to reduce the rate. However, if the RTT value detected by the sender does not change significantly, the congestion control logic based on RTT will determine that the network is not congested, thus maintaining or even increasing the transmission rate. Conversely, when the RTT value increases, indicating network congestion, the CNP may not have been generated or has not reached the sender, causing a conflict in the sender's rate adjustment logic. This results in incorrect rate adjustment operations, exacerbating network congestion or wasting link bandwidth, severely impacting the transmission stability and reliability of data center RDMA networks. Furthermore, these conflicts may also manifest as repeated rate reductions at the endpoint during the same congestion phase, excessively large cumulative rate reductions, or failure to promptly increase the transmission rate during congestion recovery.

[0036] Furthermore, joint congestion control based on multiple types of congestion control signals typically only achieves joint performance gains and cannot effectively reduce congestion control loop delay. The theoretical minimum response delay of joint congestion control based on multiple signals remains within the (1 / 2 RTT, RTT) range, failing to overcome the closed-loop control delay bottleneck. When sudden network congestion occurs, the sending end cannot receive congestion notifications in a timely manner, easily leading to congestion packet loss. In addition, existing technical solutions lack effective solutions for application scenarios where intermediate networks do not fully support ECN; for example, in wide area transmission networks, because the wide area core network does not support ECN features, the sending end usually directly abandons ECN congestion control, failing to obtain the performance gains of joint congestion control.

[0037] Finally, deployment and maintenance costs are high, and equipment compatibility is poor. Deploying multiple congestion control signals requires complex configuration and debugging of the sending, receiving, and network switches to ensure interoperability, resulting in high configuration complexity, high compatibility requirements, and high deployment costs. Furthermore, different vendors' equipment shows varying levels of support for different congestion control signals, easily leading to signal identification errors and abnormal responses, significantly increasing overall network maintenance and upgrade costs. Especially in heterogeneous data center environments, differences in support for ECN, timestamps, and feedback message formats among different network interface cards (NICs) and switches further amplify these maintenance complexities.

[0038] To address the problems associated with using multiple congestion control signals, several improvement schemes have been proposed in the industry, but none have fundamentally solved the issues. Some schemes attempt to simplify the rate adjustment logic at the transmitter by employing priority sorting or improved scheduling methods, setting a certain type of congestion control signal as the highest priority, such as prioritizing the ECN signal. When multiple signals conflict, only the highest priority signal is responded to. However, these schemes fail to address the resource load issue of the transmitter maintaining multiple sets of congestion control logic simultaneously, and the static setting of priorities is prone to congestion judgment errors, which may still lead to the transmitter executing incorrect rate adjustment operations. Furthermore, these schemes fail to effectively improve congestion response latency and do not fully utilize the packet-by-packet response and continuous transmission characteristics of the Return RTT Measurement Announcement (RTT) or Congestion Announcement (CNP) messages.

[0039] Some solutions attempt to merge some processing logic through software optimization or to improve control performance by adopting joint congestion control strategies. However, none of these solutions have fundamentally reduced the amount of congestion control logic that the transmitter needs to maintain. The technical problem of excessive load on hardware resources such as the transmitter's CPU and NIC has not been effectively solved.

[0040] Based on this, the present invention provides a network congestion signal conversion method based on a programmable switch. It deploys RTT-based congestion control logic and rate adjustment logic at the transmitting end to ensure that the transmitting end can correctly parse the timestamp information in the return RTT measurement announcement. The programmable switch is responsible for congestion signal conversion between ECN and RTT, while the receiving end is responsible for data reception and response feedback. Through a congestion signal conversion mechanism implemented on the network side, this invention enables the transmitting end to perceive network congestion status earlier and more consistently and execute corresponding congestion control operations without increasing the complexity of the processing logic on the receiving end.

[0041] This embodiment provides a network congestion signal conversion method based on a programmable switch, such as... Figure 1 As shown, it includes: Capture all data packets in the data stream transmitted in the RDMA network in real time, including outbound and inbound packets; Identify the ECN identifier information in the outbound packets and determine the congestion status of the corresponding flow based on the ECN identifier information; When a flow is determined to be in a congested state, the RTT timestamp information in the most recent return message that the flow arrived at the programmable switch is identified, and the RTT measurement value is rewritten. The rewritten RTT value is sent to the sending end, where the RTT detection logic identifies it as a congestion signal and responds accordingly.

[0042] This embodiment provides a network congestion signal conversion method based on a programmable switch, the specific steps of which include: S1: Real-time capture of all data packets in the data stream transmitted in the RDMA network, including outbound and inbound packets.

[0043] This embodiment captures all data packets of the data stream transmitted in the RDMA network through a programmable switch, including outbound packets sent from the sender to the receiver and return packets sent from the receiver to the sender, wherein the return packets are continuous RTT measurement response packets.

[0044] S2: Identify the ECN identifier information in the outbound packet and determine the congestion status of the corresponding flow based on the ECN identifier information, specifically including: In this embodiment, the determination of congestion events includes two methods: the first method is to directly read the ECN identification information of the outbound packet through the programmable switch, identify the CE field in the ECN identification information, and determine the congestion event if the CE field in the ECN identification information is set.

[0045] The second method is for the switch to determine whether the packet should be considered a congestion event based on the local queue length, queuing delay, buffer occupancy status, or a preset ECN marking policy.

[0046] This embodiment maintains the following status information for the corresponding flow based on the ECN identifier information: FlowKey, window packet counter. ECN-tagged message counter The system includes the congestion flag (cong_flag), the congestion level flag (Cong_Level), and the corresponding RTT rewrite index. P and Pe are used to approximate the ECN congestion intensity within an observation window, while Cong_Level indicates whether the current flow is in a congestion-free, slightly congested, or severely congested state.

[0047] If a congestion event is identified, the outbound packet is recorded as a packet with an ECN tag, and Pe is incremented by 1. Regardless of whether it has an ECN tag, P is incremented by 1 for each outbound packet received. Based on the identified ECN tag information, the congestion status of the corresponding flow is updated to non-congested, slightly congested, or severely congested.

[0048] The programmable switch receives outbound packets and parses the FlowKey; if the FlowKey does not exist, it registers a FlowKey and sets Cong_Level to 0. The FlowKey is constructed using a combination of a 5-tuple and an RDMA queue identifier. Preferably, the FlowKey can be obtained by combining the source IP address, destination IP address, source UDP port, destination UDP port, and QPN field.

[0049] In this embodiment, a fixed-packet-count window is used for the observation window, preferably consisting of 8 outbound packets. The advantage of using a fixed-packet-count window is that it eliminates the need for complex division operations in the switch, facilitating the calculation of the equivalent RTT increment directly in the data plane through integer counting and table lookup. Specifically, for each FlowKey, when the switch receives a packet in the outbound direction, it first reads the P and Pe of that flow. If the flow is appearing for the first time, a corresponding status entry for the FlowKey is created, and P, Pe, and Cong_Level are initialized to 0.

[0050] In this embodiment, after the switch completes the congestion statistics for the current outbound packets, to avoid the sending end continuing to receive the original ECN signal and triggering additional ECN processing logic, the switch resets the ECN field in the outbound packet to 0 before forwarding it. In this way, the end-side mainly adjusts the speed based on the subsequently converted RTT congestion signal, which helps reduce the risk of conflict when both RTT and ECN feedback exist simultaneously.

[0051] S3: When a flow is determined to be in a congested state, the RTT timestamp information in the return message that most recently arrived at the programmable switch is extracted and the RTT measurement value is rewritten. For return packets, the switch swaps the source address and destination address, and the source port and destination port to generate a reverse matching key, thereby associating it with the corresponding outbound flow. The switch can consistently identify outbound and return packets of the same RDMA service flow.

[0052] For flows in a "non-congested" state, their return packets are not processed in any way and are forwarded directly.

[0053] For flows in a "slightly congested" or "severely congested" state, the send or receive timestamp is identified based on the most recently arrived return message. Following a preset rewriting rule, the send or receive timestamp is modified to generate a rewritten timestamp. This ensures that the rewritten RTT value can be recognized as a congestion signal by the sender's RTT detection logic. Specifically, this includes: S31: The programmable switch identifies return packets and determines whether the return packet is related to RTT measurement. If it is not, it forwards the packet directly; if it is, it parses the FlowKey.

[0054] S32: Read the congestion status Cong_Level of the FlowKey. If Cong_Level is 0, forward directly; if Cong_Level is not 0, calculate the rewrite increment ΔRTT. The determination method can be any of the following: 1) Fixed increment: =constant .

[0055] 2) Tier Mapping: ,in, A linear mapping from 1 to N corresponds to 1% to 100%.

[0056] 3) Probability mapping: ,in, The maximum ECN labeling probability configured for the switch.

[0057] 4) Obtained according to the ECN-RTT congestion signal conversion calculation method described in this embodiment.

[0058] The constant D can be manually configured by the administrator or calculated based on the upper bound of the average expected forwarding delay per port of the switch. .

[0059] If Cong_Level is not 0, update the FlowKey state by setting Cong_Level to Cong_Level+1. If Cong_Level+1>N, set Cong_Level to N, where N is the set threshold. If no congestion event occurs, update the FlowKey state by setting Cong_Level to Cong_Level-1. If Cong_Level-1<0, set Cong_Level to 0.

[0060] To ensure that the sending end, upon receiving the rewritten RTT measurement-related message, exhibits a deceleration behavior equivalent to the ECN congestion intensity, this embodiment proposes an ECN-RTT congestion signal conversion calculation method, enabling the programmable switch to reasonably rewrite the timestamp field. This method can be described as follows: assuming the switch detects an ECN congestion intensity of 'e' for a flow within an observation window, the switch injects an equivalent RTT increment ΔRTT into the return message for that flow. This ensures that the rate update triggered by the sending end based on the Timely congestion control algorithm within that window is approximately equal to the rate update that the ECN feedback should have triggered. The ECN-RTT congestion signal conversion calculation method described in this embodiment specifically includes the following steps: S321: Number of data packets forwarded within the switch's statistical observation window and the number of packets with ECN tags ,calculate .

[0061] S322: The switch calculates using a lookup function. .

[0062] The lookup table function can be designed as shown in Table 1 below.

[0063] Table 1 Lookup Functions

[0064] In this embodiment, when the flow P reaches a preset window size of 8, the switch calculates the corresponding equivalent RTT rewrite amount ΔRTT based on the ECN congestion intensity within that window. Theoretically, the ECN congestion intensity e = Pe / P. Since P is fixed at 8 in this embodiment, no division is required; a direct table lookup based on the value of Pe is sufficient. Preferably, the following table lookup rules are used: When Pe is 0 or 1, the corresponding e falls into the interval [0, 0.2), so let ΔRTT = 0; When Pe is 2 or 3, the corresponding e falls into the interval [0.2, 0.4), let ΔRTT = D / 8; When Pe is 4, the corresponding e falls within the interval [0.4, 0.6), so let ΔRTT = D / 4; When Pe is 5 or 6, the corresponding e falls into the interval [0.6, 0.8), so let ΔRTT = D / 2; When Pe is 7 or 8, the corresponding e falls into the interval [0.8,1], so let ΔRTT=D.

[0065] Wherein, D is the base time increment, used to characterize the strength of a standard congestion feedback injected by the switch to the transmitter. In this embodiment, D is pre-configured by the switch control plane, preferably calculated based on the switch port rate and the upper bound of the expected buffer occupancy; it can also be directly set by the administrator according to the specific network size, link rate, and target congestion sensitivity. For an exemplary deployment of a 100Gbps port, D can be taken as 2μs.

[0066] In this embodiment, after completing the table lookup, the switch saves the obtained ΔRTT as the current congestion feedback value for the flow and updates Cong_Level synchronously. Preferably, Cong_Level can be set to five levels: 0, 1, 2, 3, and 4, corresponding to ΔRTT values ​​of 0, D / 8, D / 4, D / 2, and D, respectively. Subsequently, the switch clears the P and Pe values ​​for the flow to zero and begins counting the next observation window. Using this method, the switch only needs to maintain a small-width integer counter and a small number of table lookup entries, making it suitable for deployment on P4 switches.

[0067] S33: Perform controlled rewriting of the RTT timestamp field in the return message, rewriting the sending timestamp. Or rewrite the received timestamp .

[0068] In this embodiment, it is preferable to rewrite the receive timestamp Tr, that is, rewrite the receive timestamp in the return message as Tr' = Tr + ΔRTT. The advantage of this method is that the implementation logic is relatively simple and it is less prone to the problem of underflow of the sending timestamp. In other embodiments, the sending timestamp can also be rewritten. If the message protocol requires verification and updates, the switch synchronously updates the corresponding verification field after completing the timestamp field rewriting.

[0069] S4: The rewritten return message is sent to the sender, where the sender's RTT detection logic identifies it as a congestion signal and responds accordingly.

[0070] In this embodiment, the sending end processes the rewritten return packets according to the existing RTT congestion control logic. Since the switch artificially increases the equivalent RTT in the return packets when congestion occurs, the sending end will observe the RTT increase when calculating the RTT, thereby triggering the Timely algorithm to decelerate or suppress the rate of increase. In this way, the sending end does not need to additionally process ECN events or CNP packets, and can respond to congestion using the existing RTT control logic.

[0071] The operation of this embodiment will be described below with reference to a specific working process, such as... Figure 2 As shown. Assume that the sending end continuously sends outgoing packets of a certain RDMA service flow to the receiving end, the programmable switch port rate is 100Gbps and supports the congestion signal conversion function described in this embodiment, the base time increment D is configured to 2us, and the observation window size is 8 outgoing packets.

[0072] Within the first observation window, the programmable switch received a total of 8 outbound packets for this flow. Five of these packets already carried the CE tag or were determined by the switch to require ECN tagging, therefore P=8 and Pe=5. According to the lookup table rules mentioned above, Pe=5 corresponds to e being in the interval [0.6, 0.8), so let ΔRTT=D / 2=1us, and update Cong_Level to the corresponding level.

[0073] Subsequently, the receiving end returns an ACK packet. The programmable switch recognizes that the ACK packet carries a timestamp field in the return direction, finds that the current ΔRTT of the flow is 1us, and then rewrites Tr in the ACK packet to Tr+1us before forwarding it to the sending end.

[0074] After receiving the ACK packet, the sending end calculates an RTT value that increases by approximately 1µs compared to the unmodified value, thus determining that network congestion has occurred and initiating a rate reduction. It is important to note that the programmable switch modifies the timestamp by adding an extra ΔRTT to the normal RTT, thereby achieving congestion notification.

[0075] This invention is applicable to large data center networks or wide area transmission networks that support RDMA (Remote Direct Memory Access) transmission, and is especially suitable for RDMA network scenarios that use ECN and RTT as congestion control signals to realize the conversion of congestion signals.

[0076] Example 2 This embodiment provides a network congestion signal conversion system based on a programmable switch, including: Message capture module: Captures all data packets in the data stream transmitted in the RDMA network in real time, including outbound and return packets; Congestion status determination module: Identifies ECN identification information in outbound packets and determines the congestion status of the corresponding flow based on the ECN identification information; Congestion signal conversion module: When a flow is determined to be in a congested state, the RTT timestamp information in the most recent return message to the programmable switch is identified based on the return message of the flow, and the measured value of the RTT timestamp information is rewritten. Congestion signal identification module: The rewritten return message is sent to the sender, and the sender's RTT detection logic identifies it as a congestion signal and responds accordingly.

[0077] The descriptions of each embodiment in the above embodiments have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0078] The proposed system can be implemented in other ways. For example, the system embodiments described above are merely illustrative, and the division of modules described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0079] Example 3 This embodiment also provides an electronic device, including: one or more processors, one or more memories, and one or more computer programs; wherein, the processor is connected to the memory, and the one or more computer programs are stored in the memory. When the electronic device is running, the processor executes the one or more computer programs stored in the memory to cause the electronic device to perform the method described in Embodiment 1.

[0080] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0081] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0082] In the implementation process, each step of the above method can be completed by the integrated logic circuits in the processor hardware or by software instructions.

[0083] The method in Embodiment 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0084] Those skilled in the art will recognize that the units and algorithm steps described in connection with the various examples of this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0085] Example 4 This embodiment also provides a storage medium for storing computer instructions, which, when executed by a processor, complete the method described in Embodiment 1.

[0086] Example 5 This embodiment also provides a computer program product, including a computer program that, when run on one or more processors, implements the method described in Embodiment 1.

[0087] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for converting network congestion signals based on a programmable switch, characterized in that, include: Capture all data packets in the data stream transmitted in the RDMA network in real time, including outbound and inbound packets; Identify the ECN identifier information in the outbound packets and determine the congestion status of the corresponding flow based on the ECN identifier information; When a flow is determined to be in a congested state, the RTT timestamp information in the most recent return message that the flow arrived at the programmable switch is identified, and the RTT measurement value is rewritten. The rewritten return message is sent to the sender, where the sender's RTT detection logic identifies it as a congestion signal and responds accordingly.

2. The network congestion signal conversion method based on a programmable switch according to claim 1, characterized in that, Based on the ECN identifier information, maintain the following status information for the corresponding flow: FlowKey, Window Packet Counter. ECN-tagged message counter The congestion flag (cong_flag), the congestion level flag (Cong_Level), and the corresponding RTT rewrite index are also included.

3. The network congestion signal conversion method based on a programmable switch according to claim 1, characterized in that, The determination of congestion events includes: The CE flag in the outbound packet header is directly checked. If the CE bit in the ECN field is set, the packet is determined to correspond to an ECN congestion event.

4. The network congestion signal conversion method based on a programmable switch according to claim 1, characterized in that, The determination of congestion events also includes: The programmable switch can determine whether an outbound packet should be considered a congestion event based on local queue length, queuing delay, buffer occupancy status, or a preset ECN marking policy.

5. The network congestion signal conversion method based on a programmable switch according to claim 1, characterized in that, Based on the most recent return packet arriving at the programmable switch, identify the RTT timestamp information in the return packet and rewrite the RTT measurement value, including: The programmable switch identifies return packets and determines whether the return packet is related to RTT measurement; if it is not, it forwards it directly; if it is, it parses the FlowKey. Read the congestion status Cong_Level of the FlowKey. If Cong_Level is 0, forward directly; if Cong_Level is not 0, calculate the rewrite increment ΔRTT, which is obtained by the ECN-RTT congestion signal conversion calculation method.

6. The network congestion signal conversion method based on a programmable switch according to claim 5, characterized in that, The ECN-RTT congestion signal conversion calculation method includes: The number of data packets forwarded within the observation window of the programmable switch and the number of packets with ECN tags ,calculate ; Programmable switches calculate using lookup table functions. .

7. A network congestion signal conversion system based on a programmable switch, characterized in that, include: Message capture module: Captures all data packets in the data stream transmitted in the RDMA network in real time, including outbound and return packets; Congestion status determination module: Identifies ECN identification information in outbound packets and determines the congestion status of the corresponding flow based on the ECN identification information; Congestion signal conversion module: When a flow is determined to be in a congested state, the RTT timestamp information in the most recent return message to the programmable switch is identified based on the return message of the flow, and the measured value of the RTT timestamp information is rewritten. Congestion signal identification module: The rewritten return message is sent to the sender, and the sender's RTT detection logic identifies it as a congestion signal and responds accordingly.

8. An electronic device, characterized in that, include: Memory is used to store computer-readable instructions in a non-transitory manner. as well as Processor, for executing the computer-readable instructions, When the computer-readable instructions are executed by the processor, they perform a network congestion signal conversion method based on a programmable switch as described in any one of claims 1-6.

9. A storage medium, characterized in that, Non-transitory storage computer-readable instructions, wherein when the non-transitory computer-readable instructions are executed by a computer, the network congestion signal conversion method based on any one of claims 1-6 is performed.

10. A computer program product, characterized in that, Includes a computer program, which, when running on one or more processors, implements the network congestion signal conversion method based on a programmable switch as described in any one of claims 1-6.

Images