Interactive establishment and transmission method of network transmission layer protocol

Abstract

The invention provides an interactive establishment and transmission method of a network transport layer protocol, which relates to the technical field of network transmission, is applied to a sending end and comprises the following steps: A1, the sending end sends an OTPSYN message to a receiving end, and the OTPSYN message comprises an initial serial number of the sending end; a2, the sending end receives an OTPSYNACK message which is from the receiving end and comprises a receiving end initial sequence number and a sending end confirmation sequence number; a3, after receiving the OTPSYNACK message, the sending end adds 1 to the initial request sequence number of the sending end and compares the initial request sequence number with a confirmation sequence number in the OTPSYNACK message, and if the initial request sequence number and the confirmation sequence number are equal, the sending end sends the OTPSYNACK message containing the confirmation sequence number of the receiving end to the receiving end; according to the invention, the dependence of the sending end and the receiving end on the CPU is reduced, the data throughput rate is higher, the message transmission delay is reduced, the data transmission efficiency and performance are improved, the TIMEWAIT state is removed when the connection is closed, and the resource consumption is reduced.

Description

Technical Field

[0001] The present invention relates to the field of network transmission, and in particular to a method for establishing and transmitting an interaction of a network transmission layer protocol. Background Art

[0002] The traditional TCP / IP network delay is generally in the millisecond level, but with the widespread deployment of artificial intelligence applications, the network delay requirement has dropped from milliseconds to microseconds. The traditional TCP / IP network protocol stack cannot meet the network bandwidth and delay requirements. At the same time, due to the complex state management mechanism and heavy packet control process of the TCP / IP protocol, it is inefficient and resource-intensive in high-performance AI computing environments, and cannot meet the ultimate pursuit of AI computing for data processing speed and efficiency.

[0003] RDMA (Remote Direct Memory Access) technology came into being. It allows user space applications to directly read or write remote memory without kernel interference or memory copying. It is widely used due to its high bandwidth and low latency. RDMA first appeared in the IB (Infiniband) network and was later ported to the traditional Ethernet, which promoted the popularization of RDMA technology. RDMA on Ethernet is divided into two technologies: RoCE (RDMA over ConvergedEthernet) and iWARP (RDMA over TCP / IP). RoCE has higher throughput and lower latency than iWARP. RoCE uses the lossless Ethernet protocol as the data link layer, the RoCEv1 network layer uses the IB protocol, and the RoCEv2 network layer uses the IP protocol.

[0004] In order to ensure high-performance data transmission of RDMA, RoCEv2 needs to deploy lossless Ethernet using the priority-based flow control protocol PFC (Priority-based Flow Control) in the data center. The PFC protocol allows congested ports to directly suspend data transmission from upstream source ports, thereby avoiding buffer overflow of congested ports and achieving reliable and lossless transmission of data packets. However, this port-level pause will lead to performance problems such as congestion diffusion, and its deployment threshold is high. The strict requirements on hardware resources lead to soaring costs. In actual applications, it may cause side effects such as network congestion, which in turn affects the stability and scalability of the overall system.

[0005] TTPoE (Tesla Transport Protocol over Ethernet) is a custom network protocol designed by Tesla for its AI supercomputer DOJO. This protocol was introduced at the 2024 Hot Chips conference and was developed to meet the needs of low latency and high throughput in high-performance AI computing environments. Here are some of the design goals of TTPoE: (1) Low-latency design: TTPoE is designed to provide microsecond-level latency, which is critical for real-time AI processing and training models.

[0006] (2) Hardware acceleration: The operations of the TTPoE protocol are mainly performed at the hardware level, reducing dependence on the CPU, thereby improving efficiency and performance.

[0007] (3) Simplified protocol stack: TTPoE simplifies the traditional TCP / IP protocol stack, especially in the transport layer. It reduces latency by reducing the complexity of the protocol.

[0008] (4) Lossy network design: Unlike IB and ROCv2, TTPoE allows packet loss in the network and adopts an effective retransmission mechanism to handle packet loss, which is acceptable in AI training because they can usually tolerate a certain degree of data incompleteness.

[0009] (5) Traffic and congestion control: TTPoE handles congestion at the local link level rather than relying on network or switch level control, which helps reduce the complexity of congestion control.

[0010] (6) Fixed congestion window: TTPoE uses a fixed-size congestion window instead of dynamically adjusting it like TCP, which helps achieve more consistent performance in low-latency networks.

[0011] (7) Integration into hardware: Tesla integrates TTPoE into its hardware design, including FPGA and specific chips, to achieve high-speed data transmission.

[0012] (8) Compatible with existing Ethernet infrastructure: TTPoE is designed to run on standard Ethernet switches, which means it can be compatible with existing network infrastructure while providing optimized performance.

[0013] However, when TTPoE is applied to large networks, the following problems will occur: (1) Specific purpose: TTPoE is designed specifically for Tesla's AI cluster and is not suitable for other types of network environments or applications.

[0014] (2) Hardware dependency: TTPoE requires the use of Tesla’s dedicated network interface support, which limits its use on non-Tesla hardware.

[0015] (3) Incompatible with existing TCP / IP network infrastructure: TTPoE is compatible with standard Ethernet switches, but it is not suitable for infrastructure that relies on the TCP / IP protocol stack.

[0016] (4) Complexity: The implementation of TTPoE involves the deep integration of hardware and software, which increases the complexity of the system.

[0017] (5) Ecosystem: TTPoE does not yet have as extensive an ecosystem and community support as TCP / IP, which may affect its long-term maintainability and compatibility.

[0018] (6) Cost: Developing and deploying new network protocols may involve additional costs, including hardware upgrades, software development, etc.

[0019] (7) Scalability: Although TTPoE performs well in Tesla’s Dojo supercomputer, its performance in the broader Internet environment has not yet been verified and may encounter challenges when scaling to larger networks.

[0020] (8) Security: TTPoE only uses two handshakes to establish a connection, which makes it extremely vulnerable to DDoS attacks. In addition, as a new network protocol, TTPoE may not have undergone extensive security audits and may have unknown security vulnerabilities.

[0021] TTPoE only uses two handshakes to establish a connection. The following is a detailed analysis of the disadvantages of TTPoE's two handshakes: (1) Unreliable connection: The purpose of the three-way handshake is to ensure that the sending and receiving channels of both parties are open. If there are only two handshakes, it is impossible to ensure that the receiving channel of the receiver is open. This may cause the sender to send data to a receiver that is actually unable to receive the data.

[0022] (2) Processing of old connection requests: The third handshake in the three-way handshake ensures that even if a delayed connection request arrives, it will not be mistakenly accepted. If there are only two handshakes, a delayed old connection request may be mistakenly accepted by the receiver because it looks like a valid new connection request.

[0023] (3) Challenges of concurrent connections: In the case of a two-way handshake, if the sender sends a connection request but fails to receive a response from the server, the sender may try to connect again. This may cause the server to receive multiple repeated connection requests, thereby creating multiple concurrent connections, which may cause resource allocation problems and data confusion.

[0024] (4) Sequence number synchronization problem: In the second handshake of the three-way handshake, the ACK message sent by the receiver contains the confirmation of the sender's initial sequence number, and the receiver will also choose its own initial sequence number. If there are only two handshakes, the sender cannot confirm whether the receiver has correctly received and confirmed its initial sequence number, which may cause sequence number synchronization problems.

[0025] (5) Security issues: Reducing the number of handshakes to two may reduce the security of the connection because potential attackers may be able to more easily exploit the incomplete handshake process to launch attacks, such as SYN flood attacks.

[0026] (6) The three-way handshake does not reduce the efficiency of data transmission, because data can be officially transmitted during the third handshake without causing additional data transmission delay.

[0027] Therefore, the three-way handshake is an important mechanism in the TCP / IP protocol, which ensures the reliability of the connection and the stability of data transmission. Reducing it to two handshakes will introduce a variety of problems, affecting the stability and security of network communications.

