Network congestion control method, sending end network card and receiving end network card

By obtaining and extracting timestamps in the RDMA network to calculate RTT and adjusting the packet transmission rate according to RTT, the problem of inaccurate network congestion control caused by large RTT measurement error in the RDMA network is solved, and precise control of network congestion is achieved.

CN119788619APending Publication Date: 2025-04-08ZTE CORP
View PDF 0 Cites 2 Cited by

Patent Information

Application Number
CN202311290706.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-09-28
Publication Date
2025-04-08

AI Technical Summary

Technical Problem

In RDMA networks, RTT measurement errors are large, resulting in inaccurate network congestion control.

Method used

By exchanging request and response messages between the sending network card and the receiving network card, the timestamp is obtained and extracted to calculate the round-trip delay RTT, and the packet transmission rate is adjusted according to the RTT to control network congestion.

Benefits of technology

By taking into account the internal delay of the network card, RTT measurement errors are eliminated and precise control of network congestion is achieved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119788619A_ABST
    Figure CN119788619A_ABST
Patent Text Reader

Abstract

The present application discloses a network congestion control method, a sending network card and a receiving network card, and belongs to the field of network communication technology. Among them, the method includes: the sending network card obtains the first timestamp of the sending request message, and obtains the second timestamp of the receiving response message, extracts the internal processing delay of the receiving network card from the response message, calculates the round-trip delay RTT between the sending network card and the receiving network card according to the first timestamp, the second timestamp and the internal processing delay; calculates the packet sending rate according to the RTT, and controls the network congestion according to the packet sending rate. Through this application, the internal delay of the network card is taken into account in measuring RTT, which eliminates the error caused by the internal delay of the receiving network card to the RTT measurement, and realizes the precise control of network congestion.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a network congestion control method, a sending-end network card, and a receiving-end network card. Background Art

[0002] RDMA (Remote Direct Memory Access) is a network transmission technology that allows data between two hosts to be exchanged directly in memory without the CPU participating in the transmission process. It uses the RDMA network card to directly access memory and transmit data on the network, avoiding the process of data replication and intermediate caching, achieving efficient network transmission and reducing CPU load.

[0003] In RDMA networks, due to the zero-copy characteristics and low latency advantages of RDMA, the data transmission rate is very high, which can easily lead to network congestion. Therefore, the congestion flow control mechanism is particularly important in RDMA networks. Congestion flow control is a mechanism used to control network congestion. When the traffic in the network is too large, it will cause network congestion, resulting in problems such as decreased network performance, increased latency, and even packet loss. The congestion flow control mechanism avoids network congestion and ensures network performance by limiting the data sending rate of the sender. At present, congestion flow control algorithms based on RTT (Round-Trip Time) measurement are increasingly favored by the scientific research community and major manufacturers.

[0004] In the related art, the RTT measurement scheme only measures the sending time information and receiving time information of the message, and obtains the RTT by subtracting them. As the network transmission speed increases, the processing delay fluctuation inside the network card will also affect the congestion flow control, resulting in large RTT measurement errors, which in turn leads to inaccurate network congestion control.

[0005] With respect to the above-mentioned problems existing in the related technologies, no effective solutions have been found so far. Summary of the invention

[0006] The present application provides a network congestion control method, a sending-end network card and a receiving-end network card to solve the technical problem that the RTT measurement error in the related technology is large, which leads to low accuracy of network congestion control.

[0007] According to one aspect of an embodiment of the present application, a network congestion control method is provided, which is applied to a sending-end network card, and the sending-end network card is communicatively connected with a receiving-end network card, including: obtaining a first timestamp for sending a request message to the receiving-end network card, and obtaining a second timestamp for receiving a response message returned by the receiving-end network card based on the request message; extracting an internal processing delay of the receiving-end network card from the response message; calculating a round-trip delay RTT between the sending-end network card and the receiving-end network card based on the first timestamp, the second timestamp and the internal processing delay; calculating a packet sending rate based on the RTT, and controlling network congestion based on the packet sending rate.

[0008] According to one aspect of an embodiment of the present application, a network congestion control method is provided, which is applied to a receiving-end network card, and the receiving-end network card is communicatively connected to a sending-end network card, including: receiving a request message sent by the sending-end network card, recording a third timestamp of receiving the request message, and inserting the third timestamp into the request message; recording a fourth timestamp of sending a response message corresponding to the request message to the sending-end network card; calculating a third difference between the third timestamp and the fourth timestamp, using the third difference as an internal processing delay, inserting the internal processing delay into the response message, and sending the response message to the sending-end network card.

