Sack-based packet loss retransmission and receiving method

Abstract

The application belongs to the technical field of data communication, and particularly relates to a packet loss retransmission and receiving method based on SACK. The method comprises a packet loss inference mechanism based on explicit notification and a packet loss positioning mechanism based on selective retransmission. The packet loss inference mechanism based on explicit notification is applied to a switch and aims to optimize packet loss processing in a data transmission process. The core of the mechanism is to adopt a solution of explicit packet loss notification to ensure that packet loss reporting is only performed under specific conditions. The packet loss positioning mechanism based on selective retransmission is applied to a receiving end and realizes effective management of lost data packets through accurate positioning. The application introduces the packet loss inference mechanism based on explicit notification and the packet loss positioning mechanism based on selective retransmission, avoids inaccurate packet loss detection and inefficient batch retransmission of a traditional scheme, realizes adaptive accurate retransmission and fast selective acknowledgement retransmission, and greatly increases network transmission throughput.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of data communication, and particularly relates to a packet loss retransmission and receiving method based on SACK. BACKGROUND

[0002] RoCE (RDMA over Converged Ethernet) is a specification method for deploying RDMA in an Ethernet-based data center. Traditionally, RoCE runs on a lossless network by default and does not have a reliability guarantee mechanism itself.

[0003] To achieve reliable guarantee in a lossy network, the traditional scheme uses the Go-Back-N algorithm to provide reliability guarantee, but this protocol retransmits a large number of data packets when packet loss occurs, resulting in a significant reduction in transmission efficiency. According to mathematical reasoning, when the packet loss rate reaches 1%, the throughput of RoCE will decrease by nearly 80%; according to experiments, the 99% delay of a normal network flow under RoCE is only 329us, but a network flow that needs to be retransmitted due to timeout results in a 99% delay of up to 30ms.

[0004] Specifically, the traditional scheme has deficiencies in two aspects:

[0005] It is difficult to determine packet loss: the traditional scheme relies on implicit inference of whether a packet is lost. When the following situations occur, it is considered that the packet has been lost: the packet is not received within the timeout or an out-of-order packet is received. However, such a traditional scheme has false positives, such as when network congestion causes slow data packet transmission, which is also considered as packet loss.

[0006] It is difficult to accurately locate packet loss: the traditional scheme only locates in batches and needs to retransmit a large number of packets. Once packet loss occurs, the receiver sends NACK x indicating that packets with sequence numbers x and subsequent packets have not been received, and requires retransmission of all subsequent packets. This will result in redundant retransmission and exacerbate network congestion, thereby greatly reducing network transmission efficiency.

[0007] In summary, since RDMA was originally run on a lossless network, its packet loss recovery mechanism is not efficient, and ROCE also follows the old packet loss recovery mechanism. At the same time, since early switches do not have programmable capabilities, it is difficult to monitor packet loss on the switch. Therefore, under the existing mechanism, once packet loss occurs, it will greatly reduce the network transmission efficiency. SUMMARY

[0008] In view of the shortcomings of the prior art described above, the purpose of the present application is to provide a SACK (Selective Acknowledgment) based packet loss retransmission and receiving method to solve the problem of insufficient reliability of the existing ROCE technology in a lossy network, improve the reliable transmission capability of RoCE (RDMA over Converged Ethernet), and enable it to run efficiently in a lossy intelligent cluster network, breaking through the limitations of the lossless network environment. The present application contains two aspects, which respectively improve the two existing deficiencies of the background technology traditional scheme.

[0009] Technical scheme

[0010] A SACK based packet loss retransmission and receiving method, comprising: an explicit notification based packet loss inference mechanism and a selective retransmission based packet loss positioning mechanism.

[0011] The explicit notification based packet loss inference mechanism aims to optimize the processing of packet loss in the data transmission process and is applied to switches. The core of this mechanism is to adopt an explicit packet loss notification solution to ensure that packet loss reporting is only performed under certain conditions. Specifically, when a data packet is discarded at an intermediate switch due to excessive network pressure, the switch actively sends a packet loss notification to the receiving end.