[0028] In summary: (1) TCP / IP network latency is in the millisecond level, which cannot meet the microsecond level requirements of artificial intelligence; (2) The TCP protocol state management mechanism and packet control process are inefficient and resource-intensive, and cannot meet the requirements of artificial intelligence computing for data processing speed and efficiency; (3) The PFC mechanism of RDMA may cause network congestion in practical applications, thus affecting the stability and scalability of the network.

[0029] (5) TTPoE hardware dependency: TTPoE requires the use of Tesla’s dedicated network interface support, which limits its use on non-Tesla hardware.

[0030] (6) TTPoE is incompatible with existing TCP / IP network infrastructure: TTPoE is compatible with standard Ethernet switches, but it is not suitable for infrastructure that relies on the TCP / IP protocol stack.

[0031] (7) TTPoE security: TTPoE only uses two handshakes to establish a connection, which leads to unreliable connection and network security issues.

[0032] Given that TCP / IP, RDMA and TTPoE are all difficult to fully meet the high standards of artificial intelligence for network transport layer protocols in terms of speed, cost control and comprehensive performance, this application intends to propose an efficient and easy-to-implement network transport layer protocol for artificial intelligence needs. It aims to directly optimize the traditional TCP protocol through customized design, thereby effectively breaking through the existing technical bottlenecks, which can not only adapt to the artificial intelligence application training and reasoning needs of the AI ​​center, but also be suitable for data transmission and real-time information interaction on the Internet, effectively improving the transmission efficiency of the protocol. Summary of the invention

[0033] In order to overcome the deficiencies in the background technology, the present invention provides a method for establishing and transmitting an interaction of a network transport layer protocol.

[0034] In order to achieve the above-mentioned invention object, the present invention adopts the following technical scheme: In a first aspect, the present invention provides a method for establishing interaction of a network transport layer protocol, which is applied to a sending end and comprises the following steps: A1. The sender sends an OTP_SYN message to the receiver to request to establish a connection; the OTP_SYN message includes the sender's initial sequence number ISN1; A2, the sending end receives an OTP_SYN_ACK message from the receiving end, which includes the initial sequence number ISN2 of the receiving end and the confirmation sequence number of the sending end; the sending end confirmation sequence number is generated after the receiving end receives the OTP_SYN message; the sending end confirmation sequence number is equal to the initial sequence number ISN1 of the sending end plus 1; A3. After receiving the OTP_SYN_ACK message, the sender adds 1 to the sender's initial sequence number ISN1 and compares it with the sender's confirmation sequence number in the OTP_SYN_ACK message segment. If the two are equal, the sender sends an OTP_ACK message containing the receiver's confirmation sequence number to the receiver to establish a connection between the sender and the receiver; and puts the transmission data into the payload of the message for data transmission; the receiver's confirmation sequence number is equal to the receiver's initial sequence number ISN2 plus 1.

[0035] Specifically, the method further includes: A4. The sender sends an OTP_FIN message to the receiver, where the OTP_FIN message includes a close sequence number of the sender. A5. After receiving the OTP_FIN_ACK message, the sender adds 1 to the sender's closing sequence number and compares it with the sender's closing confirmation sequence number in the OTP_FIN_ACK message segment. If the two are equal, the connection between the sender and the receiver is closed. A6. When the sending end receives the OTP_FIN message from the receiving end, it sends back an OTP_FIN_ACK message including the receiving end's closing confirmation sequence number to the receiving end; the receiving end's closing confirmation sequence number is the receiving end's closing sequence number in the received OTP_FIN message plus 1; the sending end closes the connection between the sending end and the receiving end; the OTP_FIN message includes the receiving end's closing sequence number.

[0036] Specifically, the step A1 further includes: the sending end calculates the first congestion window and the first MSS according to its own sending buffer size and the network interface type, and packages the two into an OTP_SYN message and sends it to the receiving end; The step A2 further includes: the receiving end calculates the second congestion window and the second MSS according to the size of its receiving buffer and the type of the network interface, and packages the smaller value of the first congestion window and the second congestion window as the third congestion window and the smaller value of the first MSS and the second MSS as the third MSS into an OTP_SYN_ACK message replied to the sending end; The step A3 also includes: the sending end receives the OTP_SYN_ACK message sent by the receiving end, packs the third congestion window and the third MSS into the OTP_ACK message and sends it to the receiving end, and the sending end sends a data message according to the third congestion window and the third MSS.

[0037] Specifically, step A3 also includes the following steps: M1, the sender records the sending time and sequence number of each data packet confirmation message, and waits for receiving the confirmation message; M2. If the waiting time exceeds the unconfirmed tolerance window time and the confirmation message of the data packet that should be received is still not received, the data packet is judged to be the first lost data packet; the receiving time of the data packet should be less than the sending time of the data packet plus the value of the unconfirmed tolerance window time. If it is greater, it is considered that the confirmation message of the data packet that should be received has not been received; M3. The sender resends the data packet according to the sequence number of the first lost data packet.

[0038] Specifically, step A3 also includes: A31, after receiving the OTP_NACK_FULL message, the transmitting end suspends sending data messages according to the suspension duration; the OTP_NACK_FULL message option includes the suspension duration; A32. After receiving the OTP_LINK_CLOSED message, the sending end stops using the connection to send data and closes the connection.

[0039] Specifically, step A3 also includes the following steps: A33, the sender receives an OTP_NACK message with a sequence number of ISN from the receiver; A34. The sender resends the message with sequence number ISN.

[0040] In a second aspect, the present invention provides a method for establishing interaction of a network transport layer protocol, which is applied to a receiving end and comprises the following steps: B1, the receiving end receives the OTP_SYN message from the sending end; the OTP_SYN message includes the sending end initial sequence number ISN1; B2. After receiving the OTP_SYN message from the sender, the receiver sends back an OTP_SYN_ACK message containing the initial sequence number ISN2 of the receiver and the confirmation sequence number of the sender as a response; the confirmation sequence number of the sender is equal to the initial sequence number ISN1 of the sender plus 1; B3. After the receiving end receives the OTP_ACK message containing the receiving end confirmation sequence number from the sending end, the receiving end establishes a connection with the sending end and starts receiving data; the receiving end confirmation sequence number is equal to the receiving end initial sequence number ISN2 plus 1.

[0041] Specifically, the method further includes: B4. After receiving the OTP_FIN message from the sender, the receiving end sends back an OTP_FIN_ACK message including the sender's closing confirmation number to the sender; the sender's closing confirmation number is the sender's closing number in the received OTP_FIN message plus 1; the receiving end closes the data reception from the sender; the OTP_FIN message includes the sender's closing number.

[0042] B5. The receiving end sends an OTP_FIN message to the sending end, wherein the OTP_FIN message includes a closing sequence number of the receiving end; B6. After receiving the OTP_FIN_ACK message, the receiving end adds 1 to the receiving end closing sequence number and compares it with the receiving end closing confirmation sequence number in the OTP_FIN_ACK message segment. If the two are equal, the connection between the sending end and the receiving end is closed; the receiving end closing confirmation sequence number is the receiving end closing sequence number in the received OTP_FIN message plus 1.

[0043] Specifically, the B1 further includes: the OTP_SYN message includes a first congestion window and a first MSS calculated by the sender according to its own send buffer size and network interface type; The B2 also includes: the receiving end calculates the second congestion window and the second MSS according to the size of its receiving buffer and the type of the network interface, and packages the smaller value of the first congestion window and the second congestion window as the third congestion window and the smaller value of the first MSS and the second MSS as the third MSS into an OTP_SYN_ACK message replied to the sending end; The B3 also includes: the receiving end receives the data message according to the third congestion window and the third MSS.