[0009] According to one aspect of an embodiment of the present application, a network congestion control method is provided, which is applied to a network congestion control system, wherein the network congestion control system includes a sending-end network card and a receiving-end network card, wherein the sending-end network card is in communication connection with the receiving-end network card, and the network congestion control method includes: the sending-end network card sends a request message to the receiving-end network card, and obtains a first timestamp of sending the request message; the receiving-end network card receives the request message sent by the sending-end network card, records a third timestamp of receiving the request message, inserts the third timestamp into the request message, and records a fourth timestamp of sending a response message corresponding to the request message to the sending-end network card; The method comprises the steps of: calculating a third difference between the third timestamp and the fourth timestamp, taking the third difference as an internal processing delay, inserting the internal processing delay into the response message, and sending the response message to the sending-end network card; the sending-end network card receives the response message returned by the receiving-end network card, and obtains a second timestamp of receiving the response message; extracting the internal processing delay of the receiving-end network card from the response message; calculating a round-trip delay RTT between the sending-end network card and the receiving-end network card according to the first timestamp, the second timestamp and the internal processing delay; calculating a packet sending rate according to the RTT, and controlling network congestion according to the packet sending rate.

[0010] According to another aspect of an embodiment of the present application, a sending network card is also provided, which is communicatively connected to a receiving network card, and the sending network card includes: an acquisition module, used to acquire a first timestamp for sending a request message to the receiving network card, and to acquire a second timestamp for receiving a response message returned by the receiving network card based on the request message; an extraction module, used to extract an internal processing delay of the receiving network card from the response message; a calculation module, used to calculate a round-trip delay RTT between the sending network card and the receiving network card based on the first timestamp, the second timestamp and the internal processing delay; and a control module, used to calculate a packet sending rate based on the RTT, and to control network congestion based on the packet sending rate.

[0011] According to another aspect of an embodiment of the present application, a receiving network card is also provided, which is communicatively connected to a sending network card, and the receiving network card includes: a receiving module, used to receive a request message sent by the sending network card, record a third timestamp of receiving the request message, and insert the third timestamp into the request message; a sending module, used to record a fourth timestamp of sending a response message corresponding to the request message to the sending network card; and a calculating module, used to calculate a third difference between the third timestamp and the fourth timestamp, use the third difference as an internal processing delay, insert the internal processing delay into the response message, and send the response message to the sending network card.

[0012] According to another aspect of an embodiment of the present application, a storage medium is further provided, which includes a stored program, and the above steps are executed when the program is run.

[0013] According to another aspect of an embodiment of the present application, there is also provided an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; wherein: the memory is used to store computer programs; and the processor is used to execute the steps in the above method by running the program stored in the memory.

[0014] The embodiment of the present application also provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute the steps in the above method.

[0015] Through this application, the sending network card obtains the first timestamp of sending the request message and the second timestamp of receiving the response message, extracts the internal processing delay of the receiving network card from the response message, and calculates the round-trip delay RTT between the sending network card and the receiving network card based on the first timestamp, the second timestamp and the internal processing delay; calculates the packet sending rate based on the RTT, and controls network congestion based on the packet sending rate. By measuring RTT and considering the internal delay of the network card, the error caused by the internal delay of the receiving network card in RTT measurement is eliminated, and precise control of network congestion is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0017] Figure 1 It is a hardware structure block diagram of a network card in an embodiment of the present application;

[0018] Figure 2 is a flow chart of a network congestion control method applied to a sending-end network card according to an embodiment of the present application;

[0019] Figure 3 is a flow chart of a network congestion control method applied to a receiving-end network card according to an embodiment of the present application;

[0020] Figure 4 It is a schematic diagram of the interaction process between the sending end network card and the receiving end network card in the embodiment of the present application;

[0021] Figure 5 It is a flow chart of the RTT measurement solution in the embodiment of the present application;

[0022] Figure 6 It is a schematic diagram of the message structure in the embodiment of the present application;

[0023] Figure 7 It is a schematic diagram of the process of processing a request message in an embodiment of the present application;

[0024] Figure 8 It is a schematic diagram of the process of processing a response message in an embodiment of the present application;

[0025] Fig. 9 It is a schematic diagram of the process of MP performing network congestion control in an embodiment of the present application;

[0026] Fig.10 This is a structural block diagram of a sending end network card in an embodiment of the present application;

[0027] Fig.11It is a structural block diagram of the receiving end network card in the embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only embodiments of a part of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work should fall within the scope of protection of the present application. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] Example 1

