SACK-based packet loss retransmission and receiving method

Abstract

The invention belongs to the technical field of data communication, and particularly relates to a lost packet retransmission and receiving method based on SACK. Comprising a packet loss inference mechanism based on explicit notification and a packet loss positioning mechanism based on selective retransmission; the explicit notification-based packet loss inference mechanism aims at optimizing packet loss processing in a data transmission process, and is applied to a switch; the core of the mechanism is that an explicit packet loss notification solution is adopted, and it is ensured that packet loss reporting is carried out only under specific conditions. The packet loss positioning mechanism based on selective retransmission is applied to a receiving end, and effective management of lost data packets is realized through accurate positioning. According to the method, a packet loss inference mechanism based on explicit notification and a packet loss positioning mechanism based on selective retransmission are introduced, so that inaccurate packet loss detection and low-efficiency batch retransmission of a traditional scheme are avoided, adaptive accurate retransmission and rapid selection confirmation retransmission are realized, and the network transmission throughput is greatly increased.

Description

Technical Field

[0001] This invention belongs to the field of data communication technology, specifically relating to a packet loss retransmission and reception method based on SACK. Background Technology

[0002] RoCE (RDMA over Converged Ethernet) is a standardized approach for deploying RDMA in Ethernet-based data centers. Traditionally, RoCE operates on lossless networks by default and lacks inherent reliability guarantees.

[0003] To ensure reliability in lossy networks, traditional solutions use the Go-Back-N (Go-Back-N) algorithm. However, this protocol retransmits a large number of data packets when packet loss occurs, significantly reducing transmission efficiency. Mathematical reasoning suggests that when the packet loss rate reaches 1%, RoCE throughput will drop by nearly 80%. Experiments show that under RoCE, the latency of normal network flow is only 329μs for 99% of cases, while network flow experiencing timeouts requires retransmission, resulting in a latency as high as 30ms for 99% of cases.

[0004] Specifically, the traditional approach has shortcomings in two aspects: Packet loss detection is difficult: Traditional solutions rely on implicitly inferring whether data packets are lost, assuming a packet is lost when: no packet is received within a timeout period or out-of-order packets are received. However, this traditional approach is prone to misjudgment, such as when network congestion causes slow packet transmission, which may also be interpreted as packet loss.

[0005] Precise packet loss location is difficult: traditional solutions only locate the loss in batches, requiring the retransmission of a large number of packets. Once packet loss occurs, the receiver sends a NACK. x Indicates the sequence number is x Subsequent unreceived packets require retransmission of all subsequent packets. This leads to redundant retransmissions, exacerbating network congestion and significantly reducing network transmission efficiency.

[0006] In summary, because RDMA originally operated on lossless networks, its packet loss recovery mechanism was inherently inefficient, and ROCE also inherited this outdated mechanism. Furthermore, because early switches lacked programmability, monitoring packet loss on the switch itself was difficult. Therefore, under the existing mechanisms, packet loss significantly reduces network transmission efficiency. Summary of the Invention

[0007] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a packet loss retransmission and reception method based on SACK (Selective Acknowledgment), which solves the problem of insufficient reliability of existing ROCE technology in lossy networks, thereby improving the reliable transmission capability of RoCE (RDMA over Converged Ethernet) and enabling it to operate efficiently in lossy intelligent computing cluster networks, overcoming its limitations in lossless network environments. This invention comprises two aspects, respectively addressing two shortcomings of the conventional solutions in the background art.

[0008] Technical solution A packet loss retransmission and reception method based on SACK includes: a packet loss inference mechanism based on explicit notification and a packet loss location mechanism based on selective retransmission.

[0009] The packet loss inference mechanism based on explicit notification aims to optimize packet loss handling during data transmission and is applied to switches. The core of this mechanism lies in employing an explicit packet loss notification solution, ensuring that packet loss reporting only occurs under specific conditions. Specifically, when a data packet is dropped at an intermediate switch due to excessive network pressure, the switch proactively sends a packet loss notification to the receiving end.

[0010] This method effectively avoids false positives and reduces unnecessary retransmission requests because it only issues notifications when data packets are confirmed to be lost. Through this mechanism, the overall network load is reduced, transmission efficiency is improved, and latency caused by duplicate data transmissions due to network instability is also decreased.

[0011] In this process, communication between the sender and receiver becomes more efficient. Upon receiving a packet loss notification, the sender can perform targeted retransmissions as needed, rather than blindly retransmitting all data packets. This not only saves bandwidth resources but also improves the reliability of data transmission. The use of explicit packet loss notifications ensures that the network can better self-adjust under high load conditions, thereby improving overall performance.