[0044] Specifically, step B3 also includes the following steps: N1. The receiving end records the sequence number and receiving time of each received data packet, and calculates the time interval between every two consecutive data packets; N2. When the receiving end receives a data packet, it checks the sequence number of the data packet. If the receiving end finds that a data packet with a smaller sequence number than the current data packet has not been received, it preliminarily determines that the unreceived data packet is a second preliminary lost data packet; N3. If the estimated receiving time of the second preliminary lost data packet plus the time of the disorder tolerance window is still less than the current time, the second preliminary lost data packet is marked as the second lost data packet; the estimated receiving time of the second preliminary lost data packet is the receiving time of the previous data packet plus the interval time; N4. The receiving end sends an OTP_NACK message to the sending end. The OTP_NACK message carries the sequence number of the second lost data packet, requesting the sending end to resend the second lost data packet.

[0045] Specifically, step B3 also includes: B31. If the receiving end sends a buffer that exceeds a preset usage threshold, an OTP_NACK_FULL message is sent to the sending end to notify the sending end to suspend sending data; the OTP_NACK_FULL message option includes a suspension duration; B32. After the connection is closed, the receiving end still receives a message of a closed connection, and the receiving end sends an OTP_LINK_CLOSED message.

[0046] Specifically, the protocol header of the message includes: Option type: 8 bits, TCP option field, set to 0xc7, indicating an experimental extension of TCP; Length: 8 bits, the setting value is 0x08, which means the option length is 8 bytes; Operation code: 8 bits, including: OTP_SYN, OTP_SYN_ACK, OTP_ACK, OTP_PUSH, OTP_FIN, OTP_FIN_ACK, OTP_NACK, OTP_NACK_FULL and OTP_LINK_CLOSED; Congestion control: 8 bits, congestion control; indicates the congestion window size in bytes; Send control: 8 bits, the sequence number sent; used to identify the sequence number of the data packet sent by the sender next time; Receive control: 8 bits, receive sequence number; used to identify the sequence number of the next data packet that the receiver expects to receive.

[0047] In a third aspect, the present invention provides a transmission method of a network transport layer protocol, which is applied to a sending end. The sending end starts data transmission and enters the OPENED state after executing the interactive establishment method as described in the first aspect, indicating that the connection is established; After the sending end sends the OTP_FIN message, the sending end enters the CLOSE SEND state; and after receiving the OTP_FIN_ACK message from the receiving end, the TCB is deleted, the sending end closes the sending connection, and the state changes to the CLOSED state; After receiving the OTP_FIN message, the sending end enters the CLOSE RCVD state, sends an OTP_FIN_ACK message to the receiving end, deletes the TCB, closes the receiving connection, and the state changes to the CLOSED state.

[0048] In a fourth aspect, the present invention provides a network transport layer protocol transmission method, which is applied to a receiving end. The receiving end starts data transmission and enters the OPENED state after executing the interactive establishment method as described in the second aspect, indicating that the connection is established; After the receiving end sends the OTP_FIN message, the receiving end enters the CLOSE SEND state; and after receiving the OTP_FIN_ACK message from the sending end, the TCB is deleted, the receiving end closes the sending connection, and the state changes to the CLOSED state; After receiving the OTP_FIN message, the receiving end enters the CLOSE RCVD state, sends an OTP_FIN_ACK message to the sending end, deletes the TCB, and closes the receiving connection, and the state changes to the CLOSED state.

[0049] The invention provides a method for establishing and transmitting an interactive network transport layer protocol, which has the following beneficial effects: 1) Modify the TCP state machine and the protocol interaction process to reduce the transmission protocol's dependence on the CPU: The TCP three-way handshake mechanism is retained, and data is sent synchronously during the third handshake to reduce data transmission time; Removing the TIME_WAIT state and various waiting states can effectively reduce the waiting time on both the sending and receiving ends, reduce the additional delay when closing the connection, improve protocol efficiency, and help reduce network congestion under high load conditions.

[0050] 2) When the connection is established, the window size is determined based on the smallest SRAM buffer size in the hardware of the sender and server. When the buffer is full, the transmission stops, and the packet loss is handled by retransmitting the data stored in the SRAM buffer. This method reduces the complexity of congestion control; 3) It handles congestion by simply discarding data packets, uses fast retransmission and fast recovery to manage network congestion, and does not use congestion control algorithms such as slow start and congestion avoidance. Compared with traditional TCP congestion control algorithms (such as Reno), the response time scale is shorter and more suitable for supercomputer application scenarios; 4) Bidirectional packet loss detection algorithm: Both the sender and the receiver use the packet loss detection algorithm to quickly and effectively detect packet loss and reduce packet loss delay; Through these mechanisms, the new protocol is able to reduce network congestion while maintaining high throughput, which is critical for AI training and other high-performance computing tasks; the new transmission protocol is suitable for efficiently handling large-scale data transmission in supercomputer environments, and is particularly suitable for artificial intelligence training and reasoning. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0052] Figure 1 Schematic diagram of the OTP protocol stack provided by an embodiment of the present invention; Figure 2 It is a schematic diagram of the TCP / IP protocol stack provided by an embodiment of the present invention; Figure 3 It is a schematic diagram of the TTPoE protocol stack provided by an embodiment of the present invention; Figure 4 Schematic diagram of an OTP state machine provided by an embodiment of the present invention; Figure 5 It is a schematic diagram of a TCP-compatible OTP message format provided by an embodiment of the present invention; Figure 6 It is a schematic diagram of the OTP message format as an independent transmission protocol provided by an embodiment of the present invention; Figure 7 Schematic diagram of a method for establishing interaction of a network transport layer protocol provided by an embodiment of the present invention; Figure 7 (a) The sender actively closes the connection. Figure 7 (b) The receiving end actively closes the connection; Figure 8It is a schematic diagram of the change of the TCP congestion window provided by an embodiment of the present invention; Fig. 9 It is a schematic diagram of the congestion window change of OTP provided by an embodiment of the present invention; Fig.10 It is a schematic diagram of the MSS and congestion window negotiation process of a method for interactively establishing a network transport layer protocol provided by an embodiment of the present invention; Fig.11 1 is a schematic diagram of a bidirectional packet loss detection and retransmission process of an interactive establishment method of a network transport layer protocol provided by an embodiment of the present invention; Fig.11 (a) is a schematic diagram of the packet loss detection process at the sending end; Fig.11 (b) is a schematic diagram of the packet loss detection process at the receiving end; Fig.12 is an example diagram of bidirectional packet loss detection and retransmission of a method for establishing an interactive network transport layer protocol provided by an embodiment of the present invention; wherein Fig.12 (a) is an example diagram of packet loss detection at the sender; Fig.12 (b) is an example diagram of packet loss detection at the receiving end. DETAILED DESCRIPTION

[0053] The present invention can be explained in detail through the following embodiments. The purpose of providing the present invention is to protect all technical improvements within the scope of the present invention. In the description of the present invention, it should be understood that if there are terms such as "upper", "lower", "front", "back", "left", "right", etc. indicating directions or positional relationships, they only correspond to the drawings of the present application for the convenience of describing the present invention, and do not indicate or imply that the device or element referred to must have a specific direction.

[0054] Embodiment 1

[0055] This embodiment provides a network transport layer protocol named OTP (Optimal Transfer Protocol), which is designed to meet the artificial intelligence application training and reasoning needs of the AI ​​center and is also suitable for data transmission and real-time information interaction on the Internet. Its state machine is simple, practical, efficient and easy to implement. It draws on some design ideas of TTPoE, simplifies the traditional TCP protocol, improves the problem of poor adaptability of TTPoE, and improves the transmission efficiency of the protocol.

[0056] Let's first understand which steps in the TCP data transmission process need to interact with the CPU (central processing unit). The following are some key interaction links: (1) Data preparation: Before sending data, the application will prepare the data, which usually involves the CPU to process the data, such as reading, processing, and encryption.

[0057] (2) Socket operations: Applications interact with the TCP / IP protocol stack through the socket interface. Operations such as creating sockets, binding, listening, connecting, sending, and receiving all require the CPU to execute system calls and process related application logic.

[0058] (3) Buffer management: The CPU is responsible for managing kernel buffers (such as send buffers and receive buffers), including allocating and releasing buffers, and copying data from user space to kernel space, or vice versa.