[0031] The method embodiment provided in the first embodiment of the present application can be executed in a network card. Taking running on a network card as an example, Figure 1 is a hardware structure block diagram of a network card in an embodiment of the present application. Figure 1 As shown, the network card may include a programmable microprocessor, such as Figure 1 The MP (Microprocessor) module, accelerator (such as Figure 1 The ACK RTT module in the ACK RTT module is used to store and calculate RTT (Round-Trip Time). The ACK RTT module contains memory and can interact with external memory. The external memory is used to store more QP (queue pair, task queue) time and message information to support RTT measurement in large-scale network scenarios. The request end TX of the network card is used to send messages, and the response end RX of the network card is used to receive messages. It can be understood by ordinary technicians in this field that Figure 1 The structure shown is for illustration only and does not limit the structure of the above network card. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0032] In this embodiment, a network congestion control method is provided, which is applied to a sending end network card. Figure 2 is a flow chart of a network congestion control method according to an embodiment of the present application, such as Figure 2 As shown, the process includes the following steps:

[0033] Step S10, obtaining a first timestamp of sending a request message to the receiving end network card, and obtaining a second timestamp of receiving a response message returned by the receiving end network card based on the request message;

[0034] The application scenarios of this embodiment include multiple node servers or storage connected to the network through network cards, and the storage or server sends and receives messages through the network card. The main application environments include high-performance computing, distributed storage, magnetic arrays, GPU Direct, etc. In these applications, accurate network congestion flow control can be implemented to improve data transmission efficiency and avoid network congestion. Figure 1 and Figure 4 When the requesting end TX of the sending network card HostA sends a request message, TX sends a report to the ACK RTT module, and the report includes the sending time of sending the request message to the receiving network card HostB (i.e., the first timestamp T1). The ACK RTT module stores the T1 time, and when the receiving end RX of the sending network card receives the response message returned by the receiving network card based on the request message, the receiving time (i.e., the second timestamp T5) is recorded.

[0035] Step S20, extracting the internal processing delay of the receiving end network card from the response message;

[0036] Step S30, calculating the round-trip delay RTT between the sending end network card and the receiving end network card according to the first timestamp, the second timestamp and the internal processing delay;

[0037] Step S40, calculating a packet sending rate according to the RTT, and controlling network congestion according to the packet sending rate.

[0038] Extract the internal processing delay (T4-T2) of the receiving end network card insertion response message RTK, calculate the round-trip delay RTT as T5-T1-(T4-T2) according to the first timestamp T1, the second timestamp T5, and the internal processing delay (T4-T2), calculate the packet sending rate according to RTT, and control the network congestion according to the packet sending rate.

[0039] In this embodiment, as the data transmission speed becomes faster and faster, the number of tasks and nodes increases, the accuracy and real-time requirements for RTT measurement are also getting higher and higher. Through the above steps, the sending end network card obtains the first timestamp of the sending request message, and obtains the second timestamp of the receiving response message, extracts the internal processing delay of the receiving end network card from the response message, and calculates the round-trip delay RTT between the sending end network card and the receiving end network card based on the first timestamp, the second timestamp and the internal processing delay; calculates the packet sending rate based on RTT, and controls network congestion based on the packet sending rate. By measuring RTT and considering the internal delay of the network card, the error caused by the internal delay of the receiving end network card to the RTT measurement is eliminated, and accurate control of network congestion is achieved.

[0040] In one implementation of the present embodiment, obtaining the first timestamp for sending a request message to the receiving network card includes: obtaining the task queue QP and the message sequence number PSN in the response message; searching the sending network card locally for a target request message corresponding to the QP and the PSN, and determining the time of sending the target request message as the first timestamp.

[0041] Each QP sends messages in sequence, and each message belongs to a task queue QP and corresponds to a message sequence number PSN. In this embodiment, when the sending end network card receives the response message, it obtains the QP number and PSN number in the response message, searches for the target request message corresponding to the QP number and PSN number, and determines the time of sending the target request message as the first timestamp T1. By recording and comparing the QP number and PSN number of the sent message and the response ACK message, the time difference between sending the message and receiving the ACK is obtained, and the problem of ACK aggregation being difficult to measure the time difference is solved by using a linked list design. In this embodiment, T1 is stored locally, avoiding the problem of inserting T1 into the request message and being easily modified by the receiving end network card.

[0042] The current remote direct memory access RDMA designs all support the ACK message aggregation function. This embodiment uses the local storage T1 to find the T1 timestamp stored in the sending message corresponding to the response message by comparing the response packet information. It can measure the RTT without negotiating with the receiving end network card and other devices to measure the RTT. It does not occupy the link bandwidth and does not rely on other network devices such as the receiving end network card and switches, making the RTT measurement more feasible and compatible. It is compatible with the RTT measurement in the scenario of ACK message aggregation.