[0012] This method effectively avoids false positives, and because it only sends notifications when the data packet is actually lost, it reduces unnecessary retransmission requests. Through this mechanism, the overall burden of the network is reduced, improving transmission efficiency and reducing the delay caused by repeated data transmission due to network instability.

[0013] In this process, communication between the sender and the receiver becomes more efficient. After receiving the packet loss notification, the sender can perform targeted retransmission according to actual needs, 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 notification ensures that the network can better adjust itself under high load conditions, thereby improving overall performance.

[0014] The selective retransmission based packet loss positioning mechanism is applied to the receiving end, which accurately describes which data packets in a certain data transmission interval have not been received, 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 feedback to the sender which data packets have been successfully received.

[0015] This method enables the sender to quickly identify and retransmit those packets that are actually lost, avoiding redundant transmission.

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

[0017] When the receiving end receives the data packet, it records its state and sends the un-received data packet sequence number to the sending end through the SNACK frame when packet loss occurs. Such a feedback mechanism enables the sending end to master the data transmission state in real time, thereby making targeted responses.

[0018] A SACK-based packet loss retransmission and receiving method, and the packet loss retransmission and receiving process is as follows:

[0019] S1, the sending end starts data transmission and sends data packets to the network;

[0020] S2, during the data packet transmission process, when the switch discovers that a data packet is discarded based on the explicit notification-based packet loss inference mechanism, it sends a packet loss notification frame (NACK) to the receiving end;

[0021] S3, after the receiving end receives the packet loss notification frame, it sends a selective repeat notification to the sending end based on the selective repeat-based packet loss positioning mechanism. The receiving end explicitly indicates which data packets need to be retransmitted according to the state of the data packets it has received;

[0022] S4, after the sending end receives the selective repeat notification, it retransmits the missing data packets according to the notification content.

[0023] Further, the explicit notification-based packet loss inference mechanism is implemented in the switch, including three modules: a packet loss detection module, an event processing module, and a notification generator module.

[0024] The packet loss detection module is responsible for determining whether a data packet will be discarded at the switch;

[0025] The event processing module is responsible for inferring whether a data packet is lost at the link;

[0026] The notification generator module is responsible for generating a packet loss notification frame.

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

[0028] Further, the packet loss detection module is responsible for obtaining the shared buffer / queue state at the switch ingress queue and outputting whether a data packet will be discarded at the switch;

[0029] Specifically, the packet loss detection module calculates the remaining buffer pool space by multiplying the utilization rate of the entire buffer pool and the buffer pool size.

[0030] If the remaining space is greater than the size of the packet about to enter the buffer pool, the packet can enter, otherwise it will be discarded upon entering the buffer pool. Thus, it can be inferred whether the packet will be discarded at the switch, and if so, "discarded" is output, otherwise "not discarded" is output.

[0031] Further, the event processing module is responsible for maintaining the state of all flows passing through the switch to implicitly infer whether a packet is lost at the link.

[0032] The event processing module computes a hash index according to the flowID of the packet, and makes corresponding processing according to the packet loss condition.

[0033] The specific processing is as follows: first, a data packet pkt arriving at the ingress queue of the switch is received, which contains a flow identifier flowID and a packet sequence number PSN. Next, a congestion flow table Flow_table is maintained, which includes a flow identifier flowID, an expected packet sequence number PSN, and a time at which the flow is marked as congested. Subsequently, it is determined whether the packet is discarded according to the output of the packet loss detection module, and an expiration event threshold δ is set. Finally, an output operation is generated according to the processing result, including: enqueuing the data packet pkt to 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); discarding the data packet pkt and sending the (pkt.flowID, pkt.PSN) information to the notification generator.

[0034] The specific steps are as follows:

[0035] First, a hash index idx is computed according to the flowID of the packet. If the packet is to be discarded (according to the output of the packet loss event collector), it is checked whether the flow is in the congestion flow table Flow_table:

[0036] If the flow is not in the table and the table entry is empty or the information is outdated (the current time minus the time in the table entry is greater than the threshold δ), the information of the flow is inserted into the congestion flow table and the operation is set to DROP(pkt) to generate a packet loss notification;

[0037] Otherwise, if a hash collision occurs, no operation is taken.

[0038] If the flow is in the congestion flow table, and the PSN of the packet is equal to the expected PSN, the time in the table entry is updated and the operation is set to DROP(pkt) again; if not, no operation is taken.

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

[0040] If the flow is in the congestion flow table and the PSN of the packet is equal to the expected PSN, remove the flow from the congestion flow table and set the operation to ENQUEUE (pkt); if the PSN is greater than the expected PSN, set the operation to ENQUEUE_NACK (pkt, tbl.flowID, tbl.PSN) to retransmit the packet with flow identifier tbl.flowID and 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.

[0041] Further, the packet loss positioning mechanism based on selective retransmission is as follows:

[0042] At the receiving end, the received events include: Arrived, Drop, Timeout, and specifically:

[0043] Arrived (pkt): the packet pkt arrives;

[0044] Drop (flowID, x): the message that the packet numbered x of the flow numbered flowID is dropped is received;

[0045] Timeout (flowID, x): the message that the packet numbered x of the flow numbered flowID times out is received;

[0046] The receiving end maintains a two-dimensional flow state table State, a one-dimensional expected receiving flow table expectPSM, and a one-dimensional maximum receiving flow table maxPSM.

[0047] The first dimension of the two-dimensional flow state 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" (dropped).

[0048] The expected receiving flow table expectPSM has the flow identifier of each flow as the first dimension, and the smallest unreceived packet sequence number as the table entry.

[0049] The maximum receiving flow table maxPSM has the flow identifier of each flow as the first dimension, and the largest received packet sequence number as the table entry.

[0050] According to different events, the receiving end updates the state and decides when and how to request retransmission. The output retransmission notification includes:

[0051] NACK (flowID,x) : informs sender x and all subsequent retransmissions;

[0052] SNACK (flowID, l,r): informs sender to retransmit packets in interval (l,r);

[0053] The specific steps are as follows:

[0054] First, at the reception event Arrived (pkt): when the data 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 of the current maximum PSN and the PSN of the data packet.

[0055] Second, for the discard event Drop(flowID, x), calculate the hash index idx, and if State[idx][x] is not equal to RECEIVED, set it to DROPPED, and send SNACK(flowID, x, x).

[0056] Finally, for the timeout event Timeout(flowID, x), calculate the hash index idx, and if expectPSM[idx] is equal to maxPSM[idx]+1, send NACK(flowID, expectPSM[idx]); otherwise, traverse the range from expectPSM[idx] to maxPSM[idx], and for each missing sequence number interval (l,r), send SNACK(flowID, l, r).

[0057] Advantages

[0058] The advantage of the explicit notification packet loss inference mechanism is that it can determine whether the data packet is lost during transmission through explicit feedback information, so that the sender can retransmit the lost data packet in time, ensuring the integrity and reliability of data transmission.

[0059] The advantage of the selective retransmission packet loss positioning mechanism is that it allows the receiver to request retransmission of only the specific data packet that is lost when detecting data packet loss, rather than the entire data stream, which can significantly improve the efficiency of network transmission and reduce unnecessary data retransmission, thereby optimizing the use of network resources.

[0060] The application introduces an explicit notification-based packet loss inference mechanism and a selective retransmission-based packet loss positioning mechanism, avoids inaccurate packet loss detection and inefficient batch retransmission of the traditional scheme, realizes adaptive accurate retransmission and fast selective acknowledgement retransmission, and greatly increases the network transmission throughput. According to simulation experiments, the flow completion time of the application is reduced by 24.8% compared with the traditional algorithm under a 0.1% packet loss rate, which fully shows the performance advantage of the application in a high-load network environment. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 It is a schematic diagram of the overall process of the method of the application.