[0059] (4) Data packetization / packetization: TCP is a byte stream-oriented protocol. The CPU needs to handle data packetization (splitting large data into multiple TCP segments) and packetization (reassembling received TCP segments into complete messages).

[0060] (5) Sequence number and acknowledgment: The sender’s CPU needs to calculate the sequence number, while the receiver’s CPU needs to send an acknowledgment (ACK) and process the sequence number of the received data packet.

[0061] (6) Flow control and congestion control: The CPU needs to calculate the window size (flow control) and execute congestion control algorithms such as slow start, congestion avoidance, fast retransmit, and fast recovery.

[0062] (7) Error detection and recovery: If an error is detected (such as a checksum error), the CPU needs to handle the retransmission mechanism or may need to close the connection.

[0063] (8) Processing TCP options: Some TCP options (such as maximum segment size MSS, window scaling factor, timestamp, etc.) require the CPU to calculate and process.

[0064] (9) Processing TCP header: The CPU needs to parse various flags in the TCP header, such as SYN, ACK, FIN, RST, etc., and perform corresponding operations.

[0065] (10) Interrupt processing: When a data packet arrives or is sent, the network interface card (NIC) triggers an interrupt. The CPU needs to handle these interrupts and hand over or retrieve the data to or from the TCP / IP protocol stack.

[0066] (11) Protocol stack processing: The CPU executes software routines in the protocol stack to handle the reception and transmission of TCP segments, including processing the TCP header, managing the connection status, and processing data.

[0067] (12) Data transfer between user space and kernel space: When data arrives from the network, the CPU needs to copy the data from the kernel space to the application buffer in the user space. Similarly, when the application sends data, the CPU needs to copy the data from the user space to the kernel space.

[0068] (13) I / O operations: An application's I / O operations (such as reading and writing files) usually require the CPU to execute, especially when network communication is involved.

[0069] (14) Close the connection: When the data is sent and the connection is no longer needed, the CPU will execute the operation of closing the connection, including sending a FIN packet and processing four handshake processes.

[0070] In modern operating systems, many network operations can reduce the burden on the CPU through technologies such as asynchronous I / O, kernel bypass (such as DPDK), and user-mode protocol stacks, but many operations in the above steps still require the participation of the CPU.

[0071] The present invention improves the efficiency of TCP mainly by optimizing the protocol interaction process, flow and congestion control, processing TCP options, protocol stack processing (corresponding to (11), (5), (6), (8), (14) above) and other links. The technical solution is specifically described from the following aspects: 1) Protocol stack model like Figure 1 As shown, this implementation provides a network transport layer protocol, which is applied to the transport layer; OTP is mainly based on modifying the TCP protocol to improve TCP efficiency, with little impact on other protocols in the protocol stack. The link layer relies on Ethernet and the network layer is based on IP. The corresponding TCP / IP protocol stack is Figure 2 As shown, the TTPoE protocol stack is as follows Figure 3 shown.

[0072] 2) State Machine The TCP state machine has 11 states: CLOSED: Initially, there is no connection.

[0073] LISTEN: The server (receiving end) listens for connection requests (SYN packets) from the sending end.

[0074] SYN_SENT: The sending socket executes CONNECT connection, sends a SYN packet, and then waits for a SYN ACK packet from the server (the server's connection request and confirmation of the sender's connection request).

[0075] SYN_RCVD: The receiver receives the SYN packet from the sender and sends the receiver SYN ACK packet, and then waits for the sender's confirmation of the connection request (ACK packet).

[0076] ESTABLISH: Indicates that the connection is established. The sender enters this state after sending the last ACK packet, and the receiver enters this state after receiving the ACK packet.

[0077] FIN_WAIT_1: The party terminating the connection (usually the client) enters this state after sending a FIN packet, and then waits for the other party's FIN packet.

[0078] CLOSE_WAIT: The receiving end (server) waits for the closing phase after receiving the FIN packet from the client. After receiving the FIN packet from the other party, it is necessary to reply with an ACK packet immediately, indicating that the disconnection request has been received.

[0079] However, whether this party disconnects the connection immediately (sends a FIN packet) depends on whether there is still data to be sent to the sender. If there is still data to be sent, this state will be maintained before sending the FIN packet.

[0080] FIN_WAIT_2: The sender receives the ACK packet from the server, but does not immediately receive the FIN packet from the receiver, and enters the FIN_WAIT_2 state. This is a semi-connected state, that is, one party requests to close the connection and waits for the other party to close.

[0081] LAST_ACK: The receiver sends the last FIN packet and waits for the last ACK packet from the sender.

[0082] CLOSING: When the active closing party is in FIN_WAIT_1, the passive closing party's FIN arrives before the ACK sent by itself. The active closing party directly changes from FIN_WAIT_1 -> CLOSING (actually equivalent to closing at the same time). Then when the late ACK arrives, the active closing party changes from CLOSING -> TIME_WAIT.

[0083] TIME_WAIT: The sender receives the FIN packet from the receiver and immediately sends an ACK packet for final confirmation. The 2MSL (twice the maximum segment life) time after this is called the TIME_WAIT state.

[0084] OTP state machine Figure 4 As shown in the figure, OTP retains the states required for the three-way handshake, deletes the ESTABLISH, FIN_WAIT_1, CLOSE_WAIT, FIN_WAIT_2, LAST_ACK, CLOSING, and TIME_WAIT states, and adds the OPENED, CLOSESEND, and CLOSE RCVD states; among them: OPENED: Indicates that the connection is established. The sender enters this state after sending the last ACK message (that is, the sender starts data transmission); the receiver enters this state after receiving the ACK message (that is, the receiver starts data transmission).

[0085] CLOSE SEND: Close send state. The sender enters this state after sending a FIN message. After receiving the FIN ACK message from the sender, the TCB is deleted, the sender closes the send connection, and the state changes to CLOSED state. CLOSE RCVD: Close receiving state. The receiving end enters this state after receiving the FIN message, and then sends a FINACK message to the sending end, deletes the TCB, and the receiving end closes the receiving connection, and the state changes to the CLOSED state; TCB (Transmission Control Block) is the abbreviation of transmission control block. It is a data structure that contains all the information needed to manage a connection.

[0086] It is understandable that each connection has two TCBs, located at both ends of the communication (i.e., the sending end (client) and the receiving end (server)), which jointly maintain the connection status information.

[0087] This protocol can effectively reduce the waiting time at both the sending and receiving ends and improve the protocol efficiency by removing the TIME_WAIT state and various waiting states.

[0088] 3) Protocol header format In the early stage, in order to achieve compatibility with the traditional TCP / IP protocol, the protocol header of the OTP message is the same as TCP, mainly expanding the TCP options. The option format of the current OTP protocol header design is as follows: Figure 5 As shown in the figure, the option type, length, operation code, congestion control, send control and receive control fields are added to expand the TCP function, including RDMA read and write operations, etc., which can be expanded by referring to the Opcode (protocol operation code) of TTPoE, where: Option type: 8 bits, TCP option field, set to 0xc7 (199) here to indicate an experimental extension of TCP; Length: 8 bits. Here, the value is set to 0x08, indicating that the option length is 8 bytes. Operation code: 8 bits, as shown in Table 1:

[0089] Congestion control: 8 bits, congestion control; indicates the congestion window size in bytes; Send control: 8 bits, the sequence number sent; used to identify the sequence number of the data packet sent by the sender next time; Receive control: 8 bits, receive sequence number; used to identify the sequence number of the next data packet that the receiver expects to receive.

[0090] The remaining fields have the same functions as the TCP fields.

[0091] refer to Figure 6 If OTP is used as an independent transmission protocol in the future, the protocol header of the OTP message includes: Operation code: 8 bits, as shown in Table 1: Congestion control: 8 bits, congestion control; indicates the congestion window size in bytes; Send control: 8 bits, the sequence number sent; used to identify the sequence number of the data packet sent by the sender next time; Receive control: 8 bits, receive sequence number; used to identify the sequence number of the next data packet that the receiver expects to receive.