[0043] In another implementation manner of this embodiment, after obtaining the second timestamp of the response message returned by the receiving-end network card based on the request message, the method further includes:

[0044] Step A, extracting the third timestamp in the response message, calculating the first difference between the first timestamp and the third timestamp, using the first difference as the one-way sending path delay, and the third timestamp is the timestamp when the receiving end network card receives the request message; extracting the fourth timestamp in the response message, calculating the second difference between the second timestamp and the fourth timestamp, using the second difference as the one-way receiving path delay, and the fourth timestamp is the timestamp when the receiving end network card sends the response message;

[0045] Step B: controlling network congestion according to the one-way sending path delay or the one-way receiving path delay.

[0046] In this embodiment, the request end TX of the receiving network card can be configured to insert the fourth timestamp T4, (T4-T2) or the third timestamp T2 into the response message. Correspondingly, by extracting T2 in the response message, the one-way sending path delay (T2-T1) can be calculated. Similarly, by extracting T4 in the response message, the one-way receiving path delay (T5-T4) can be calculated, and the network congestion can be controlled according to the one-way sending path delay or the one-way receiving path delay. The RTT measurement method of this embodiment supports multiple configurations, and can only measure the sending path delay of T2-T1 or the response path delay of T5-T4. It can be flexibly configured for different scenarios to make the RTT measurement more accurate. For example, in a network scenario where WRITE services are the main body, measuring the one-way sending path delay truly reflects the congestion of network services.

[0047] In another implementation of the present embodiment, obtaining a first timestamp for sending a request message to the receiving network card includes: obtaining the number of task queues QP in the memory of the sending network card; when the number of QPs exceeds a preset number, obtaining part of the QPs; and storing message information of the part of the QPs sending the request message to the receiving network card in an external memory, wherein the message information includes a first timestamp, a task queue number QPN of the message, and the head and tail addresses of a linked list of message sequence numbers PSN.

[0048] The memory of the network card only supports the storage of information of some QPs. When the number of QPs is large, this embodiment stores the relevant message information of some QPs in the external memory, thereby realizing the measurement of RTT in a large-scale network scenario. The relevant message information of the QP includes the first timestamp of sending the request message to the receiving end network card, the task queue number QPN of the message, the head and tail addresses of the message sequence number PSN linked list, and other information.

[0049] This embodiment uses the interaction between internal memory and external memory to achieve RTT measurement in large-scale network scenarios. To address the problem of large-scale scenarios with large computational complexity, a microprocessor is used to perform algorithm calculations to achieve real-time congestion flow control for large-scale networks.

[0050] In one implementation of this embodiment, obtaining a first timestamp of sending a request message to the receiving-end network card includes:

[0051] C1, obtaining the message type of the message sent to the receiving end network card, and locating the basic transmission header BTH field according to the message type;

[0052] C2, checking the operation code Opcode of the BTH field, filtering out invalid sending messages and retransmission messages, and retaining valid request messages;

[0053] C3, determining whether the request message can generate a response message;

[0054] C4: If the request message can generate a response message, record the first timestamp of sending the request message to the receiving end network card.

[0055] In this implementation manner, since retransmitted messages and abnormal messages may cause RTT measurement errors, this embodiment filters retransmitted and abnormal request messages and response messages to further improve the accuracy of RTT measurement.

[0056] Verify the sent message and obtain the message type of the sent message. The target types include IPV4 without VLAN field, IPV6 without VLAN field, IPV4 with VLAN field and IPV6 with VLAN field. Determine whether the message type of the sent message is the above target type. If the message type of the sent message is one of the above target types, determine that the sent message is a valid sent message and filter out invalid messages other than the above target types. Obtain the identification class carried by the sent message. The identification class is used to identify whether the sent message is a retransmission message. Retransmission messages can be filtered based on the identification class. Different types of messages have different lengths, so the message type of the sent message is determined. Based on the message type, the basic transmission header BTH field of the message can be located, and then the operation code Opcode of the BTH field is located. The Opcode of the BTH field is checked, and the request message is filtered out from the sent message according to the Opcode. It is determined whether the request message can generate a response message, and thus it is determined whether to store the message and time information. If the request message can generate a response message, the first timestamp of sending the request message to the receiving network card is recorded.