[0012] The packet loss location mechanism based on selective repeat is applied at the receiving end, which accurately describes which data packets were not received within a data transmission interval, thereby supporting the retransmission of specific data packets; at the same time, the SACK (selective acknowledgment) mechanism is adopted, which allows the receiving end to report back to the sending end which data packets were successfully received. This method allows the sender to quickly identify and retransmit packets that are indeed lost, avoiding redundant transmission.

[0013] The implementation of the SACK mechanism not only improves the efficiency of data transmission, but also enhances the adaptability of the network.

[0014] When a data packet is received, the receiving end records its status and, in the event of packet loss, sends the sequence number of the unreceived data packet to the sender via a SNACK frame. This feedback mechanism allows the sender to monitor the data transmission status in real time and take appropriate action.

[0015] A packet loss retransmission and reception method based on SACK is described below: S1, the sender begins data transmission, sending data packets to the network; S2, During data packet transmission, when the switch detects that a data packet has been dropped based on the packet loss inference mechanism of explicit notification, it sends a packet loss notification frame (NACK) to the receiving end. S3. After receiving the packet loss notification frame, the receiving end sends an optional retransmission notification to the sender based on the packet loss location mechanism of optional retransmission. The receiving end specifies which data packets need to be retransmitted based on the status of the data packets it has already received. S4. After receiving the Select Retransmission notification, the sender retransmits the lost data packets according to the notification content.

[0016] Furthermore, the packet loss inference mechanism based on explicit notification is implemented in the switch and includes three modules: a packet loss detection module, an event handling module, and a notification generator module.

[0017] The packet loss detection module is responsible for determining whether data packets will be dropped at the switch; The event handling module is responsible for determining whether data packets are lost at the link. The notification generator module is responsible for generating packet loss notification frames.

[0018] After the packet loss detection module or event handling module detects packet loss in the switch or link, the notification generator module generates a packet loss notification frame and provides it to the receiving end.

[0019] Furthermore, the packet loss detection module is responsible for obtaining the shared buffer / queue status at the switch ingress queue and outputting whether the data packet will be dropped at the switch. Specifically, the packet loss detection module calculates the remaining buffer pool space by multiplying the utilization rate of the entire buffer pool by the size of the buffer pool.

[0020] If the remaining space is greater than the size of the data packet about to enter the buffer pool, the data packet can enter; otherwise, it will be dropped just before entering the buffer pool. This allows us to predict whether the data packet will be dropped at the switch. If it is dropped, we output "dropped"; otherwise, we output "not dropped".

[0021] Furthermore, the event processing module is responsible for maintaining the state of all flows passing through the switch to implicitly infer whether data packets were lost at the link.

[0022] The event handling module calculates the hash index based on the flowID of the data packet and takes appropriate action based on the packet loss situation.

[0023] The specific processing is as follows: First, the data packet pkt arriving at the switch's ingress queue is received. This data packet contains a flow identifier (flowID) and a packet sequence number (PSN). Next, the congestion flow table (Flow_table) is maintained, which includes the flow identifier (flowID), the expected packet sequence number (PSN), and the time (time) when the flow was marked as congested. Subsequently, based on the output of the packet loss detection module, it is determined whether the data packet should be dropped, and an expiration event threshold (δ) is set. Finally, output operations are generated based on the processing results, including: enqueuing the data packet pkt into the switch buffer; enqueuing the data packet pkt and sending the (flowID, PSN) information to the notification generator module, or DROP(pkt) (generating a packet loss notification); dropping the data packet pkt and sending the (pkt.flowID, pkt.PSN) information to the notification generator.

[0024] The specific steps are as follows: First, calculate the hash index idx based on the packet's flowID. If the packet is to be dropped (based on the output of the packet loss event collector), then check if the flow is in the congestion flow table Flow_table: If the flow is not in the table and the entry is empty or the information is outdated (the current time minus the time in the entry is greater than the threshold δ), then insert the flow information into the congested flow table and set the operation to DROP(pkt) to generate a packet loss notification. Otherwise, if a hash collision occurs, no action is taken.

[0025] If the flow is in the congestion flow table and the packet's PSN is equal to the expected PSN, update the time in the entry and set the operation to DROP(pkt) again; otherwise, do nothing.

[0026] If the packet will not be dropped and the flow is not in the congestion flow table, set the operation to ENQUEUE(pkt) and enqueue the packet into the switch buffer.

[0027] If the flow is in the congestion flow table and the packet's PSN equals the expected PSN, then remove the flow from the congestion flow table and set the operation to ENQUEUE(pkt); if the PSN is greater than the expected PSN, then set the operation to ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN), retransmitting the packet with the flow identifier tbl.flowID and the packet sequence number tbl.PSN; otherwise, if the PSN is less than the expected PSN, set the operation to ENQUEUE(pkt). Finally, return the corresponding operation.