[0092] The remaining fields have the same functions as the TCP fields.

[0093] 4) Protocol interaction process During the connection establishment phase, OTP uses a three-way handshake process. First, the sender sends an OTP_SYN (synchronization sequence number) message, and the server responds with an OTP_SYN_ACK (synchronization sequence number confirmation) message. The sender sends the data synchronously while sending the OTP_ACK (confirmation) message. This completes the three-way handshake without reducing data transmission efficiency.

[0094] The interactive establishment method of the network transport layer protocol OTP is applied to the sender and the receiver, and the interactive establishment process covers the connection establishment process and the connection termination process: The protocol interaction process includes the connection establishment process and the connection termination process: The method for establishing interaction of the network transport layer protocol applied at the sending end includes the following steps: A1. The sender sends an OTP_SYN message to the receiver to request to establish a connection. The OTP_SYN message includes the sender's initial sequence number ISN1. The sequence number included in the message is used for subsequent data packet sorting and packet loss detection. The Initial Sequence Number (ISN) is randomly determined, including the sender's initial sequence number ISN1 and the receiver's initial sequence number ISN2. It is mainly to ensure the uniqueness and security of each connection. The generation of ISN can also be achieved through a Hash algorithm. This algorithm will generate a random value based on the source IP, destination IP, source port and destination port to ensure the randomness and unpredictability of ISN.

[0095] It is understandable that the messages exchanged between the sending end and the receiving end all contain the port address of the other party. This is the existing technology and will not be described in detail here.

[0096] A2, the sending end receives an OTP_SYN_ACK message from the receiving end, which includes the initial sequence number ISN2 of the receiving end and the confirmation sequence number of the sending end; the sending end confirmation sequence number is generated after the receiving end receives the OTP_SYN message; the sending end confirmation sequence number is equal to the initial sequence number ISN1 of the sending end plus 1; A3. After receiving the OTP_SYN_ACK message, the sender adds 1 to the sender's initial sequence number ISN1 and compares it with the sender's confirmation sequence number in the OTP_SYN_ACK message segment. If the two are equal, the sender sends an OTP_ACK message containing the receiver's confirmation sequence number to the receiver to establish a connection between the sender and the receiver; and puts the transmission data into the payload of the message for data transmission; the receiver's confirmation sequence number is equal to the receiver's initial sequence number ISN2 plus 1.

[0097] The payload of a message is the data field in the message.

[0098] When sending the sender confirmation sequence number, the sender puts the data into the message payload for transmission. This can reduce the RTT (round trip time) and improve the efficiency of data transmission.

[0099] refer to Figure 7 (a) The process of the sender actively closing the connection is as follows: A4. The sender sends an OTP_FIN message to the receiver, where the OTP_FIN message includes a close sequence number of the sender. A5. After receiving the OTP_FIN_ACK message, the sender adds 1 to the sender's closing sequence number and compares it with the sender's closing confirmation sequence number in the OTP_FIN_ACK message segment. If the two are equal, the connection between the sender and the receiver is closed. A6. When the sending end receives the OTP_FIN message from the receiving end, it sends back an OTP_FIN_ACK message including the receiving end's closing confirmation sequence number to the receiving end; the receiving end's closing confirmation sequence number is the receiving end's closing sequence number in the received OTP_FIN message plus 1; the sending end closes the connection between the sending end and the receiving end; the OTP_FIN message includes the receiving end's closing sequence number.

[0100] After A3 establishes the connection between the sending end and the receiving end, the following steps are also included: A31. After receiving the OTP_NACK_FULL message, the sender suspends sending data messages according to the pause duration; the OTP_NACK_FULL message option includes the pause duration; if the pause duration option does not exist, the pause duration defaults to 2 milliseconds; the pause duration can be modified according to specific needs.

[0101] When the receiving buffer is full, if the sender still sends messages at the original speed, buffer overflow will cause message loss. The sending will be suspended until the receiving area processes some messages and then send the messages at the original speed.

[0102] A32. The sending end receives the OTP_LINK_CLOSED message, stops using the connection to send data, and closes the connection.

[0103] After A3 establishes the connection between the sender and the receiver, the following steps are also included for retransmitting when it is assumed that the message is lost: A33, the sender receives an OTP_NACK message with a sequence number of ISN from the receiver; A34. The sender resends the message with sequence number ISN.

[0104] Combined with the state machine of OTP, the sender starts data transmission and enters the OPENED state through the above method at the sender, indicating that the connection is established; After the sending end sends the OTP_FIN message, the sending end enters the CLOSE SEND state; and after receiving the OTP_FIN_ACK message from the receiving end, the TCB is deleted, the sending end closes the sending connection, and the state changes to the CLOSED state; After receiving the OTP_FIN message, the sending end enters the CLOSE RCVD state, sends an OTP_FIN_ACK message to the receiving end, deletes the TCB, closes the receiving connection, and the state changes to the CLOSED state.

[0105] The interactive establishment method of the network transport layer protocol applied at the receiving end includes the following steps: B1, the receiving end receives the OTP_SYN message from the sending end; the OTP_SYN message includes the sending end initial sequence number ISN1; B2. After receiving the OTP_SYN message from the sender, the receiver sends back an OTP_SYN_ACK message containing the initial sequence number ISN2 of the receiver and the confirmation sequence number of the sender as a response; the confirmation sequence number of the sender is equal to the initial sequence number ISN1 of the sender plus 1; B3. After the receiving end receives the OTP_ACK message containing the receiving end confirmation sequence number from the sending end, the receiving end establishes a connection with the sending end and starts receiving data; the receiving end confirmation sequence number is equal to the receiving end initial sequence number ISN2 plus 1.

[0106] ISN2 can be used to verify the receiving end confirmation number. In this embodiment, the connection is established after the sending end confirms and verifies. In other possible implementations, the receiving end confirmation number can also be verified at the receiving end as needed; For example, in another possible implementation, in step B3, after the receiving end receives the OTP_ACK message containing the receiving end confirmation number from the sending end, the receiving end initial sequence number ISN2 plus 1 is compared with the receiving end confirmation number in the OTP_ACK message segment. If the two are equal, a connection between the receiving end and the sending end is established, and data reception begins.

[0107] B4. After receiving the OTP_FIN message from the sender, the receiving end sends back an OTP_FIN_ACK message including the sender's closing confirmation number to the sender; the sender's closing confirmation number is the sender's closing number in the received OTP_FIN message plus 1; the receiving end closes the data reception from the sender; the OTP_FIN message includes the sender's closing number.

[0108] refer to Figure 7 (b) The process of the receiving end actively closing the connection is as follows: B5. The receiving end sends an OTP_FIN message to the sending end, wherein the OTP_FIN message includes a closing sequence number of the receiving end; B6. After receiving the OTP_FIN_ACK message, the receiving end adds 1 to the receiving end closing sequence number and compares it with the receiving end closing confirmation sequence number in the OTP_FIN_ACK message segment. If the two are equal, the connection between the sending end and the receiving end is closed; the receiving end closing confirmation sequence number is the receiving end closing sequence number in the received OTP_FIN message plus 1.

[0109] After the data receiving starts in step B3, the following steps are also included: B31. If the receiving end sends a buffer that exceeds a preset usage threshold, an OTP_NACK_FULL message is sent to the sending end to notify the sending end to suspend sending data; the OTP_NACK_FULL message option includes a suspension duration; The pause duration can be specified in the OTP_NACK_FULL message option. If not specified, the pause duration is 2 milliseconds. The preset usage threshold is selected in the range of [0.88, 0.98]. Preferably, the preset usage threshold in this embodiment is 0.95. The pause duration can be modified according to specific needs.

[0110] B32. After the connection is closed, the receiving end still receives a message of a closed connection, and the receiving end sends an OTP_LINK_CLOSED message.