[0057] In an example, refer to Figure 7 First, obtain the packet report, determine whether the sent message is a retransmission message or an invalid message, and discard the retransmission message and invalid message. For ordinary business messages, refer to Figure 6 , Figure 6The schematic diagram of the structure of the message includes Eth L2 Header (Ethernet L2 Header), Ether type (Ether type indicates that the data packet is IP, that is, the next header is IP), IP Header, ip.protocol_number (ip protocol number indicates that the data packet is UDP), UDP Header, UDP dport number (UDP data port number indicates that the next header is IB.BTH), IB.BTH+(L4Hdr), IB Payload, ICRC, FCS (frame tail). According to the Type / Length1 field in the Eth L2 Header, it is judged whether the Eth L2 header contains the VLAN field, and whether the next field is the IPV4 or IPV6 field, so as to locate the BTH field, check the Opcode of the BTH field, filter out the request message, and judge whether the request message can generate a response message. If it can generate a response message, the message information and T1 timestamp are stored. If it cannot generate a response message, it is discarded.

[0058] refer to Figure 8 , check the response message to see if it is a normal response message or a retransmission response message. If it is a retransmission response message, find the first timestamp corresponding to the retransmission response message and do not report the RTT. If it is a normal response message, check the Opcode of the normal response message to determine whether it is an ACK message. If it is an ACK message, check the upper three bits of the AETH field of the ACK message. If it is 000, determine the ACK message as a response message for measuring the RTT, and then calculate the RTT.

[0059] Optionally, in this embodiment, the abnormal RTT result may be subjected to smoothing filtering to filter out abnormal and retransmitted messages.

[0060] In one implementation of this embodiment, calculating the packet sending rate according to the RTT includes:

[0061] S41, obtaining the task queue QP corresponding to the RTT;

[0062] S42, comparing the RTT with an upper threshold and a lower threshold, and determining whether the current QP state is a processor maintenance RTT state;

[0063] S43, if the RTT is greater than the upper threshold and the QP state is the processor-maintained RTT state, a speed reduction calculation is performed to obtain a first packet sending rate; if the RTT is less than the lower threshold and the QP state is the processor-maintained RTT state, a speed increase calculation is performed to obtain a second packet sending rate; if the RTT is greater than or equal to the lower threshold and less than or equal to the upper threshold, and the QP state is the processor-maintained RTT state, the RTT gradient and the threshold gradient of the RTT are further judged, and if the RTT gradient is between ± the threshold gradient, the additive speed increase stage is entered to obtain a third packet sending rate; if the RTT gradient is greater than the absolute value of the threshold gradient, the beta speed reduction stage is entered to obtain a fourth packet sending rate; if the RTT gradient is less than the inverse of the absolute value of the threshold gradient, the multiplicative speed increase stage is entered to obtain a fifth packet sending rate.

[0064] refer to Fig. 9 , MP obtains RTT information, obtains the large QP group corresponding to the task queue QP corresponding to the RTT, the large QP group groups QPs according to nodes, and a large QP group may include multiple QPs; this embodiment reads the status (Flag_QP_type) of each QP and the RTT event record flag in each cycle.

[0065] If Flag_QP_type=01, indicating that the current QP is in a new QP state, an initial rate rate=Rc_init is configured for the current QP, wherein the new QP is a QP for which no delay has been measured on the link.

[0066] If Flag_QP_type=10, it means that the current QP is rescheduled after aging. Then, the time (△T_aging) from the start of aging to the re-entry of the MP for calculation is read. If the time is greater than the preset time TTHR, it means that the aging information of the current QP has expired and it is treated as a new QP. If the time is less than or equal to TTHR, it means that the aging information of the current QP is still usable. Then, it is determined whether the current RTT is greater than the RTT upper threshold (Thigh).

[0067] If the current RTT is greater than the RTT upper threshold and the current QP state is the processor maintenance RTT state, a speed reduction calculation is performed to obtain a first packet sending rate, and network congestion is controlled according to the first packet sending rate.

[0068] If the current RTT is less than or equal to the RTT upper threshold and the QP state is not the processor maintenance RTT state, the speed remains unchanged.

[0069] If the current RTT is less than or equal to the RTT upper threshold and less than the lower threshold (Tlow), and the QP state is the processor maintenance RTT state, the speed is increased.

[0070] If the current RTT is less than or equal to the RTT upper threshold, greater than or equal to the lower threshold, and the QP state is the processor maintaining the RTT state, then the RTT gradient gradi (normalized_gradient, the gradient normalization of the RTT change) and the threshold gradient thred are further judged. If the RTT gradient is between ± the threshold gradient, the additive speed-up stage is entered to obtain the third packet sending rate.

[0071] If the RTT gradient is greater than the absolute value of the gradient threshold, the speed reduction factor beta speed reduction phase is entered to obtain the fourth packet sending rate.