[0028] Furthermore, the packet loss location mechanism based on selective retransmission is as follows: On the receiving end, the received events include: Arrived, Drop, and Timeout, specifically: Arrived (pkt): Data packet pkt has arrived; Drop(flowID, x): Receives a message that the packet with flow ID and number x has been dropped; Timeout(flowID, x): A message indicating that the timeout has occurred upon receiving a data packet with flowID and number x. The receiver maintains a two-dimensional stream state table (State), a one-dimensional expected receive stream table (expectPSM), and a one-dimensional maximum receive stream table (maxPSM). The first dimension of the two-dimensional flow status table is the flow identifier for each flow, and the second dimension is the packet sequence number. The entries include: "NOT_RECEIVED" (not received), "RECEIVED" (received), and "DROPPED" (discarded). The expected receive flow table expectPSM has the first dimension being the flow identifier for each flow, and the entries being the smallest unreceived packet sequence number.

[0029] The maximum received flow table maxPSM has the first dimension being the flow identifier for each flow, and the entries being the maximum received packet sequence number.

[0030] Based on different events, the receiving end updates its status and determines when and how to request a retransmission. The output retransmission notification includes: NACK (flowID, x): Informs the sender x and all subsequent retransmissions; SNACK (flowID, l,r): Instructs the sender to retransmit packets in the (l,r) range; The specific steps are as follows: First, upon receiving the Arrived (pkt) event: when packet pkt arrives, its hash index idx is calculated, and then it is checked whether State[idx][pkt.PSN] is not equal to RECEIVED. If they are not equal, State[idx][pkt.PSN] is set to RECEIVED, and maxPSM[idx] is updated to the maximum value between the current maximum PSN and the packet's PSN.

[0031] Secondly, for the drop event Drop(flowID, x), the hash index idx is also calculated. If State[idx][x] is not equal to RECEIVED, it is set to DROPPED and SNACK(flowID, x, x) is sent.

[0032] Finally, for the timeout event Timeout(flowID, x), calculate the hash index idx. If expectPSM[idx] equals maxPSM[idx] + 1, then send NACK(flowID, expectPSM[idx]); otherwise, iterate through the range from expectPSM[idx] to maxPSM[idx] and send SNACK(flowID, l, r) for each missing sequence number interval (l, r).

[0033] Beneficial effects The advantage of explicit notification packet loss inference mechanisms is that they can determine whether data packets were lost during transmission through explicit feedback information, thereby enabling the sender to resend lost data packets in a timely manner, ensuring the integrity and reliability of data transmission.

[0034] The advantage of the packet loss location mechanism of Selective Retransmission is that it allows the receiver to request the retransmission of only the lost packet when it detects packet loss, rather than the entire data stream. This can significantly improve the efficiency of network transmission and reduce unnecessary data retransmissions, thereby optimizing the use of network resources.

[0035] This invention introduces a packet loss inference mechanism based on explicit notification and a packet loss location mechanism based on selective retransmission, avoiding the inaccurate packet loss detection and inefficient batch retransmission of traditional schemes. It achieves adaptive and accurate retransmission and rapid selective confirmation retransmission, significantly increasing network throughput. According to simulation experiments, at a packet loss rate of 0.1%, the flow completion time of this invention is reduced by 24.8% compared to traditional algorithms, fully demonstrating its performance advantages in high-load network environments. Attached Figure Description

[0036] Figure 1This is a schematic diagram of the overall process of the method of the present invention; Figure 2 This is an overview diagram of the accurate data packet inference mechanism according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the loss notification frame format on the switch according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the retransmission notification frame format on the receiving end in an embodiment of the present invention; Figure 5 This is a schematic diagram of the comparative test network of the present invention; Figure 6 This is a performance comparison chart of different methods in the embodiments of the present invention. Detailed Implementation

[0037] The technical solution provided in this application will be further described below with reference to specific embodiments and accompanying drawings. The advantages and features of this application will become clearer from the following description.

[0038] The method of this invention is used in lossy networks employing ROCE technology, the network comprising: a sender, a switch, and a receiver.

[0039] The RoCE data packet typically contains the following fields: flowID: Flow identifier PSN: Package Serial Number SIP: Source IP address DIP: Destination IP address time: Sending time The switch uses a P4 architecture. It provides a refined and structured packet processing flow, typically including the following parts: (e.g.) Figure 2 ) Parser: The parser parses data packets according to a predefined format and extracts the various fields from the header. Ingress: The Ingress pipeline section, the entry point for data processing logic. TM: Traffic Manager, defines the core processing logic. Egress: The Egress pipeline section, the exit point for data processing logic. Deparser: Reassembles data packets To ensure compatibility with the aforementioned modern RoCE transmission mechanisms and to achieve the objectives of the invention, this invention provides a packet loss retransmission and reception method and system based on SACK (Selective Acknowledgment).