[0111] Combined with the state machine of OTP, the receiving end starts data transmission and enters the OPENED state through the above method at the receiving end, indicating that the connection is established; After the receiving end sends the OTP_FIN message, the receiving end enters the CLOSE SEND state; and after receiving the OTP_FIN_ACK message from the sending end, the TCB is deleted, the receiving end closes the sending connection, and the state changes to the CLOSED state; After receiving the OTP_FIN message, the receiving end enters the CLOSE RCVD state, sends an OTP_FIN_ACK message to the sending end, deletes the TCB, and the receiving end closes the receiving connection, and the state changes to the CLOSED state.

[0112] The network transport layer protocol of this embodiment retains the three-way handshake mechanism of TCP, and sends data synchronously during the third handshake to reduce data transmission time. In order to save time and simplify the process, during the connection closing phase, the TIME_WAIT and other states of TCP are removed to reduce additional delays when closing the connection, which helps to reduce network congestion under high load conditions.

[0113] 5) Flow and congestion control TCP uses slow start, congestion window (sliding window) and timeout retransmission mechanisms to control congestion. The congestion window changes as follows: Figure 8 shown.

[0114] OTP does not use the traditional TCP congestion window mechanism. Instead, it determines the window size based on the smallest SRAM buffer size in the sender and server hardware when the connection is established. When the buffer is full, transmission stops, and packet loss is handled by retransmitting the data saved in the SRAM buffer. This approach eliminates the need for additional send credits and reduces the complexity of network switches. OTP's congestion control algorithm is similar to TCP, which handles congestion by simply discarding packets. OTP uses fast retransmission and fast recovery to manage network congestion, and does not use congestion control algorithms such as slow start and congestion avoidance. Compared with traditional TCP congestion control algorithms (such as Reno), OTP has a shorter response time scale and is more suitable for supercomputer application scenarios. OTP window changes such as Fig. 9 As shown in Figure 1, compared with TCP, its control is simpler and its data throughput is higher. The MSS and congestion window negotiation process of OTP is as follows: Fig.10 As shown: S1. The sender calculates the first congestion window and the first MSS according to its own send buffer size and network interface type, and packages the two into an OTP_SYN message and sends it to the receiver; MSS (Maximum segment size) is the maximum segment size. MSS is used in the TCP protocol and represents the maximum data length that can be transmitted in a single TCP message.

[0115] The MSS value in this embodiment is related to the network interface type. For the MSS values ​​of common network interfaces, refer to Table 2:

[0116] Assume that the first congestion window is 15 calculated based on the size of the sender's own send buffer; Assume that the network interface type of the sender is an Ethernet electrical interface, then the first MSS is 1460; S2. The receiving end calculates the second congestion window and the second MSS according to its own receiving buffer size and the network interface type, and packages the smaller value of the first congestion window and the second congestion window as the third congestion window and the smaller value of the first MSS and the second MSS as the third MSS into an OTP_SYN_ACK message replied to the sending end; Assume that the second congestion window is 10 calculated according to the size of the receiving buffer area of ​​the receiving end; Assume that the network interface type of the receiving end is an Ethernet electrical interface, the second MSS is 1460; Compare the first congestion window and the second congestion window to obtain the smaller value as the third congestion window of 10, and compare the first MSS and the second MSS to obtain the smaller value to obtain the third MSS of 1460; Pack the third congestion window and the third MSS into an OTP_SYN_ACK message and send it to the sending end; S3: The sender receives the OTP_SYN_ACK message from the receiver, packs the third congestion window and the third MSS into the OTP_ACK message and sends it to the receiver; The sender receives the OTP_SYN_ACK message from the receiver and agrees to use the third congestion window as the final congestion window and the third MSS as the final MSS. Then, the sender packages the third congestion window and the third MSS into the OTP_ACK message and sends it to the receiver to inform the receiver. S4. The sending end and the receiving end send and receive data packets according to the third congestion window and the third MSS.

[0117] It is understandable that the sending end can also be called the client, and the receiving end can also be called the server; This embodiment does not limit how to calculate the congestion window value based on the size of the sender or receiver's own send buffer; In a possible implementation, a mapping function may be defined to map the size of the send buffer to the size of an initial congestion window; In another possible implementation, the initial congestion window may be determined by an adaptive algorithm, which may consider the current system load, network conditions, and historical data to determine a suitable initial congestion window, and then evaluate the size of the sending buffer at startup, and dynamically adjust the initial congestion window accordingly; In another possible implementation, the MSS may be adjusted according to the relationship between the buffer size and the MSS to obtain the congestion window value.

[0118] The final TCP congestion window size (i.e., the third congestion window value) of the OTP message is calculated based on the buffer size in the hardware of the sender and receiver and the MSS negotiation, so the final congestion window size is constant. Fig. 9 The change of the congestion window in the figure presents a straight line. In this embodiment, the first, second and third congestion windows are intermediate values ​​obtained in order to calculate the final TCP congestion window. Because they are not shown in the figure, the third congestion window value is finally obtained to send the data message, that is, the third congestion window value is the TCP congestion window used when the message is finally sent.

[0119] OTP's congestion window does not resize based on packet loss. The software tracks the data sent in a send buffer. When the buffer fills up, sending stops and packet loss is handled by retransmitting the data saved in the send buffer. When the response confirmation from the other end arrives, the data is released from the send buffer, naturally pushing the congestion window forward. This approach eliminates the need for additional send credits and reduces the complexity of network switches.

[0120] 6) Packet loss and retransmission detection refer to Figure 11-12 As shown, OTP also proposes a packet loss detection method that infers packet loss based on timestamps in both the sender and the receiver, rather than relying solely on the order in which the data packets are sent or whether duplicate acknowledgments are received.

[0121] 1. If the sender fails to receive the confirmation message within the time limit, it will actively resend the message; 2. If the receiver receives a message with a later sequence number but fails to receive a message with an earlier sequence number within the time limit, it will actively inform the sender to resend the message.

[0122] The packet loss detection method includes a sending end packet loss detection method and a receiving end packet loss detection method; refer to Fig.11 As shown in (a) and 12 (a), the packet loss detection method at the sending end specifically includes: M1, the sender records the sending time and sequence number of each data packet confirmation message, and waits for receiving the confirmation message; If no confirmation message is received, clear the corresponding sequence number data in the buffer.

[0123] M2. If the waiting time exceeds the unconfirmed tolerance window time and the confirmation message of the data packet that should be received is still not received, the data packet is judged to be the first lost data packet; the receiving time of the data packet should be less than the sending time of the data packet plus the value of the unconfirmed tolerance window time. If it is greater, it is considered that the confirmation message of the data packet that should be received has not been received; Unconfirmed tolerance window: A certain degree of disorder is tolerated by setting a time window. Within this time window, even if a confirmation of a later-sent data packet is received, the sender will not immediately mark the earlier data packet as lost; if the time exceeds the unconfirmed tolerance window, the unreceived data packet is considered lost. M3. The sender resends the data packet according to the sequence number of the first lost data packet.

[0124] For example, the sender sends 4 data packets, each of which has a unique sequence number: data packet 1 (sequence number 1), data packet 2 (sequence number 2), data packet 3 (sequence number 3), and data packet 4 (sequence number 4).

[0125] The sender sends 4 data packets, each of which has a unique sequence number: data packet 1 (sequence number 1), data packet 2 (sequence number 2), data packet 3 (sequence number 3), and data packet 4 (sequence number 4).

[0126] The sender sets an unacknowledged tolerance window of 200 milliseconds.

[0127] Step M1: Send data packet and record confirmation message Packet 1 is sent at time T1=10:00:00.

[0128] Packet 2 is sent at time T2 = 10:00:01.

[0129] Packet 3 is sent at time T3 = 10:00:02.

[0130] Packet 4 is sent at time T4 = 10:00:03.

[0131] Step M2: Wait for confirmation message and determine loss The sender receives the OTP_ACK confirmation message for data packet 1 at time T5=10:00:04 and records the confirmation time.