[0062] Figure 2 It is a schematic diagram of the precise inference mechanism of the lost data packet of the embodiment of the application.

[0063] Figure 3 It is a schematic diagram of the lost notification frame format on the switch of the embodiment of the application.

[0064] Figure 4 It is a schematic diagram of the retransmission notification frame format on the receiving end of the embodiment of the application.

[0065] Figure 5 It is a schematic diagram of the comparative test network of the application.

[0066] Figure 6 It is a performance comparison diagram of different methods of the embodiment of the application. DETAILED DESCRIPTION

[0067] The technical solutions provided by the application will be further described below in combination with specific embodiments and their accompanying drawings. The advantages and features of the application will be clearer in combination with the following description.

[0068] The method of the application is used in a lossy network using ROCE technology, and the network includes a sender, a switch and a receiver.

[0069] The RoCE data packet generally includes the following fields:

[0070] flowID: flow identifier

[0071] PSN: packet sequence number

[0072] SIP: source IP address

[0073] DIP: destination IP address

[0074] time: sending time

[0075] The switch uses a P4 architecture. It provides a refined and structured data packet processing flow, which usually includes the following parts: (such as Figure 2 )

[0076] Parser: Parser, parses the data packet according to the pre-defined format, and extracts the fields of the header

[0077] Ingress: Ingress pipeline part, entrance of data processing logic

[0078] TM: Traffic Manager, defines the core processing logic

[0079] Egress: Egress pipeline part, exit of data processing logic

[0080] Deparser: reassembles the data packet

[0081] To be compatible with the above modern RoCE transmission mechanism, and to achieve the purpose of the application, the application provides a packet loss retransmission and receiving method and system based on SACK (selective acknowledgement).

[0082] The following embodiment 1 describes the overall packet loss retransmission and receiving process. Embodiments 2-3 are described in detail for the packet loss inference mechanism based on explicit notification and the packet loss positioning mechanism based on selective retransmission proposed by the application.

[0083] Embodiment 1

[0084] As Figure 1 , the overall packet loss retransmission and receiving process is described.

[0085] The sending direction sends data packets in the network, and if there is a packet loss or error packet, the switch will send a packet loss notification to the receiving side (packet loss inference mechanism based on explicit notification). After receiving the packet loss notification, the receiving side will send a retransmission notification to the sending side (packet loss positioning mechanism based on selective retransmission). The sending side will resend the corresponding data packet to the network, and the switch and the receiving side will try to receive and verify again.

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

[0087] This process ensures the reliability of data transmission and reduces the risk of communication interruption caused by packet loss.

[0088] The packet loss retransmission and receiving process is as follows:

[0089] S1, the sending side starts data transmission and sends data packets to the network.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

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

[0095] 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.

[0096] Example 2

[0097] 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.

[0098] 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.

[0099] The packet loss detection module is responsible for obtaining the shared buffer / queue state at the ingress queue of the switch and outputting whether the data packet will be dropped at the switch.

[0100] The specific steps are as follows:

[0101] In the switch, each data packet will pass through the traffic manager before entering the egress queue. The traffic manager is responsible for managing the queues and traffic in the switch and maintaining the statistical information of each queue, including the queue depth (i.e., the number of data packets in the queue).

[0102] A set of data packets, called seed data packets (one seed data packet for each queue), are initially injected and continuously looped.

[0103] When the seed data packet arrives at the egress queue, the traffic manager will:

[0104] 1. Obtain the egress queue to which the data packet belongs.

[0105] 2. Read the current queue depth of the egress queue.

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

[0107] In this way, when the data packet is looped back to the ingress, the queue depth information in the metadata of the data packet is used to directly write to the register. The depths of all queues at the ingress are added up to obtain the utilization rate and buffer pool size of the entire buffer pool, and then the remaining buffer pool space is calculated by multiplying them. The utilization rate and buffer pool size of the buffer pool are calculated by the traffic manager, and the calculation method is the prior art.