[0040] Example 1 below describes the overall packet loss retransmission and reception process. Examples 2 and 3 thereafter provide detailed explanations of the packet loss inference mechanism based on explicit notification and the packet loss location mechanism based on selective retransmission proposed in this invention.

[0041] Example 1 like Figure 1 It describes the overall packet loss retransmission and reception process.

[0042] When a data packet is sent into the network, if packet loss or errors occur, the switch sends a packet loss notification to the receiver (a packet loss inference mechanism based on explicit notification). Upon receiving the packet loss notification, the receiver sends a retransmission notification to the sender (a packet loss location mechanism based on selective retransmission). The sender then retransmits the corresponding data packet into the network, and the switch and receiver attempt to receive and verify it again.

[0043] This process repeats until all data packets are correctly received or the maximum number of retransmissions is reached.

[0044] This process ensures the reliability of data transmission and reduces the risk of communication interruption due to packet loss.

[0045] The packet loss retransmission and reception process is as follows: S1, the sender begins data transmission, sending data packets into the network.

[0046] Data packets are the basic unit of information transmission and may contain various forms of data such as text, images, audio, or video. At this stage, the sender sends data packets one by one to the target receiver according to a specific protocol. To ensure data integrity and reliability, the sender usually appends control information, such as sequence numbers and checksums, to the data packets so that the receiver can correctly identify and verify the received data.

[0047] S2. During transmission, data packets may pass through multiple network devices, such as routers and switches. Within these devices, packets may be dropped due to network congestion, link failures, or other reasons. When a switch detects a dropped packet, it sends a Notification of Loss (NACK) frame to the receiver. This is a packet loss inference mechanism based on explicit notification, designed to promptly inform the receiver that certain packets failed to arrive. Through this mechanism, the receiver can understand the network status in a timely manner and take appropriate measures to handle packet loss events.

[0048] S3. After receiving a packet loss notification, the receiving end sends an optional retransmission notification to the sending end. This process involves a packet loss location mechanism based on optional retransmission, where the receiving end will specify which data packets need to be retransmitted based on the status of the data packets it has already received.

[0049] The advantage of retransmission is that the sender only needs to retransmit the data packets that were actually lost, instead of retransmitting all the data, which effectively reduces network load and redundant transmission, and improves overall transmission efficiency.

[0050] S4. After receiving the Select Retransmission notification, the sender retransmits the lost data packets according to the notification content.

[0051] This process ensures data integrity and avoids retransmission of successfully received data, reducing network traffic and latency. When retransmitting data packets, the sender typically uses the same sequence number and control information so that the receiver can correctly identify and process the retransmitted packets.

[0052] Example 2 This embodiment creatively introduces a packet loss inference mechanism based on explicit notification on the switch side, effectively solving the problem of difficult packet loss judgment in traditional technologies.

[0053] On the switch side, the packet loss inference mechanism based on explicit notification mainly involves three modules: a packet loss detection module, an event handling module, and a notification generator module. For example... Figure 2 As shown. The packet loss detection module is responsible for determining whether a data packet will be dropped at the switch; the event handling module is responsible for inferring whether a data packet is lost at the link; after a data packet loss is detected, the notification generator module is responsible for generating a packet loss notification frame.

[0054] The packet loss detection module is responsible for obtaining the shared buffer / queue status at the switch's ingress queue and outputting whether the data packet will be dropped at the switch.

[0055] The specific steps are as follows: In a switch, each data packet passes through the traffic manager before entering the egress queue. The traffic manager is responsible for managing queues and traffic in the switch and maintaining statistics for each queue, including queue depth (i.e., the number of data packets in the queue).

[0056] An initial injection and continuous loop of a set of data packets, called a seed packet (one seed packet per queue), is performed. When seed packets arrive in the egress queue, the traffic manager will: 1. Obtain the exit queue to which the data packet belongs.

[0057] 2. Read the current queue depth of the exit queue.

[0058] 3. Add queue depth information to the metadata of the data packet.

[0059] When a data packet loops back to the ingress, the queue depth information from the packet metadata is directly written to the register. The depths of all queues at the ingress are summed to obtain the overall buffer pool utilization and size, which are then multiplied to calculate the remaining buffer pool space. The buffer pool utilization and size are calculated by the flow manager using existing technology.