[0132] The sender waits for confirmation messages for data packets 2, 3, and 4.

[0133] At time T6 = 10:00:06, the sender finds that the unacknowledged tolerance window of data packet 2 has been exceeded (T2 + 200ms = 10:00:01 + 200ms = 10:00:01.2), but has not received the confirmation message of data packet 2, so it determines that data packet 2 is the first lost data packet.

[0134] Similarly, the sender also finds that the unacknowledged tolerance windows of packets 3 and 4 have expired (T3 + 200ms = 10:00:02.2 and T4 + 200ms = 10:00:03.2), but their acknowledgment messages have not arrived, so they are also marked as lost.

[0135] Step M3: Resend lost packets The sender resends data packet 2 (sequence number 2) at time T7 = 10:00:06.

[0136] The sender resends data packet 3 (sequence number 3) at time T8 = 10:00:07.

[0137] The sender resends data packet 4 (sequence number 4) at time T9 = 10:00:08.

[0138] In this example, the sender sends 4 data packets and waits for confirmation messages after sending them. Since no confirmation messages for data packets 2, 3, and 4 are received within the unconfirmed tolerance window, the sender marks these data packets as lost and resends them in sequence. This process ensures that data packets can be reliably transmitted in the event of network delays or packet loss.

[0139] refer to Fig.11 As shown in (b) and 12 (b), the receiving end packet loss detection method specifically includes: N1. The receiving end records the receiving time of each received data packet and calculates the time interval between every two consecutive data packets; Record the interval time: When the receiving end successfully receives two consecutive data packets, record the interval time; interval time = time when the latter data packet is received - time when the first data packet is received; the receiving time is represented by a timestamp, which can also be selected according to specific needs; The interval time is used to calculate the congestion window and compare the out-of-order tolerance window time; N2. When the receiving end receives a data packet, it checks the sequence number of the data packet. If the receiving end finds that there is an unreceived data packet with an earlier sequence number than the current data packet, it preliminarily determines that the unreceived data packet is a second preliminarily lost data packet; Time comparison: If the message received by the receiver is a data packet with a later sequence number, it means that the sender should have sent all the data packets sent before it; N3. If the estimated receiving time of the second preliminary lost data packet plus the time of the disorder tolerance window is still less than the current time, the second preliminary lost data packet is marked as the second lost data packet; the estimated receiving time of the second preliminary lost data packet is the receiving time of the previous data packet plus the interval time; If an earlier data packet is not received, a certain degree of disorder is tolerated by setting a time window; Out-of-order tolerance window: A certain degree of out-of-order is tolerated by setting a time window. Within this time window, even if a later-sent data packet is received, the receiver will not immediately mark the earlier data packet as lost; N4. The receiving end sends an OTP_NACK message to the sending end, wherein the OTP_NACK message carries the sequence number of the second lost data packet, requesting the sending end to resend the second lost data packet; Request the sender to resend: Send an OTP_NACK message with the expected message sequence number to the sender, requesting the sender to resend the message.

[0140] For example: The sender sends 4 data packets, each of which has a unique sequence number: data packet 1 (sequence number 1), data packet 2 (sequence number 2), data packet 3 (sequence number 3), and data packet 4 (sequence number 4).

[0141] The receiving end sets an out-of-order tolerance window of 150 milliseconds.

[0142] Step N1: Record the receiving time and calculate the interval time Packet 1 is received by the receiver at time T1=10:00:00.

[0143] Data packet 2 is received by the receiving end at time T2=10:00:01.

[0144] The receiving end records the time interval between data packet 1 and data packet 2: ΔT12 = T2 - T1 = 1 second.

[0145] Step N2: Check the packet sequence number and determine if it is lost The receiver received packet 4 (sequence number 4) at time T3 = 10:00:02, but did not receive packet 3 (sequence number 3).

[0146] The receiving end finds that there is an unreceived data packet (data packet 3) with a sequence number earlier than the current data packet, and therefore preliminarily determines that data packet 3 is the second preliminarily lost data packet.

[0147] Step N3: Calculate the out-of-order tolerance window and mark lost packets The expected reception time of packet 3 is T2 + ΔT12 = 10:00:01 + 1 second = 10:00:02.

[0148] At time T4 = 10:00:03, the receiver finds that the expected reception time of packet 3 plus the out-of-order tolerance window (10:00:02 + 150ms = 10:00:02.15) has expired, but packet 3 has not arrived yet, so it marks packet 3 as the second lost packet.

[0149] Step N4: Send OTP_NACK message to request retransmission The receiving end sends an OTP_NACK message to the sending end at time T4=10:00:03, with the sequence number of data packet 3 attached in the message, requesting the sending end to resend data packet 3.

[0150] In this example, after receiving data packet 4, the receiver finds that data packet 3 has not arrived within the out-of-order tolerance window, so it determines that data packet 3 is lost and sends an OTP_NACK message to request the sender to resend data packet 3. This process ensures that data packets can be reliably transmitted in the case of network out-of-order or packet loss.

[0151] Both the sender and the receiver use packet loss detection algorithms to quickly and effectively detect packet loss and reduce packet loss delays.

[0152] The main idea of ​​the present invention is: (1) Low-latency design: Providing microsecond-level latency for real-time AI processing and model training.

[0153] (2) Reduce software intervention: Reduce dependence on the CPU, thereby improving efficiency and performance.

[0154] (3) Simplified protocol stack: Simplify the traditional TCP / IP protocol stack, especially at the transport layer, reduce the complexity of the protocol to reduce latency, retain the TCP three-way handshake, remove TCP TIME_WAIT and other states, and reduce the additional delay when closing the connection. Even the waiting time at the millisecond level can be reduced, achieving microsecond-level latency, which helps reduce network congestion under high load conditions.

[0155] (4) Flow control and congestion management: Congestion is handled based on source-side control strategies and local link levels. A fixed-size SRAM buffer is used instead of TCP's dynamic congestion window, which helps reduce the complexity of congestion management. The unified congestion control window helps achieve more consistent performance in low-latency networks and optimizes the low-latency and low-packet-loss environment in supercomputer networks.

[0156] (5) Bidirectional time-based packet loss detection algorithm: Both the sender and the receiver use a packet loss detection algorithm to quickly and effectively detect packet loss and reduce packet loss delay.

[0157] The method for establishing and transmitting an interactive network transport layer protocol proposed in this embodiment has the following beneficial effects: 1) Modify the TCP state machine and the protocol interaction process: The TCP three-way handshake mechanism is retained, and data is sent synchronously during the third handshake to reduce data transmission time; Removing the TIME_WAIT state and various waiting states can effectively reduce the waiting time on both the sending and receiving ends, reduce the additional delay when closing the connection, improve protocol efficiency, and help reduce network congestion under high load conditions.

[0158] 2) When the connection is established, the window size is determined based on the smallest SRAM buffer size in the hardware of the sender and server. When the buffer is full, the transmission stops, and the packet loss is handled by retransmitting the data stored in the SRAM buffer. This method reduces the complexity of congestion control; 3) It handles congestion by simply discarding data packets, uses fast retransmission and fast recovery to manage network congestion, and does not use congestion control algorithms such as slow start and congestion avoidance. Compared with traditional TCP congestion control algorithms (such as Reno), the response time scale is shorter and more suitable for supercomputer application scenarios.

[0159] 4) Bidirectional packet loss detection algorithm: Both the sender and the receiver use the packet loss detection algorithm to quickly and effectively detect packet loss and reduce packet loss delay.

[0160] Through these mechanisms, the new protocol is able to reduce network congestion while maintaining high throughput, which is critical for AI training and other high-performance computing tasks. The new transmission protocol is suitable for efficiently handling large-scale data transmission in supercomputer environments, and is particularly suitable for artificial intelligence training and reasoning.