[0072] If the RTT gradient is less than the inverse of the absolute value of the gradient threshold, the multiplicative speed-up phase is entered to obtain the fifth packet sending rate.

[0073] In this embodiment, if Flag_QP_ype=00, indicating that the current QP is an active QP, the Flag_newRTT flag is read (the flag indicates whether the QP has a new RTT event). If the Flag newRTT flag is 1, the number of valid RTT measurement groups (RTT num) of the RTT event record of the QP and the measurement value (RTT measure) in each group of RTT measurements are read.

[0074] Figure 5 This is a specific implementation flow chart of the RTT measurement solution of the embodiment of the present application, including:

[0075] Step 1: When the sending network card sends service messages, the ACK RTT module records the T1 timestamp of these messages and stores them.

[0076] Step 2: The receiving network card responder RX inserts the T2 timestamp into the UDP checksum field of the received service message at the ingress.

[0077] Step 3: The receiving network card responder converts the service message into a response message, inserts the T2 timestamp into the UDP checksum of the generated response message, and sends it to the requester TX of the receiving network card.

[0078] The position where the timestamp is inserted into the message in the second and third steps is the UDP checksum field of the service message, or the reserved field of the BTH in the packet header of the message or the length field of the UDP.

[0079] Step 4: The requesting end TX of the receiving network card takes out T2 of the UDP checksum in the response message, calculates T4-T2, and inserts T4 or T4-T2 or T2 into the reserved field of the BTH header of the response message through software configuration.

[0080] Step 5: When the sending network card receives the response message at the RX entrance of the responding end, it records the T5 timestamp and inserts T5 or T5-(T4-T2) or T2 or T5-T4 into the reserved field of the BTH header of the received response message through software configuration.

[0081] The position where the timestamp is inserted into the message in the fourth and fifth steps is the reserved field of the BTH header of the response message, or the checksum field of UDP or the length field of UDP.

[0082] Step 6: The RX of the sending network card responder transmits the response message information and timestamp to the ACK RTT module. The ACKRTT module uses the response message information to compare the service message information stored in T1, finds the stored T1 timestamp, and reports the RTT of the message to the MP.

[0083] Step 7: The MP of the sending network card calculates the packet sending rate based on the obtained RTT.

[0084] Step 8: MP converts the rate into token delivery information, controls the packet sending rate of the requesting end TX of the sending network card, and implements congestion flow control.

[0085] In this embodiment, a network congestion control method is also provided, which is applied to a receiving end network card. Figure 3 is a flow chart of a network congestion control method according to an embodiment of the present application, such as Figure 3 As shown, the process includes the following steps:

[0086] S50, receiving a request message sent by the sending end network card, recording a third timestamp of receiving the request message, and inserting the third timestamp into the request message;

[0087] S60, recording a fourth timestamp of sending a response message corresponding to the request message to the sending end network card;

[0088] S70, calculating a third difference between the third timestamp and the fourth timestamp, taking the third difference as an internal processing delay, inserting the internal processing delay into the response message, and sending the response message to the sending end network card.

[0089] The receiving end network card receives the request message sent by the sending end network card, and records the third timestamp T2 of the received request message. The responding end RX of the receiving end network card inserts the T2 timestamp into the UDP checksum field of the received service message at the inlet. The receiving end network card RX converts the service message into a response message, inserts the T2 timestamp into the UDP checksum of the generated response message, and sends it to the requesting end TX of the receiving end network card. The requesting end TX of the receiving end network card takes out T2 of the UDP checksum in the response message, records the fourth timestamp T4 of sending the response message to the sending end network card, calculates the internal processing delay T4-T2, and inserts the internal processing delay into the response message, and sends the response message to the sending end network card. This embodiment eliminates the RTT error by recording the processing delay of the message in the receiving end network card in the UDP or BTH reserved field, thereby accurately measuring the RTT time of the message in the link.

[0090] In one implementation of this embodiment, after receiving the request message sent by the sending end network card, the method further includes: recording a third timestamp of receiving the request message; converting the request message into a first response message, inserting the third timestamp into the first response message, and sending the first response message to the sending end network card; or, recording a fourth timestamp of sending a response message corresponding to the request message to the sending end network card; converting the request message into a second response message, and inserting the third timestamp into the second response message, and sending the second response message to the sending end network card. In this implementation, by software configuration, the third timestamp T2 or the fourth timestamp T4 is inserted into the reserved field of the BTH header of the response message, so as to realize the measurement of the one-way transmission path delay or the one-way reception path delay.

[0091] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0092] Example 2