[0108] 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 discarded when it is about to enter the buffer pool. In this way, it can be inferred whether the data packet will be dropped at the switch, and if it is dropped, it outputs "dropped", otherwise it outputs "not dropped".

[0109] The event handling module is responsible for maintaining the state of all flows passing through the switch to implicitly infer whether the data packet is lost at the link. The algorithm calculates the hash index according to the flowID of the data packet and makes corresponding processing according to the packet loss situation.

[0110] The module relies on the following mechanisms: The method first receives a packet pkt arriving at the ingress queue of the switch, which contains a flow identifier flowID and a packet sequence number PSN. Next, a congestion flow table Flow_table is maintained, which includes the flow identifier flowID, the expected packet sequence number PSN, and the time at which the flow is marked as congested. Then, it is determined whether the packet is dropped according to the output of the packet loss detection module, and an expiration event threshold δ (50 μs in this embodiment) is set. Finally, an enumerated value action of the output operation is generated according to the processing result, and possible operations include:

[0111] ENQUEUE(pkt) (enqueue the packet to the switch buffer): enqueue the packet pkt to the switch buffer

[0112] ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN) (enqueue the packet pkt and send (flowID, PSN) information to the notification generator module), or DROP(pkt) (generate a packet loss notification)

[0113] DROP(pkt): discard the packet pkt and send (pkt.flowID, pkt.PSN) information to the notification generator.

[0114] The specific steps are as follows:

[0115] First, calculate the hash index idx according to the flowID of the packet. If the packet is to be discarded (according to the output of the packet loss event collector), check whether the flow is in the congestion flow table Flow_table:

[0116] If the flow is not in the table and the table entry is empty or the information is outdated (the current time minus the time in the table entry is greater than the threshold δ), insert the information of the flow into the congestion flow table and set the operation as DROP(pkt) to generate a packet loss notification.

[0117] Otherwise, if a hash collision occurs, no operation is taken. A hash collision means that another flow is in the congestion flow table and has a hash collision with the current flow identifier. The present application defaults to continue monitoring the former flow and ignores the latter flow, so no operation is taken here.

[0118] If the flow is in the congestion flow table and the PSN of the packet is equal to the expected PSN, update the time in the table entry and set the operation as DROP(pkt) again; if not, no operation is taken.

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

[0120] If the flow is in the congestion flow table and the PSN of the packet is equal to the expected PSN, remove the flow from the congestion flow table and set the action to ENQUEUE (pkt). If the PSN is greater than the expected PSN, set the action to ENQUEUE_NACK (pkt, tbl.flowID, tbl.PSN) and retransmit the packet with flow identifier tbl.flowID and packet sequence number tbl.PSN. Otherwise, if the PSN is less than the expected PSN, set the action to ENQUEUE (pkt) (which can be dropped later). Finally, return the corresponding action.

[0121] The notification generator module is responsible for generating the lost packet notification frame as shown in Fig. 3. Figure 3 The lost packet notification frame includes the following fields:

[0122] The KIND field indicates the frame type, which is 0xFA in this module, indicating that it is a lost packet notification frame

[0123] The LEN field is the frame length, which is 48 in this module, indicating 48 bits

[0124] The flowID field indicates the flow identifier

[0125] The PSN field indicates the packet sequence number

[0126] When the action event processing module outputs the action DROP (pkt), the fields of the lost packet notification frame are: KIND = 0xFA; LEN = 48; flowID = pkt.flowID; PSN = pkt.PSN.

[0127] When the action event processing module outputs the action ENQUEUE_NACK (pkt, tbl.flowID, tbl.PSN), the fields of the lost packet notification frame are: KIND = 0xFA; LEN = 48; flowID = tbl.flowID; PSN = tbl.PSN.

[0128] Embodiment 3

[0129] The embodiment describes a lost packet positioning mechanism based on selective retransmission, mainly deployed at the receiving end.