[0161] The parts of the present invention that are not described in detail are prior art. It is obvious to those skilled in the art that the present invention is not limited to the details of the above-mentioned exemplary embodiments, and the present invention can be implemented in other specific forms without departing from the spirit or basic characteristics of the present invention; therefore, no matter from which point of view, the embodiments should be regarded as exemplary and non-restrictive, and it is intended that all changes that fall within the meaning and scope of equivalent elements are included in the present invention.

Claims

1. A method for establishing interaction of a network transport layer protocol, applied to a sending end, characterized in that: The steps include: A1. The sender sends an OTP_SYN message to the receiver to request to establish a connection; the OTP_SYN message includes the sender's initial sequence number ISN1; A2, the sending end receives an OTP_SYN_ACK message from the receiving end, which includes the initial sequence number ISN2 of the receiving end and the confirmation sequence number of the sending end; the sending end confirmation sequence number is generated after the receiving end receives the OTP_SYN message; the sending end confirmation sequence number is equal to the initial sequence number ISN1 of the sending end plus 1; A3. After receiving the OTP_SYN_ACK message, the sender adds 1 to the sender's initial sequence number ISN1 and compares it with the sender's confirmation sequence number in the OTP_SYN_ACK message segment. If the two are equal, the sender sends an OTP_ACK message containing the receiver's confirmation sequence number to the receiver to establish a connection between the sender and the receiver; and puts the transmission data into the payload of the message for data transmission; the receiver's confirmation sequence number is equal to the receiver's initial sequence number ISN2 plus 1.

2. The method according to claim 1, characterized in that The method further comprises: A4. The sender sends an OTP_FIN message to the receiver, where the OTP_FIN message includes a close sequence number of the sender. A5. After receiving the OTP_FIN_ACK message, the sender adds 1 to the sender's closing sequence number and compares it with the sender's closing confirmation sequence number in the OTP_FIN_ACK message segment. If the two are equal, the connection between the sender and the receiver is closed. A6. When the sending end receives the OTP_FIN message from the receiving end, it sends back an OTP_FIN_ACK message including the receiving end's closing confirmation sequence number to the receiving end; the receiving end's closing confirmation sequence number is the receiving end's closing sequence number in the received OTP_FIN message plus 1; the sending end closes the connection between the sending end and the receiving end; the OTP_FIN message includes the receiving end's closing sequence number.

3. The method according to claim 1, characterized in that The step A1 further includes: the sending end calculates the first congestion window and the first MSS according to its own sending buffer size and the network interface type, and packages the two into an OTP_SYN message and sends it to the receiving end; The step A2 further includes: the receiving end calculates the second congestion window and the second MSS according to the size of its receiving buffer and the type of the network interface, and packages the smaller value of the first congestion window and the second congestion window as the third congestion window and the smaller value of the first MSS and the second MSS as the third MSS into an OTP_SYN_ACK message replied to the sending end; The step A3 also includes: the sending end receives the OTP_SYN_ACK message sent by the receiving end, packs the third congestion window and the third MSS into an ACK message and sends it to the receiving end, and the sending end sends a data message according to the third congestion window and the third MSS.

4. The method according to claim 1, characterized in that: Step A3 also includes the following steps: M1, the sender records the sending time and sequence number of each data packet and waits for the receipt of the confirmation message; M2. If the waiting time exceeds the unconfirmed tolerance window time and the confirmation message of the data packet that should be received is still not received, the data packet is judged to be the first lost data packet; the receiving time of the data packet should be less than the sending time of the data packet plus the value of the unconfirmed tolerance window time. If it is greater, it is considered that the confirmation message of the data packet that should be received has not been received; M3. The sender resends the data packet according to the sequence number of the first lost data packet.

5. A method for establishing interaction of a network transport layer protocol, applied to a receiving end, characterized in that: The steps include: B1, the receiving end receives the OTP_SYN message from the sending end; the OTP_SYN message includes the sending end initial sequence number ISN1; B2. After receiving the OTP_SYN message from the sender, the receiver sends back an OTP_SYN_ACK message containing the initial sequence number ISN2 of the receiver and the confirmation sequence number of the sender as a response; the confirmation sequence number of the sender is equal to the initial sequence number ISN1 of the sender plus 1; B3. After the receiving end receives the OTP_ACK message containing the receiving end confirmation sequence number from the sending end, the receiving end establishes a connection with the sending end and starts receiving data; the receiving end confirmation sequence number is equal to the receiving end initial sequence number ISN2 plus 1.

6. The method according to claim 5, characterized in that The method further comprises: B4. After receiving the OTP_FIN message from the sender, the receiving end sends back an OTP_FIN_ACK message including the sender's closing confirmation number to the sender; the sender's closing confirmation number is the sender's closing number in the received OTP_FIN message plus 1; the receiving end closes the data reception from the sender; the OTP_FIN message includes the sender's closing number; B5. The receiving end sends an OTP_FIN message to the sending end, wherein the OTP_FIN message includes a closing sequence number of the receiving end; B6. After receiving the OTP_FIN_ACK message, the receiving end adds 1 to the receiving end closing sequence number and compares it with the receiving end closing confirmation sequence number in the OTP_FIN_ACK message segment. If the two are equal, the connection between the sending end and the receiving end is closed; the receiving end closing confirmation sequence number is the receiving end closing sequence number in the received OTP_FIN message plus 1.

7. The method according to claim 5, characterized in that The B1 also includes: the OTP_SYN message includes a first congestion window and a first MSS calculated by the sender according to its own send buffer size and network interface type; The B2 also includes: the receiving end calculates the second congestion window and the second MSS according to the size of its receiving buffer and the type of the network interface, and packages the smaller value of the first congestion window and the second congestion window as the third congestion window and the smaller value of the first MSS and the second MSS as the third MSS into an OTP_SYN_ACK message replied to the sending end; The B3 also includes: the receiving end receives the data message according to the third congestion window and the third MSS.

8. The method according to claim 5, characterized in that Step B3 also includes the following steps: N1. The receiving end records the sequence number and receiving time of each received data packet, and calculates the time interval between every two consecutive data packets; N2. When the receiving end receives a data packet, it checks the sequence number of the data packet. If the receiving end finds that a data packet with a smaller sequence number than the current data packet has not been received, it preliminarily determines that the unreceived data packet is a second preliminary lost data packet; N3. If the estimated receiving time of the second preliminary lost data packet plus the time of the disorder tolerance window is still less than the current time, the second preliminary lost data packet is marked as the second lost data packet; the estimated receiving time of the second preliminary lost data packet is the receiving time of the previous data packet plus the interval time; N4. The receiving end sends an OTP_NACK message to the sending end. The OTP_NACK message carries the sequence number of the second lost data packet, requesting the sending end to resend the second lost data packet.

9. A transmission method of a network transport layer protocol, characterized in that: The method is applied to the sending end, The sending end starts data transmission and enters the OPENED state after executing the interactive establishment method as claimed in claim 1, indicating that the connection is established; After the sending end sends the OTP_FIN message, the sending end enters the CLOSE SEND state; and after receiving the OTP_FIN_ACK message from the receiving end, the TCB is deleted, the sending end closes the sending connection, and the state changes to the CLOSED state; After receiving the OTP_FIN message, the sending end enters the CLOSE RCVD state, sends an OTP_FIN_ACK message to the receiving end, deletes the TCB, closes the receiving connection, and the state changes to the CLOSED state.

10. A transmission method of a network transport layer protocol, characterized in that: The method is applied to the receiving end, The receiving end starts data transmission and enters the OPENED state after executing the interactive establishment method as claimed in claim 5, indicating that the connection is established; After the receiving end sends the OTP_FIN message, the receiving end enters the CLOSE SEND state; and after receiving the OTP_FIN_ACK message from the sending end, the TCB is deleted, the receiving end closes the sending connection, and the state changes to the CLOSED state; After receiving the OTP_FIN message, the receiving end enters the CLOSE RCVD state, sends an OTP_FIN_ACK message to the sending end, deletes the TCB, and the receiving end closes the receiving connection, and the state changes to the CLOSED state.

Images