[0093] In this embodiment, a network congestion control device is also provided to implement the above-mentioned embodiments and preferred implementation modes, which have been described and will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0094] Fig.10 is a structural block diagram of a sending end network card in an embodiment of the present application, such as Fig.10 As shown, the sending end network card includes:

[0095] The acquisition module 100 is used to acquire a first timestamp of sending a request message to the receiving end network card, and to acquire a second timestamp of receiving a response message returned by the receiving end network card based on the request message;

[0096] An extraction module 101 is used to extract the internal processing delay of the receiving end network card from the response message;

[0097] A calculation module 102, configured to calculate a round trip delay RTT between the sending end network card and the receiving end network card according to the first timestamp, the second timestamp and the internal processing delay;

[0098] The control module 103 is used to calculate a packet sending rate according to the RTT, and control network congestion according to the packet sending rate.

[0099] Fig.11 is a structural block diagram of a receiving end network card in an embodiment of the present application, such as Fig.11 As shown, the receiving end network card includes:

[0100] The receiving module 110 is used to receive the request message sent by the sending end network card, record a third timestamp of receiving the request message, and insert the third timestamp into the request message;

[0101] The sending module 111 is used to record a fourth timestamp of sending a response message corresponding to the request message to the sending end network card;

[0102] The calculation module 112 is used to calculate a third difference between the third timestamp and the fourth timestamp, use the third difference as an internal processing delay, insert the internal processing delay into the response message, and send the response message to the sending end network card.

[0103] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0104] Example 3

[0105] An embodiment of the present application further provides a storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0106] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0107] S1, obtaining a first timestamp of sending a request message to the receiving end network card, and obtaining a second timestamp of receiving a response message returned by the receiving end network card based on the request message;

[0108] S2, extracting the internal processing delay of the receiving end network card from the response message;

[0109] S3, calculating the round-trip delay RTT between the sending end network card and the receiving end network card according to the first timestamp, the second timestamp and the internal processing delay;

[0110] S4, calculating a packet sending rate according to the RTT, and controlling network congestion according to the packet sending rate.

[0111] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store computer programs.

[0112] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0113] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0114] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0115] S1, obtaining a first timestamp of sending a request message to the receiving end network card, and obtaining a second timestamp of receiving a response message returned by the receiving end network card based on the request message;

[0116] S2, extracting the internal processing delay of the receiving end network card from the response message;

[0117] S3, calculating the round-trip delay RTT between the sending end network card and the receiving end network card according to the first timestamp, the second timestamp and the internal processing delay;

[0118] S4, calculating a packet sending rate according to the RTT, and controlling network congestion according to the packet sending rate.

[0119] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0120] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0121] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0123] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0124] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0125] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0126] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A network congestion control method, characterized in that: Applied to a sending end network card, the sending end network card is communicatively connected with a receiving end network card, and the method includes: Acquire a first timestamp of sending a request message to the receiving-end network card, and acquire a second timestamp of receiving a response message returned by the receiving-end network card based on the request message; Extracting the internal processing delay of the receiving end network card from the response message; Calculate the round-trip delay RTT between the sending end network card and the receiving end network card according to the first timestamp, the second timestamp and the internal processing delay; The packet sending rate is calculated according to the RTT, and network congestion is controlled according to the packet sending rate.

2. The method according to claim 1, characterized in that Acquiring a first timestamp of sending a request message to the receiving end network card includes: Obtain the task queue QP and message sequence number PSN in the response message; The target request message corresponding to the QP and the PSN is searched locally on the sending end network card, and the time of sending the target request message is determined as the first timestamp.

3. The method according to claim 1, characterized in that After obtaining a second timestamp of a response message returned by the receiving end network card based on the request message, the method further includes: Extracting a third timestamp in the response message, calculating a first difference between the first timestamp and the third timestamp, and using the first difference as a one-way transmission path delay, wherein the third timestamp is a timestamp when the receiving end network card receives the request message; Extracting a fourth timestamp in the response message, calculating a second difference between the second timestamp and the fourth timestamp, and using the second difference as a one-way receiving path delay, wherein the fourth timestamp is a timestamp when the receiving-end network card sends the response message; Network congestion is controlled according to the one-way sending path delay or the one-way receiving path delay.

4. The method according to claim 1, characterized in that: Acquiring a first timestamp of sending a request message to the receiving end network card includes: Obtain the number of task queues QP in the memory of the sending end network card; When the number of the QPs exceeds a preset number, obtaining part of the QPs; The message information of the request message sent by the part of QP to the receiving end network card is stored in the external memory, wherein the message information includes the first timestamp, the task queue number QPN of the message and the head and tail addresses of the message sequence number PSN linked list.