[0060] If the remaining space is greater than the size of the data packet about to enter the buffer pool, the data packet can enter; otherwise, it will be dropped just before entering the buffer pool. This allows us to predict whether the data packet will be dropped at the switch. If it is dropped, we output "dropped"; otherwise, we output "not dropped".

[0061] The event handling module is responsible for maintaining the state of all flows passing through the switch to implicitly infer whether packets were lost at the link. The algorithm calculates a hash index based on the packet's flowID and takes appropriate action based on the packet loss situation.

[0062] This module primarily relies on the following mechanism: First, it receives the data packet pkt arriving at the switch's ingress queue. This packet contains a flow identifier (flowID) and a packet sequence number (PSN). Next, it maintains a congestion flow table (Flow_table), which includes the flow identifier (flowID), the expected packet sequence number (PSN), and the time (time) at which the flow was marked as congested. Then, based on the output of the packet loss detection module, it determines whether the data packet has been dropped and sets an expiration event threshold δ (50 μs in this embodiment). Finally, it generates an enumerated value `action` for the output operation based on the processing result. Possible operations include: ENQUEUE(pkt) (Enqueue packet to switch buffer): Enqueues packet pkt to switch buffer. ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN): Enqueues the packet pkt and sends the (flowID, PSN) information to the notification generator module, or DROP(pkt) (generates a packet loss notification). DROP(pkt): Discard packet pkt and send (pkt.flowID, pkt.PSN) information to the notification generator.

[0063] The specific steps are as follows: First, calculate the hash index idx based on the packet's flowID. If the packet is to be dropped (based on the output of the packet loss event collector), then check if the flow is in the congestion flow table Flow_table: If the flow is not in the table and the entry is empty or the information is outdated (the current time minus the time in the entry is greater than the threshold δ), then insert the flow information into the congested flow table and set the operation to DROP(pkt) to generate a packet loss notification. Otherwise, if a hash collision occurs, no action is taken. A hash collision means that another flow is in the congested flow table and has a hash collision with the current flow identifier. This invention defaults to continuing to monitor the first flow and ignoring the later flow, so no action is taken here.

[0064] If the flow is in the congestion flow table and the packet's PSN is equal to the expected PSN, update the time in the entry and set the operation to DROP(pkt) again; otherwise, do nothing.

[0065] If the packet will not be dropped and the flow is not in the congestion flow table, set the operation to ENQUEUE(pkt) and enqueue the packet into the switch buffer.

[0066] If the flow is in the congestion flow table and the packet's PSN equals the expected PSN, then remove the flow from the congestion flow table and set the operation to ENQUEUE(pkt); if the PSN is greater than the expected PSN, then set the operation to ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN), retransmitting the packet with the flow identifier tbl.flowID and the packet sequence number tbl.PSN; otherwise, if the PSN is less than the expected PSN, set the operation to ENQUEUE(pkt) (which may result in subsequent packet loss). Finally, return the appropriate operation.

[0067] The notification generator module is responsible for generating notifications such as... Figure 3 The packet loss notification frame shown includes the following fields: The KIND field indicates the frame type; in this module, it is 0xFA, indicating a packet loss notification frame. The LEN field is the frame length; in this module, it is 48, indicating 48 bits. The flowID field represents the flow identifier. The PSN field indicates the packet serial number. When the operation event handling module outputs the operation as DROP(pkt), the fields of the packet loss notification frame are: KIND=0xFA; LEN=48; flowID=pkt.flowID; PSN=pkt.PSN.

[0068] When the operation event handling module outputs the operation as ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN), the fields of the packet loss notification frame are: KIND=0xFA; LEN=48; flowID=tbl.flowID; PSN=tbl.PSN.

[0069] Example 3 The example describes a packet loss location mechanism based on selective retransmission, which is mainly deployed at the receiving end.

[0070] On the receiving end, the received events include: Arrived, Drop, and Timeout, specifically: Arrived (pkt): Data packet pkt has arrived. Drop(flowID, x): Receives a message indicating that the packet with flow ID x has been dropped. Timeout(flowID, x): A message indicating that the timeout occurred upon receiving the data packet with flowID and number x. The receiver maintains a two-dimensional flow state table (State), a one-dimensional expected receive flow table (expectPSM), and a one-dimensional maximum receive flow table (maxPSM).

[0071] The first dimension of the two-dimensional flow state table is the flow identifier for each flow, and the second dimension is the packet sequence number. The table entries include: "NOT_RECEIVED" (Not received) "RECEIVED" "DROPPED" The expected receive flow table expectPSM has the first dimension being the flow identifier for each flow, and the entries being the smallest unreceived packet sequence number.

[0072] And the maximum received flow table maxPSM, the first dimension of which is the flow identifier for each flow, and the entries are the maximum received packet sequence numbers.