[0130] At the receiving end, the received events include: Arrived, Drop, Timeout, which are as follows:

[0131] Arrived (pkt) : The packet pkt arrives

[0132] Drop (flowID, x): message that packet number x of flow number flowID is dropped

[0133] Timeout (flowID, x): message that packet number x of flow number flowID is timed out

[0134] 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.

[0135] Wherein, the first dimension of the two-dimensional flow state table is the flow identifier of each flow, and the second dimension is the packet sequence number, and the table entry includes:

[0136] “NOT_RECEIVED”

[0137] “RECEIVED”

[0138] “DROPPED”

[0139] The expected receive flow table expectPSM has the flow identifier of each flow as the first dimension, and the minimum un-received packet sequence number as the table entry.

[0140] And the maximum receive flow table maxPSM has the flow identifier of each flow as the first dimension, and the maximum received packet sequence number as the table entry.

[0141] According to different events, the mechanism updates the state and decides when and how to request retransmission. The output retransmission notification is:

[0142] NACK (flowID, x): informs the sender to resend x and all subsequent packets.

[0143] SNACK (flowID, l, r): informs the sender to resend packets in the interval (l, r), and the SNACK frame format is as follows Figure 4 .

[0144] The specific steps are as follows:

[0145] First, at the reception event Arrived (pkt): when the data packet pkt arrives, calculate its hash index idx, and then check whether 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 of the current maximum PSN and the PSN of the data packet.

[0146] Second, 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 a SNACK(flowID, x, x) is sent, and the time limit can be adjusted.

[0147] Finally, for the timeout event Timeout(flowID, x), the hash index idx is calculated, if expectPSM[idx] is equal to maxPSM[idx]+1, a NACK(flowID, expectPSM[idx]) is sent, otherwise, the range from expectPSM[idx] to maxPSM[idx] is traversed, and for each missing sequence number interval (l, r), a SNACK(flowID, l, r) is sent.

[0148] The retransmission notification frame (SNACK frame) is as shown in Figure 4 The main fields include:

[0149] The KIND field indicates the frame type, the module is 0xFB, indicating that it is a retransmission notification frame

[0150] The LEN field is the frame length, the module is 64, indicating 64 bits

[0151] The flowID field indicates the flow identifier

[0152] The (PSNL, PSNR) field indicates the packet sequence number interval (PSNL, PSNR)

[0153] 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).

[0154] Compared with the traditional selective retransmission technology (such as the TCP protocol), the scheme of the application does not need to notify the sender of the acceptance of all data packets, and by using a lightweight retransmission notification frame, the transmission overhead is greatly reduced.

[0155] Comparative experiment

[0156] Modeling experiments are performed using the NS-3 simulator. A leaf-spine topology network is used, which is divided into three layers: (as Figure 5 )

[0157] The spine switches (S0~Sm-1) are interconnected with external networks, and the input and output bandwidths of the spine switches are equal.

[0158] 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.

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

[0160] 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.

[0161] 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.

[0162] This invention was compared with the following algorithms:

[0163] 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.

[0164] 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.

[0165] 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.

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

[0167] Experimental results are as follows Figure 6As shown, under the condition of 60% medium-high network load, the application exhibits excellent transmission performance: when the packet loss rate is 0.01%, the flow completion time (FCT) of the application increases by only 0.2% compared with that of the lossless network; when the packet loss rate increases to 0.1%, the increase of the flow completion time is only 0.9%; even in the environment of 1% high packet loss rate, the flow completion time only increases by 2.3%, showing transmission efficiency close to that of the lossless network. This performance is significantly better than that of other comparative algorithms: the flow completion time of the traditional algorithm increases by 350% at 1% packet loss rate, the flow completion time of the SLR algorithm increases by 264%, and the flow completion time of the SACK-RoCE algorithm increases by 90%. It is particularly worth noting that at 0.1% packet loss rate, the flow completion time of the application is reduced by 24.8% compared with that of the traditional algorithm, reduced by 4.6% compared with that of the SACK-RoCE algorithm, and reduced by 22.1% compared with that of the SLR algorithm, fully showing the performance advantage of the application in the high-load network environment.