5. The method according to claim 1, characterized in that Acquiring a first timestamp of sending a request message to the receiving end network card includes: Acquire the message type of the message sent to the receiving end network card, and locate the basic transmission header BTH field according to the message type; Check the operation code Opcode of the BTH field, filter out invalid sending messages and retransmission messages, and retain valid request messages; Determining whether the request message can generate a response message; If the request message can generate a response message, then the first timestamp of sending the request message to the receiving end network card is recorded.

6. The method according to claim 1, characterized in that Calculating the packet sending rate according to the RTT includes: Get the task queue QP corresponding to the RTT; Compare the RTT with an upper threshold and a lower threshold, and determine whether the current QP state is a processor maintenance RTT state; If the RTT is greater than the upper threshold and the QP state is the processor-maintained RTT state, a speed reduction calculation is performed to obtain a first packet sending rate; if the RTT is less than the lower threshold and the QP state is the processor-maintained RTT state, a speed increase calculation is performed to obtain a second packet sending rate; if the RTT is greater than or equal to the lower threshold and less than or equal to the upper threshold, and the QP state is the processor-maintained RTT state, the RTT gradient and the threshold gradient of the RTT are further judged, and if the RTT gradient is between ± the threshold gradient, the additive speed increase stage is entered to obtain a third packet sending rate; if the RTT gradient is greater than the absolute value of the threshold gradient, the beta speed reduction stage is entered to obtain a fourth packet sending rate; if the RTT gradient is less than the inverse of the absolute value of the threshold gradient, the multiplicative speed increase stage is entered to obtain a fifth packet sending rate.

7. A network congestion control method, characterized in that: Applied to a receiving end network card, the receiving end network card is communicatively connected with a sending end network card, and the method includes: Receiving a request message sent by the sending end network card, recording a third timestamp of receiving the request message, and inserting the third timestamp into the request message; Recording a fourth timestamp of sending a response message corresponding to the request message to the sending end network card; Calculate a third difference between the third timestamp and the fourth timestamp, use the third difference as an internal processing delay, insert the internal processing delay into the response message, and send the response message to the sending end network card.

8. A network congestion control method, characterized in that: Applied to a network congestion control system, the network congestion control system includes a sending end network card and a receiving end network card, the sending end network card is communicatively connected with the receiving end network card, and the method includes: The sending end network card sends a request message to the receiving end network card, and obtains a first timestamp of sending the request message; The receiving-end network card receives the request message sent by the sending-end network card, records a third timestamp of receiving the request message, inserts the third timestamp into the request message, records a fourth timestamp of sending a response message corresponding to the request message to the sending-end network card, calculates a third difference between the third timestamp and the fourth timestamp, uses the third difference as an internal processing delay, inserts the internal processing delay into the response message, and sends the response message to the sending-end network card; The sending-end network card receives the response message returned by the receiving-end network card, and obtains a second timestamp of receiving the response message; extracts an internal processing delay of the receiving-end network card from the response message; calculates a round-trip time RTT between the sending-end network card and the receiving-end network card according to the first timestamp, the second timestamp and the internal processing delay; calculates a packet sending rate according to the RTT, and controls network congestion according to the packet sending rate.

9. A sending end network card, characterized in that: The sending end network card is connected to the receiving end network card for communication, and the sending end network card includes: An acquisition module, used for acquiring a first timestamp of sending a request message to the receiving end network card, and acquiring a second timestamp of receiving a response message returned by the receiving end network card based on the request message; An extraction module, used for extracting the internal processing delay of the receiving end network card from the response message; A calculation module, configured to calculate a round trip delay RTT between the sending end network card and the receiving end network card according to the first timestamp, the second timestamp and the internal processing delay; A control module is used to calculate a packet sending rate according to the RTT, and control network congestion according to the packet sending rate.

10. A receiving end network card, characterized in that: The receiving end network card is connected to the sending end network card for communication, and the receiving end network card includes: A receiving module, configured to receive the request message sent by the sending end network card, record a third timestamp of receiving the request message, and insert the third timestamp into the request message; A sending module, used for recording a fourth timestamp of sending a response message corresponding to the request message to the sending-end network card; The calculation module is used to calculate a third difference between the third timestamp and the fourth timestamp, use the third difference as an internal processing delay, insert the internal processing delay into the response message, and send the response message to the sending end network card.

Citation Information

Cited By

  • Instruction timeliness verification method and device, equipment and storage medium

    CN120956632A

  • Inter-host data transmission method and device based on UDP (User Datagram Protocol) and related equipment

    CN121907944A