[0073] Based on different events, the mechanism updates the state and determines when and how to request a retransmission. The output retransmission notification is as follows: NACK (flowID,x): Informs the sender x and all subsequent retransmissions.

[0074] SNACK (flowID, l, r): Instructs the sender to retransmit packets in the (l, r) interval. The SNACK frame format is as follows: Figure 4 .

[0075] The specific steps are as follows: First, upon receiving the Arrived (pkt) event: when packet pkt arrives, its hash index idx is calculated, and then it is checked whether State[idx][pkt.PSN] is not equal to RECEIVED. If they are not equal, State[idx][pkt.PSN] is set to RECEIVED, and maxPSM[idx] is updated to the maximum value between the current maximum PSN and the packet's PSN.

[0076] Secondly, for the drop event Drop(flowID, x), the hash index idx is also calculated. If State[idx][x] is not equal to RECEIVED, it is set to DROPPED and SNACK(flowID, x, x) is sent. The time limit can also be adjusted.

[0077] Finally, for the timeout event Timeout(flowID, x), calculate the hash index idx. If expectPSM[idx] equals maxPSM[idx] + 1, then send NACK(flowID, expectPSM[idx]); otherwise, iterate through the range from expectPSM[idx] to maxPSM[idx] and send SNACK(flowID, l, r) for each missing sequence number interval (l, r).

[0078] Retransmission notification frame (SNACK frame) such as Figure 4 As shown, it mainly includes the following fields: The KIND field indicates the frame type; in this module, it is 0xFB, indicating a retransmission notification frame. The LEN field is the frame length; in this module, it is 64, indicating 64 bits. The flowID field represents the flow identifier. The (PSNL, PSNR) field represents the packet sequence number range (PSNL, PSNR). When the operation is SNACK(flowID, l, r), the fields of the packet loss notification frame are: KIND=0xFB; LEN=64; flowID=flowID; (PSNL, PSNR)=(l, r).

[0079] Compared to traditional selective repeat techniques (such as the TCP protocol), the present invention does not require notifying the sender of the reception status of all data packets. By using lightweight retransmission notification frames, transmission overhead is greatly reduced.

[0080] Comparative experiment Modeling experiments were conducted using the NS-3 simulator. A leaf-ridge topology network was used, consisting of three layers: (e.g.) Figure 5 ) The spine switches (S0~Sm-1) are interconnected with the external network, and the input and output bandwidths of the spine switches are equal.

[0081] Leaf switches (L0~Lk-1) connect all spine switches and n servers. All leaf switches and spine switches form a fully connected bipartite graph. The input bandwidth between leaf switches and spine switches is equal; the input bandwidth between leaf switches and servers is equal.

[0082] The input and output bandwidths between the server and the leaf switch are equal.

[0083] like Figure 5 As shown in the experimental topology, each leaf switch connects to two servers. The bandwidth between the server and the leaf switch is 40Gbps, and the link latency is 0.001ms. The bandwidth between the leaf switch and the spine switch is 100Gbps, and the link latency is 0.001ms.

[0084] To simulate real network traffic, the traffic characteristics of MS_WebSearch were used to generate traffic with 60% link load and random traffic for 0.1 seconds.

[0085] This invention was compared with the following algorithms: Traditional RoCE packet loss recovery algorithm: relies on implicit inference to determine whether a data packet has been dropped. This means that a data packet is considered dropped as long as it is out of order or times out. When retransmitting, it adopts the Go-Back-N protocol, that is, if the data packet is considered to have been dropped, the receiver will ask the sender to retransmit the expected packet and all subsequent packets.

[0086] Segment Loss Recovery (SLR) algorithm: It uses the switch's limited location capabilities to actively notify the sender to help determine whether out-of-order packets are due to the loss of expected packets or slow transmission. During retransmission, it adopts the Go-Back-N protocol, that is, if it is believed that a data packet has been lost, the receiver will ask the sender to retransmit the expected packet and all subsequent packets.

[0087] The SACK-RoCE algorithm relies on implicit inference to determine whether a data packet has been dropped. This means that a data packet is considered dropped as long as it is out of order or times out. When the number of detected "gap segments" reaches 3, it is considered a packet loss and a select acknowledgment frame is sent. However, if the number of "gap segments" exceeds 3, subsequent "gap segments" are still retransmitted in the form of Go-Back-N.

[0088] Use FCT (flow completion time) as a comparison metric.