[0168] The above description is only a description of the preferred embodiments of the present application, and is not any limitation on the scope of the present application. Any modification or change made by any person skilled in the art according to the above disclosed technical content should be regarded as an equivalent effective embodiment, and belongs to the protection scope of the technical scheme of the present application.

Claims

1. A method for SACK-based packet loss recovery and reception, the method comprising: The application relates to a loss packet inference mechanism based on explicit notification and a loss packet positioning mechanism based on selective retransmission. The loss packet inference mechanism based on explicit notification is applied to a switch. The solution of the explicit loss packet notification ensures that loss packet reporting is only carried out under specific conditions: when a data packet is discarded at an intermediate switch due to excessive network pressure, the switch actively sends a loss packet notification to a receiving end. The loss packet positioning mechanism based on selective retransmission is applied to the receiving end, which accurately describes which data packets in a data transmission interval are not received, thereby supporting retransmission of specific data packets; meanwhile, the selective acknowledgement mechanism is adopted to allow the receiving end to feed back to the sending end which data packets are successfully received. The loss packet retransmission and receiving process is as follows: S1, the sending end starts data transmission and sends data packets to the network; S2, during data packet transmission, when the switch finds that a data packet is discarded based on the loss packet inference mechanism based on explicit notification, a loss packet notification frame is sent to the receiving end; S3, after the receiving end receives the loss packet notification frame, a selective retransmission notification is sent to the sending end based on the loss packet positioning mechanism based on selective retransmission; the receiving end clearly points out which data packets need to be retransmitted according to the state of the data packets that have been received by the receiving end; S4, after the sending end receives the selective retransmission notification, the lost data packets are retransmitted according to the notification content. The loss packet inference mechanism based on explicit notification is implemented in the switch and comprises three modules: a loss packet detection module, an event processing module and a notification generator module. The loss packet detection module is responsible for judging whether a data packet will be discarded at the switch. The event processing module is responsible for inferring whether a data packet is lost at a link. The notification generator module is responsible for generating a loss packet notification frame. After the loss packet detection module or the event processing module detects that the switch or the link is lost, the notification generator module generates a loss packet notification frame and provides the frame to the receiving end. The loss packet detection module is responsible for acquiring the shared buffer / queue state at the switch inlet queue and outputting whether a data packet will be discarded at the switch. The loss packet detection module calculates the remaining buffer pool space by multiplying the utilization rate of the entire buffer pool and the buffer pool size; 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 the data packet will be discarded when it is about to enter the buffer pool; accordingly, it is inferred whether the data packet will be discarded at the switch, and if the data packet is discarded, "discarded" is output, otherwise "not discarded" is output. The loss packet notification frame comprises the following fields: A KIND field: indicating a frame type, the module is 0xFA, indicating a loss packet notification frame; A LEN field: a frame length, the module is 48, indicating 48 bits; A flowID field: indicating a flow identifier; A PSN field: indicating a packet sequence number; When the operation event processing module outputs an operation DROP (pkt), the fields of the loss packet notification frame are as follows: KIND=0xFA; LEN=48; flowID=pkt.flowID; PSN=pkt.PSN. ​ When the operation event handling module outputs 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; The event handling module is responsible for maintaining the state of all flows passing through the switch to implicitly infer whether a packet is lost at the link; The event handling module calculates the hash index according to the flowID of the packet, and makes corresponding processing according to the packet loss, as follows: First, a packet pkt arriving at the ingress queue of the switch is received, which contains a flow identifier flowID and a packet sequence number PSN; Next, a congestion flow table Flow_table is maintained, which includes a flow identifier flowID, an expected packet sequence number PSN, and a time when the flow is marked as congested time; Then, it is determined whether the packet is discarded according to the output of the packet loss detection module, and an expiration event threshold δ is set; Finally, the output operation is generated according to the processing result, including: Enqueue the packet pkt to the switch buffer; Enqueue the packet pkt and send (flowID, PSN) information to the notification generator module, or DROP(pkt), generate a packet loss notification; Discard the packet pkt and send (pkt.flowID, pkt.PSN) information to the notification generator; The specific steps are as follows: First, calculate the hash index idx according to the flowID of the packet; if the packet is to be discarded, check whether the flow is in the congestion flow table Flow_table: If the flow is not in the table and the table entry is empty or the information is outdated, insert the flow information into the congestion flow table and set the operation as 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 PSN of the packet is equal to the expected PSN, update the time in the table entry and set the operation as DROP(pkt) again; if not, no action is taken; If the packet will not be discarded, and the flow is not in the congestion flow table, set the operation as ENQUEUE(pkt) to enqueue the packet to the switch buffer; If the flow is in the congestion flow table and the PSN of the packet is equal to the expected PSN, delete the flow from the congestion flow table, and set the operation as ENQUEUE(pkt); if the PSN is greater than the expected PSN, set the operation as ENQUEUE_NACK(pkt, tbl.flowID, tbl.PSN) to retransmit the packet with flow identifier tbl.flowID and packet sequence number tbl.PSN; otherwise, if the PSN is less than the expected PSN, set the operation as ENQUEUE(pkt); finally, return the corresponding operation.