[0089] The experimental results are as follows Figure 6 As shown, under a medium-high network load of 60%, this invention exhibits superior transmission performance: at a packet loss rate of 0.01%, its flow completion time (FCT) increases by only 0.2% compared to a lossless network; when the packet loss rate rises to 0.1%, the increase in flow completion time is only 0.9%; even under a high packet loss rate of 1%, the flow completion time only increases slightly by 2.3%, demonstrating transmission efficiency close to that of a lossless network. This performance significantly outperforms other comparative algorithms—the traditional algorithm experiences a 350% surge in flow completion time at a 1% packet loss rate, the SLR algorithm increases by 264%, and the SACK-RoCE algorithm increases by 90%. Particularly noteworthy is that at a 0.1% packet loss rate, the flow completion time of this invention is reduced by 24.8% compared to the traditional algorithm, 4.6% compared to the SACK-RoCE algorithm, and 22.1% compared to the SLR algorithm, fully demonstrating its performance advantages in high-load network environments.

[0090] The above description is merely a description of preferred embodiments of this application and is not intended to limit the scope of this application in any way. Any changes or modifications made by those skilled in the art based on the above-disclosed technical content should be considered as equivalent and valid embodiments and fall within the scope of protection of the technical solution of this application.

Claims

1. A packet loss retransmission and reception method based on SACK, characterized in that, include: Packet loss inference mechanism based on explicit notification and packet loss location mechanism based on selective retransmission; The packet loss inference mechanism based on explicit notification is applied to a switch; An explicit packet loss notification solution is adopted to ensure that packet loss reports are only generated under specific conditions: when a data packet is dropped at an intermediate switch due to excessive network pressure, the switch actively sends a packet loss notification to the receiving end. The packet loss location mechanism based on selective repeat is applied at the receiving end, which accurately describes which data packets were not received within a data transmission interval, thereby supporting the retransmission of specific data packets; at the same time, a selective acknowledgment mechanism is adopted, allowing the receiving end to report back to the sending end which data packets were successfully received.

2. The SACK-based packet loss retransmission and reception method according to claim 1, characterized in that, The packet loss retransmission and reception process is as follows: S1, the sender begins data transmission, sending data packets to the network; S2, During data packet transmission, when the switch detects that a data packet has been dropped based on the packet loss inference mechanism of explicit notification, it sends a packet loss notification frame to the receiving end. S3. After receiving the packet loss notification frame, the receiving end sends an optional retransmission notification to the sender based on the packet loss location mechanism of optional retransmission. The receiving end specifies which data packets need to be retransmitted based on the status of the data packets it has already received. S4. After receiving the Select Retransmission notification, the sender retransmits the lost data packets according to the notification content.

3. The SACK-based packet loss retransmission and reception method according to claim 1, characterized in that, The packet loss inference mechanism based on explicit notification is implemented in the switch and includes three modules: packet loss detection module, event processing module, and notification generator module. The packet loss detection module is responsible for determining whether data packets will be dropped at the switch; The event handling module is responsible for determining whether data packets are lost at the link. The notification generator module is responsible for generating packet loss notification frames. After the packet loss detection module or event handling module detects packet loss in the switch or link, the notification generator module generates a packet loss notification frame and provides it to the receiving end.

4. The SACK-based packet loss retransmission and reception method according to claim 3, characterized in that, The packet loss detection module is responsible for obtaining the shared buffer / queue status at the switch ingress queue and outputting whether the data packet will be dropped at the switch. The packet loss detection module calculates the remaining buffer pool space by multiplying the utilization rate of the entire buffer pool by the size of the buffer pool. If the remaining space is greater than the size of the data packet that is about to enter the buffer pool, the data packet can enter; otherwise, it will be dropped when it is about to enter the buffer pool. Based on this, it infers whether the data packet will be dropped at the switch. If it is dropped, it outputs "dropped"; otherwise, it outputs "not dropped".

5. The SACK-based packet loss retransmission and reception method according to claim 3, characterized in that, The packet loss notification frame includes the following fields: The KIND field indicates the frame type. In this module, it is 0xFA, which means it is a packet loss notification frame. LEN field: Frame length, which is 48 in this module, indicating 48 bits; The flowID field represents the flow identifier; PSN field: Represents the packet serial number; When the operation event handling module outputs the operation as DROP(pkt), the fields of the packet loss notification frame are: KIND=0xFA; LEN=48; flowID=pkt.flowID; PSN=pkt.PSN; When the operation event handling module outputs the operation as ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN), the fields of the packet loss notification frame are: KIND=0xFA; LEN=48; flowID=tbl.flowID; PSN=tbl.PSN.

6. The SACK-based packet loss retransmission and reception method according to claim 3, characterized in that, The event handling module is responsible for maintaining the state of all flows passing through the switch to implicitly infer whether data packets are lost at the link. The event handling module calculates the hash index based on the flowID of the data packet and takes appropriate action based on the packet loss situation, as follows: First, the packet pkt that arrives at the switch ingress queue is received. This packet contains the flow identifier flowID and the packet sequence number PSN. Next, maintain the congestion flow table Flow_table, which includes the flow identifier flowID, the expected packet sequence number PSN, and the time when the flow was marked as congested; Subsequently, based on the output of the packet loss detection module, it is determined whether the data packet has been dropped, and the expiration event threshold δ is set. Finally, output operations are generated based on the processing results, including: Enqueue the data packet pkt into the switch buffer; Enqueue the packet pkt and send the (flowID, PSN) information to the notification generator module, or DROP(pkt) to generate a packet loss notification; Discard the packet pkt and send the (pkt.flowID, pkt.PSN) information to the notification generator; The specific steps are as follows: First, calculate the hash index idx based on the packet's flowID; if the packet is to be dropped, check if the flow is in the congestion flow table Flow_table: If the flow is not in the table and the entry is empty or the information is outdated, insert the flow information into the congested flow table and set the operation to DROP(pkt) to generate a packet loss notification; Otherwise, if a hash collision occurs, no action is taken; If the flow is in the congestion flow table and the packet's PSN is equal to the expected PSN, update the time in the entry and set the operation to DROP(pkt) again; otherwise, do nothing. If the packet will not be dropped and the flow is not in the congestion flow table, set the operation to ENQUEUE(pkt) and enqueue the packet into the switch buffer. If the flow is in the congestion flow table and the packet's PSN equals the expected PSN, then remove the flow from the congestion flow table and set the operation to ENQUEUE(pkt); if the PSN is greater than the expected PSN, then set the operation to ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN), retransmitting the packet with the flow identifier tbl.flowID and the packet sequence number tbl.PSN; otherwise, if the PSN is less than the expected PSN, set the operation to ENQUEUE(pkt); finally, return the corresponding operation.

7. The SACK-based packet loss retransmission and reception method according to claim 1, characterized in that, The packet loss location mechanism based on selective retransmission is as follows: On the receiving end, the received events include: Arrived, Drop, and Timeout, specifically: Arrived (pkt): Data packet pkt has arrived; Drop(flowID, x): Receives a message that the packet with flow ID and number x has been dropped; Timeout(flowID, x): A message indicating that the timeout has occurred upon receiving a data packet with flowID and number x. The receiver maintains a two-dimensional stream state table (State), a one-dimensional expected receive stream table (expectPSM), and a one-dimensional maximum receive stream table (maxPSM). The first dimension of the two-dimensional flow status table is the flow identifier of each flow, and the second dimension is the packet sequence number. The table entries include: "NOT_RECEIVED" not received, "RECEIVED" received, and "DROPPED" discarded. The expected receive flow table expectPSM has the first dimension being the flow identifier for each flow, and the entry is the smallest unreceived packet sequence number. The maximum received flow table maxPSM has the first dimension being the flow identifier for each flow, and the entries being the maximum received packet sequence number. Based on different events, the receiving end updates its status and determines when and how to request a retransmission; the output retransmission notification includes: NACK (flowID, x): Informs the sender x and all subsequent retransmissions; SNACK (flowID, l,r): Instructs the sender to retransmit packets in the (l,r) range; The specific steps are as follows: First, upon receiving the Arrived (pkt) event: when packet pkt arrives, calculate its hash index idx, and then check if State[idx][pkt.PSN] is not equal to RECEIVED; if not, set State[idx][pkt.PSN] to RECEIVED and update maxPSM[idx] to the maximum value between the current maximum PSN and the packet's PSN. Secondly, for the drop event Drop(flowID, x), the hash index idx is also calculated. If State[idx][x] is not equal to RECEIVED, it is set to DROPPED and SNACK(flowID, x, x) is sent. Finally, for the timeout event Timeout(flowID, x), calculate the hash index idx. If expectPSM[idx] equals maxPSM[idx] + 1, then send NACK(flowID, expectPSM[idx]); otherwise, iterate through the range from expectPSM[idx] to maxPSM[idx] and send SNACK(flowID, l, r) for each missing sequence number interval (l, r).

8. The SACK-based packet loss retransmission and reception method according to claim 7, characterized in that, The SNACK frame includes the following fields: The KIND field indicates the frame type. In this module, it is 0xFB, which means it is a retransmission notification frame. LEN field: Frame length, which is 64 in this module, indicating 64 bits; The flowID field represents the flow identifier; The (PSNL, PSNR) field represents the packet sequence number range (PSNL, PSNR). When the operation is SNACK(flowID, l, r), the fields of the packet loss notification frame are: KIND=0xFB; LEN=64; flowID=flowID; (PSNL, PSNR)=(l, r).

Images