2. The SACK-based packet loss retransmission and reception method of claim 1, wherein, The packet loss positioning mechanism based on selective retransmission is as follows: At the receiver side, the received events include: Arrived, Drop, Timeout, specifically: Arrived (pkt): packet pkt arrives; Drop (flowID, x): the message that the packet numbered x of the flow numbered flowID is received and discarded; Timeout (flowID, x): the message that the packet numbered x of the flow numbered flowID times out; The receiver maintains a two-dimensional flow state table State, a one-dimensional expected receiving flow table expectPSM and a one-dimensional maximum receiving flow table maxPSM; The first dimension of the two-dimensional flow state table is the flow identifier of each flow, and the second dimension is the packet sequence number, and the table entry includes: "NOT_RECEIVED" not received, "RECEIVED" received, "DROPPED" discarded; The first dimension of the expected receiving flow table expectPSM is the flow identifier of each flow, and the table entry is the smallest un-received packet sequence number; The first dimension of the maximum receiving flow table maxPSM is the flow identifier of each flow, and the table entry is the maximum received packet sequence number; According to different events, the receiver updates the state and decides when and how to request retransmission; The output retransmission notification includes: NACK (flowID, x): tell the sender x and all subsequent retransmissions; SNACK (flowID, l, r): tell the sender to retransmit the packet in the interval (l, r); The specific steps are as follows: First, when the received event Arrived (pkt): packet pkt arrives, calculate its hash index idx, and then check whether 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 of the current maxPSN and the PSN of the packet; Secondly, for the discard event Drop(flowID, x), calculate the hash index idx, if State[idx][x] is not equal to RECEIVED, set it to DROPPED, and send SNACK(flowID, x, x); Finally, for the timeout event Timeout(flowID, x), calculate the hash index idx, if expectPSM[idx] is equal to maxPSM[idx] + 1, send NACK(flowID, expectPSM[idx]); Otherwise, traverse the range from expectPSM[idx] to maxPSM[idx], and send SNACK(flowID, l, r) for each missing sequence number interval (l, r).

3. The SACK-based packet loss retransmission and reception method of claim 2, wherein, The SNACK frame includes the following fields: KIND field: indicates the frame type, this module is 0xFB, indicating that it is a retransmission notification frame; LEN field: frame length, this module is 64, indicating 64 bits; flowID field: indicating flow identifier; (PSNL, PSNR) field: indicating packet sequence number interval (PSNL, PSNR); When the operation is SNACK (flowID, l, r), the lost packet notification frame fields are: KIND=0xFB; LEN=64; flowID=flowID; (PSNL, PSNR)=(l, r).

Images