Data transmission controller and method for generating data transmission packets according to a modified quic protocol

Abstract

A data transfer controller is configured to generate one or more data transfer packets according to a modified QUIC protocol by generating one or more fields in the one or more data transfer packets having a fixed field size and generating a predefined number of frames of different frame types in the one or more data transfer packets in a predefined frame type order. The data transfer controller enables a hardware offload variant of the QUIC protocol to accomplish an efficient hardware implementation of the modified QUIC protocol.

Description

Technical Field

[0001] This invention generally relates to the field of networking, and more specifically, to a data transmission controller and method for generating data transmission messages according to a modified QUIC protocol. Background Technology

[0002] Transmission Control Protocol (TCP) is a widely used communication protocol that enables the exchange of messages between computing devices in a network environment, specifically using the Internet Protocol. However, due to the high latency of TCP, QUIC is now used as the Internet transport protocol. QUIC typically runs on User Datagram Protocol (UDP). Generally, QUIC is implemented in the user space of the operating system, rather than being integrated into the operating system as it is with TCP. QUIC is replacing TCP because it provides reliable transport for application protocols used to exchange information, such as Hypertext Transfer Protocol version 3 (HTTPv3).

[0003] The QUIC protocol is designed for software implementation and offers significant flexibility compared to TCP, allowing the introduction of new protocol features without requiring changes to the operating system. However, due to its high security and enhanced recovery and congestion management, QUIC's software implementation is computationally intensive, requiring high CPU utilization. Therefore, hardware implementation (i.e., hardware offloading of the QUIC protocol) is necessary. Typically, in the QUIC protocol, QUIC messages are encapsulated with a User Datagram Protocol (UDP) header, appearing as UDP messages to network routers, intermediate boxes, and the operating system. The QUIC header format typically includes many variable-length fields, such as connection identification (ID) and version identifiers. However, processing these variable-length fields requires complex iterative parsing. Furthermore, the connection ID, the first variable-length field in the QUIC protocol, is determined per connection and is parsed in the incoming QUIC message. Therefore, each endpoint in the QUIC protocol needs to maintain per-connection state, which includes the length of the connection ID field in the QUIC protocol. Furthermore, the QUIC protocol defines different types of frames, such as stream frames and acknowledgment (ACK) frames, which are included in QUIC messages, each with its own frame header. Additionally, when a QUIC message is received, the beginning of the message does not include all frame headers, and additional headers may be present deep within the received message. Therefore, additional QUIC messages may be needed to receive all frame headers. Moreover, the traditional QUIC protocol does not define a specific order for these frames, so any combination of frames is possible within a received QUIC message. These characteristics make the QUIC protocol hardware-insensitive and challenging for hardware parsing. Furthermore, the flexibility of the QUIC protocol also makes hardware implementation difficult, requiring complex and inefficient hardware logic, thus presenting technical challenges for hardware offloading from the traditional QUIC protocol. In some scenarios, the QUIC protocol requires the host running the QUIC protocol to consume expensive resources, but the QUIC protocol does not provide a general application program interface (API) for applications that need to achieve efficient resource consumption through hardware offloading.

[0004] Therefore, based on the above discussion, it is necessary to overcome the aforementioned drawbacks associated with hardware offloading of the QUIC protocol. Summary of the Invention

[0005] This invention provides a data transmission controller for generating data transmission messages according to a modified QUIC protocol. It also provides a data transmission method for generating data transmission messages according to the modified QUIC protocol. This invention provides a solution to existing problems in the hardware implementation of the conventional QUIC protocol. The object of this invention is to provide a solution that at least partially overcomes the problems encountered in the prior art and provides an improved data transmission controller and method for generating data transmission messages according to a modified QUIC protocol for hardware offloading.

[0006] One or more objects of the present invention are achieved by the solutions provided in the appended independent claims. Advantageous embodiments of the invention are further defined in the dependent claims.

[0007] In one aspect, the present invention provides a data transmission controller, wherein the data transmission controller is configured to generate one or more data transmission messages according to a modified QUIC protocol by generating one or more fields with a fixed field size in the one or more data transmission messages, and generating a predefined number of frames of different frame types in the one or more data transmission messages in a predefined frame type order.

[0008] This invention provides an improved data transmission controller for generating one or more data transmission packets according to a modified QUIC protocol (also known as an offload variant of QUIC (or OQUIC) protocol). Because the one or more data transmission packets include fixed field sizes and a predefined number of frames in a predefined frame type order, the data transmission controller does not require expensive resource consumption to perform hardware offloading of the QUIC protocol (i.e., OQUIC) compared to conventional controllers. Furthermore, due to the fixed field sizes, the data transmission controller does not require complex iterative parsing to process one or more fields, nor does it need to maintain per-connection state including the length of each field, compared to conventional controllers. Therefore, the computational intensity of this invention is much lower than conventional methods. Advantageously, the data transmission controller uses a subset of the QUIC protocol's functionality in a manner that supports a hardware offload variant of the QUIC protocol to achieve an efficient hardware implementation of the OQUIC protocol. Therefore, this data transmission controller implements an OQUIC protocol for hardware offloading, which may be standardized in the Internet Engineering Task Force (IETF), potentially further influencing and enhancing the way people design, use, and manage the Internet.

[0009] In one implementation, the data transmission controller is further configured to limit the number of frames in each of the one or more data transmission messages to a maximum number of frames defined for each data transmission message.

[0010] By limiting the number of frames per data transmission message to the maximum defined number of frames per data transmission message, the hardware parsing of the modified QUIC protocol can be managed within the data transmission controller.

[0011] In another implementation, the data transmission controller is further configured to set the number of frames for each data transmission message to the maximum number of frames defined for each data transmission message.

[0012] By setting the number of frames per data transmission message to the maximum number of frames defined for each data transmission message, the hardware parsing of the modified QUIC protocol can be managed within the data transmission controller.

[0013] In another implementation, the data transfer controller is also used to set all fields of a field type to a fixed field type size.

[0014] By setting all fields of a field type to a fixed field type size, the data transfer controller does not need complex iterative parsing to process fields.

[0015] In another implementation, the data transmission controller is further configured to include a version number in the one or more data transmission messages, the version number indicating the protocol version to be used.

[0016] Including a version number in one or more data transmission messages is advantageous because the version number indicates the protocol version of the data transmission controller, which is used for a hardware implementation of the modified QUIC protocol based on the desired application.

[0017] In another implementation, the data transmission controller is further configured to include a mode in the one or more data transmission messages, the mode indicating whether the data transmission message is to be encrypted.

[0018] As a pattern in one or more data transmission messages, it is used to indicate whether the data transmission message should be encrypted. Therefore, compared with traditional methods, transmission controllers with hardware offloading variants of the QUIC protocol (also known as modified QUIC or OQUIC protocol) are not limited to encryption.

[0019] In another implementation, the data transmission controller further includes a communication interface, wherein the data transmission controller is also configured to initiate a communication session with a communication device through the communication interface, and define communication parameters during the initiation of the communication session, wherein the communication parameters include field size and frame type order, and wherein the predefined number of frames is a finite number of frames negotiated based on the communication parameters when establishing a connection with the communication device.

[0020] Because the communication parameters include field size and frame type order, the field size and frame type order can be fixed to an indicated size (or negotiated to a smaller value) based on the communication parameters during the initiation of a communication session with the communication device. Advantageously, the predefined number of frames is constant after the connection establishment negotiation and remains constant throughout the connection's lifetime.

[0021] In another implementation, the communication parameters also include the maximum number of frames per data transmission message.

[0022] The maximum number of frames per data transmission message is beneficial for the hardware parsing of the modified QUIC protocol within the data transmission controller.

[0023] In another implementation, the field size includes one or more field type sizes.

[0024] Because the field size includes one or more field type sizes, the data transfer controller does not need to retain the field size (or per connection state) that includes one or more fields.

[0025] In another implementation, at least one of the field type sizes is zero (0).

[0026] The advantage is that at least one of the field type sizes being zero indicates that the corresponding field does not exist, and the corresponding field type can be reserved for future use.

[0027] In another implementation, the communication parameters also include the parsing depth.

[0028] Since the communication parameters also include the resolution depth, the data transmission controller is able to negotiate the resolution depth for the hardware resolution of the modified QUIC protocol.

[0029] In another implementation, the data transmission controller is further configured to negotiate one or more of the communication parameters with the communication device during the initialization of the communication session.

[0030] The data transmission controller can also flexibly negotiate in different aspects by negotiating one or more communication parameters with the communication device during the initialization of the communication session.

[0031] In another implementation, the data transmission controller is also used to execute an application-program interface (API) with two modes: a stream-aware mode and a stream-insensitive mode.

[0032] It is advantageous to implement an application-program interface (API) with both stream-aware and stream-non-aware modes because the data transfer controller provides and enables a generic socket class API that allows applications to run on a modified QUIC protocol (i.e., the OQUIC protocol) as an alternative to the traditional transmission control protocol (TCP), for example, for applications that require efficient resource consumption through hardware offloading.

[0033] In another implementation, the stream-aware mode is based on one or more generated data transmission packets.

[0034] Since the stream-aware mode is based on one or more generated data transmission messages, new applications (e.g., Hypertext Transfer Protocol version 3) can benefit from using multiple QUIC streams per connection (e.g., QUIC streams of data transmission messages) and using the stream-aware application programming interface.

[0035] In another implementation, the application-program interface (API) is configured to enable applications designed for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) to run on the modified QUIC protocol.

[0036] Because the application programming interface (API) is designed to enable applications designed for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) to run on the modified QUIC protocol (i.e., the OQUIC protocol), the API executes legacy applications without changing the stream-aware mode.

[0037] In another implementation, the stream-aware mode is the Transmission Control Protocol (TCP) socket application-program interface (API).

[0038] Since Stream Insensible Mode is a Transmission Control Protocol socket application interface, the modified QUIC protocol has a general application interface. This modified QUIC protocol is implemented through hardware offloading to run various applications.

[0039] In another implementation, the stream-aware mode is the User Datagram Protocol (UDP) socket application programming interface (API).

[0040] Since the stream-aware mode is a user datagram protocol (UDP) socket application interface, the modified QUIC protocol has a general application interface. This modified QUIC protocol is implemented through hardware offloading to run various applications.

[0041] In another implementation, the data transmission controller is used to process at least some of the generated data in hardware.

[0042] It is advantageous to process at least some of the generation in hardware because the data transfer controller defines possible extensions to the traditional QUIC protocol (or the next-generation transfer control protocol), making it more versatile in hardware implementations.

[0043] In another implementation, the data transmission controller is used to receive data transmission messages and parse the received data transmission messages in hardware.

[0044] It is advantageous to parse the received data transmission messages in hardware because the data transmission controller defines a subset of the QUIC protocol that makes it hardware-friendly.

[0045] In another implementation, the data transmission controller is hardware-based.

[0046] Because the data transfer controller is hardware-based, it can significantly improve the performance of hardware-based servers and hosts running the modified QUIC protocol.

[0047] In another aspect, the present invention provides a data transmission method for generating one or more data transmission messages, comprising: generating the one or more data transmission messages according to a modified QUIC protocol by: generating one or more fields with a fixed field size in the one or more data transmission messages, and generating a predefined number of frames of different frame types in the one or more data transmission messages in a predefined frame type order.

[0048] The disclosed data transmission method achieves all the technical effects of the data transmission controller of the present invention.

[0049] In another aspect, the present invention provides a data transmission method, wherein the data transmission controller is configured to: receive incoming data, the incoming data including Transmission Control Protocol (TCP) instructions or User Datagram Protocol (UDP) instructions and instructions according to an application programming interface (API); generate one or more data transmission packets for the modified QUIC protocol based on the TCP or UDP instructions and the instructions according to the API, wherein the API includes two modes: a stream-aware mode and a stream-non-aware mode.

[0050] The disclosed data controller method achieves all the technical effects of the present invention.

[0051] In another aspect, the present invention provides a data transmission method for generating one or more data transmission packets according to the modified QUIC protocol, wherein the method includes: receiving incoming data, the incoming data including Transmission Control Protocol (TCP) instructions or User Datagram Protocol (UDP) instructions and instructions according to an application programming interface (API); generating one or more data transmission packets for the modified QUIC protocol according to the TCP instructions or UDP instructions and based on the instructions according to the API, wherein the API includes two modes: a stream-aware mode and a stream-non-aware mode.

[0052] The disclosed data transmission method achieves all the technical effects of the data transmission controller of the present invention.

[0053] It should be understood that all the above implementations can be combined. It should be noted that all devices, elements, circuits, units, and modules described in this application can be implemented in software or hardware elements or any combination thereof. All steps performed by the various entities described in this application, and the functions described as being performed by the various entities, are intended to indicate that the respective entities are suitable for or used to perform the respective steps and functions. Although in the following description of specific embodiments, a particular function or step performed by an external entity is not reflected in the detailed description of the specific element of the entity performing that particular step or function, it should be apparent to those skilled in the art that these methods and functions can be implemented in the corresponding hardware or software elements or any combination thereof. It should be understood that the features of the invention are readily combined in various combinations without departing from the scope of the invention as defined by the appended claims.

[0054] Additional aspects, advantages, features and objects of the invention will become apparent from the accompanying drawings and the detailed description of illustrative implementations as explained in conjunction with the following appended claims. Attached Figure Description

[0055] The above-described invention and the following detailed description of illustrative embodiments can be better understood when read in conjunction with the accompanying drawings. Exemplary structures of the invention are shown in the drawings to illustrate the invention. However, the invention is not limited to the specific methods and tools disclosed herein. Furthermore, those skilled in the art will understand that the drawings are not drawn to scale. Where possible, the same elements are represented by the same numbers.

[0056] The following figures will now be used as examples to describe embodiments of the present invention, wherein:

[0057] Figure 1A This is a block diagram of a data transmission controller provided in an embodiment of the present invention;

[0058] Figure 1B This is a block diagram of a data transmission controller provided in another embodiment of the present invention;

[0059] Figure 2 This is a block diagram of a data transmission controller provided in another embodiment of the present invention;

[0060] Figure 3 This is a flowchart of a data transmission method for generating one or more data transmission messages according to a modified QUIC protocol, based on an embodiment of the present invention.

[0061] Figure 4 This is a flowchart of a data transmission method for generating one or more data transmission messages according to a modified QUIC protocol, as described in another embodiment of the present invention.

[0062] Figure 5AThis is a block diagram of the X-over-QUIC offload variant (OQUIC) application interface provided in an embodiment of the present invention;

[0063] Figure 5B This is a block diagram of the X-over-QUIC offload variant (OQUIC) application interface provided in another embodiment of the present invention;

[0064] In the accompanying diagrams, underlined numbers indicate the item in which the underlined number is located or the item adjacent to the underlined number. Ununderlined numbers are associated with the item identified by the line that links the ununderlined number to the item. When a number is ununderlined and has an associated arrow, the ununderlined number is used to identify the general item that the arrow points to. Detailed Implementation

[0065] The following detailed description illustrates embodiments of the present invention and ways in which these embodiments can be implemented. Although some modes of implementing the invention have been disclosed, those skilled in the art will recognize that other embodiments for implementing or practicing the invention may also exist.

[0066] Figure 1A This is a block diagram of a data transmission controller provided in an embodiment of the present invention. (See reference) Figure 1A A block diagram 100A of a data transmission controller 102 is shown. One or more data transmission messages 104A to 104N, frames 106A and 106B, one or more fields 108A to 108N, a communication interface 110, and a communication device 112 are also shown.

[0067] In one aspect, the present invention provides a data transmission controller 102, wherein the data transmission controller 102 is configured to generate one or more data transmission messages 104A to 104N according to a modified QUIC protocol by: generating one or more fields 108A to 108N with fixed field sizes in the one or more data transmission messages 104A to 104N; and generating a predefined number of frames of different frame types in the one or more data transmission messages 104A to 104N in a predefined frame type order.

[0068] The data transmission controller 102 includes suitable logic, circuitry, interfaces, and / or code for generating one or more data transmission messages 104A to 104N according to a modified QUIC protocol (also known as an offloaded variant of QUIC, or OQUIC protocol). In one example, the data transmission controller 102 communicates by exchanging one or more data transmission messages 104A to 104N. The data transmission controller 102 may also be referred to as a data transmission device, controller, server, client, etc.

[0069] One or more data transmission messages 104A to 104N, along with frames 106A and 106B, are the basic units of data transmission used by the modified QUIC protocol. Data transmission messages 104A to 104N are smaller and similar data structures derived from the data block to be sent. Once received, these data transmission messages 104A to 104N are reassembled into a data block.

[0070] Frames 106A and 106B carry control information and other data, which are used by the data transmission controller 102 for communication between endpoints. Examples of frames 106A and 106B include, but are not limited to, PING frames, stream frames, and acknowledgment (ACK) frames.

[0071] Fields 108A to 108N are used during the transmission of one or more data transmission messages 104A to 104N. Examples of fields 108A to 108N include, but are not limited to, source port, destination port, sequence number, acknowledgment number, header length, flags, window size, etc.

[0072] Communication interface 110 includes suitable logic, circuitry, and / or interfaces for initiating a communication session with communication device 112. Communication device 112 includes suitable logic, circuitry, and / or interfaces that enable communication interface 110 to establish a communication session, for example, with a server. Examples of communication interface 110 may include, but are not limited to, an antenna, a telematics unit, a radio frequency (RF) transceiver, one or more amplifiers, one or more oscillators, a digital signal processor, a codec-decoder (CODEC) chipset, and / or a subscriber identity module (SIM) card.

[0073] In operation, the data transmission controller 102 is used to generate one or more data transmission messages 104A to 104N according to the modified QUIC protocol by generating one or more fields 108A to 108N with fixed field sizes in one or more data transmission messages 104A to 104N. The data transmission controller 102 is also used to generate one or more data transmission messages 104A to 104N by generating a predefined number of frames of different frame types in a predefined frame type order within the one or more data transmission messages 104A to 104N. In other words, the data transmission controller 102 uses the modified QUIC protocol (or OQUIC protocol) to generate one or more data transmission messages 104A to 104N, and also generates a predefined number of frames with different frame types, such as frame 106A and frame 106B. The predefined number of frames may be a finite number of frames negotiated, for example, when establishing a connection with communication device 112. Compared to traditional methods, the advantage is that each frame is arranged in a predefined frame type order within one or more data transmission messages 104A to 104N, for example, within data transmission message 104A, such as... Figure 1AAs shown. In one example, the frames generated by the data transmission controller 102 have a fixed, known order among frame types; for example, a stream frame always precedes an ACK frame. Therefore, compared to conventional methods, there may be predefined combinations of frame types within one or more data transmission messages 104A to 104N. In one implementation, each frame may be associated with one or more fields 108A to 108N. For example, frame 106A may be associated with field 108A, and frame 106B may be associated with subsequent fields. Furthermore, one or more fields 108A to 108N generated within one or more data transmission messages 104A to 104N have a fixed field size (or a constant size); for example, field 108A generated by the data transmission controller 102 has a fixed field size. In one example, the Connection ID (for both source (SRC) and destination (DST)) field, the message sequence number, and other fields generated by the data transmission controller 102 are considered to have fixed field sizes (in bits), as shown in Table 1. Therefore, the data transmission controller 102 does not require complex iterative parsing to process one or more fields 108A to 108N. Furthermore, due to the defined sizes of fields 108A to 108N, the data transmission controller 102 does not need to maintain per-connection states including the lengths of the corresponding fields 108A to 108N, compared to conventional methods. Moreover, since the data transmission controller 102 is used to generate one or more data transmission messages 104A to 104N according to the modified QUIC protocol, the data transmission controller 102 does not require costly resource consumption to run the modified QUIC protocol. Furthermore, the data transmission controller 102 uses a subset of the QUIC protocol's functionality in a manner that enables hardware offloading of the modified QUIC protocol. In one example, hardware offloading of the QUIC protocol is also referred to as a hardware offloading variant of the QUIC protocol (or OQUIC). In one example, one or more fields 108A to 108N may be part of the modified QUIC header format and may be part of the frame format of some specific frames 106A and 106B. Table 1 below shows the fixed field sizes for different fields (e.g., fields 108A to 108N). In Table 1, the first column shows the field names, and the second column shows the corresponding fixed field sizes. In one example, some fields in Table 1, such as "Length (Message)", correspond to the modified QUIC header fields. Additionally, some fields in Table 1, such as "Length (Frame)", correspond to frame fields. Furthermore, some fields are specific to particular frame types; for example, "ACK Delay" in Table 1 is for ACK frame formats.

[0074] Table 1

[0075]

[0076]

[0077] According to an embodiment, the data transmission controller 102 is further configured to limit the number of frames in each of one or more data transmission messages 104A to 104N to a defined maximum number of frames for each data transmission message. In other words, the data transmission controller 102 defines an upper limit on the number of frames such as frame 106A and frame 106B in one or more data transmission messages 104A to 104N. In one example, the maximum number of frames for each data transmission message is limited to two frames for each data transmission message 104A to 104N. For example, the data transmission controller 102 limits frames 106A and 106B for data transmission message 104A, and the subsequent two frames are limited by the data transmission controller 102 for data transmission message 104B. Furthermore, when data transmission messages 104A and 104B are received by the receiver, the beginning of each of data transmission messages 104A and 104B will include all the headers of each frame. For example, the beginning of data transmission message 104A includes the headers of frames 106A and 106B. Similarly, the beginning of data transmission message 104B includes the headers of the subsequent two frames. Therefore, no additional frames (and headers) exist deep within data transmission messages 104A and 104B, making it easy for the modified QUIC protocol to be parsed by hardware within the data transmission controller 102. Table 2 below shows an example of a short frame header. Table 2 below shows the beginning of a data transmission message (e.g., data transmission message 104A). The beginning of the data transmission message (in row 1) includes a short header (in row 2), and there are no additional frames within the corresponding data transmission message, as shown in row 2 of Table 2. The destination connection ID (along with its length in bits), message number (along with its length in bits), and the payload of the corresponding data transmission message are also shown.

[0078] Table 2

[0079]

[0080] According to an embodiment, the data transmission controller 102 is further configured to set the number of frames for each data transmission message to the maximum number of frames defined for each data transmission message 104A to 104N. In other words, the data transmission controller 102 defines a fixed number of frames for each data transmission message. In one example, the maximum number of frames for each data transmission message 104A to 104N is set to two frames for each data transmission message 104A to 104N, for example, frames 106A and 106B are set (or fixed) by the data transmission controller 102 for data transmission message 104A, etc. Furthermore, when the receiver receives one or more data transmission messages 104A to 104N, the beginning of each data transmission message 104A to 104N will include all the headers of the corresponding frame. Therefore, there are no extra frames (and headers) deep within the data transmission messages 104A to 104N, making it easy for the modified QUIC protocol to be parsed by hardware within the data transmission controller 102.

[0081] According to an embodiment, the data transmission controller 102 is further configured to set all fields 108A to 108N of the field type to a fixed field type size. In other words, the field type of all fields 108A to 108N is set to a fixed field type size. Therefore, different fields 108A to 108N of different field types will have a fixed field type size, and the data transmission controller 102 does not need complex iterative parsing to process all fields 108A to 108N.

[0082] According to an embodiment, the data transmission controller 102 is further configured to include a version number in one or more data transmission messages 104A to 104N, the version number indicating the protocol version to be used. In other words, one or more data transmission messages 104A to 104N generated according to the modified QUIC protocol include a version number indicating the protocol version to be used. In one example, the version number indicating the protocol version is used to identify the modified QUIC protocol of the present invention, which is also referred to as a hardware offload variant of the QUIC protocol (or OQUIC). Furthermore, the version number indicates the protocol version of the hardware offload variant of the QUIC protocol based on the desired application of the data transmission controller 102.

[0083] In other words, in this embodiment, the data transfer controller 102 implements a hardware offload variant of the QUIC protocol, which includes extensions and adjustments not defined in the standard QUIC protocol specification. Specifically, the hardware offload variant of the QUIC protocol can use different version numbers (or newer versions) than the standard QUIC protocol and can include new parameters that are not used in the standard QUIC protocol.

[0084] According to an embodiment, the data transmission controller 102 is further configured to include a mode in one or more data transmission messages 104A to 104N that indicates whether the data transmission messages 104A to 104N should be encrypted. In other words, the mode (e.g., an insecure operating mode) included by the data transmission controller 102 in one or more data transmission messages 104A to 104N indicates whether one or more data transmission messages 104A to 104N should be encrypted. In one example, encryption of one or more data transmission messages 104A to 104N is disabled in the mode, for example, in an insecure operating mode, which can be used in internal domains and restricted networks. Advantageously, compared to conventional methods, the data transmission controller 102 with a hardware offload variant of the QUIC protocol is not limited to encryption.

[0085] In other words, in this embodiment, the data transmission controller 102 supports interoperability with a standard implementation of the modified QUIC protocol by configuring the standard implementation to a specific operating mode that conforms to the previously specified attributes (or falling back to the standard QUIC protocol). For example, if a majority of nodes in the network (i.e., devices participating in the network) support hardware offloading of the QUIC protocol, a modified QUIC protocol with hardware offloading can be used. Furthermore, connections to nodes that do not support hardware offloading of the QUIC protocol can be made using a standard QUIC protocol with a software implementation (i.e., the conventional way of the QUIC protocol). Therefore, the data transmission controller 102 supports interoperability with relatively small performance losses.

[0086] According to an embodiment, the data transmission controller 102 further includes a communication interface 110. The data transmission controller 102 is also configured to initiate a communication session with the communication device 112 via the communication interface 110. The data transmission controller 102 is further configured to define communication parameters during the initiation of the communication session, wherein the communication parameters include field sizes and frame type order, and wherein a predefined number of frames is a finite number of frames negotiated based on the communication parameters when establishing a connection with the communication device 112. In other words, the data transmission controller 102 includes a communication interface 110 for initiating a communication session (or establishing a connection) with the communication device 112. Furthermore, during the initiation of the communication session, the communication parameters are defined by the data transmission controller 102, wherein the communication parameters include field sizes of fields 108A to 108N and a predefined number of frames (e.g., frames 106A and 106B) in frame type order. Therefore, the field sizes of fields 108A to 108N and the frame type order of the frames can be fixed to the indicated sizes, for example, a smaller value negotiated based on the communication parameters during the initiation of the communication session with the communication device 112. The communication parameters are also used to negotiate a finite (or constant) number of predefined frames, such as frames 106A and 106B, when establishing a connection with communication device 112. Advantageously, compared to the traditional QUIC protocol, the predefined number of frames in the modified QUIC protocol remains constant after connection establishment negotiation and also remains constant throughout the connection's lifetime.

[0087] In other words, the data transmission controller 102 is used to define communication parameters (or modules) to negotiate modified QUIC protocol attributes based on communication parameters such as the field size (or length) of fields 108A to 108N and the frame type order of frames (e.g., frames 106A and 106B). In one example, the communication parameters can be negotiated during communication session initialization, and once negotiated, the communication parameters will remain fixed for the lifetime of the communication session (or connection). Furthermore, based on the version of the modified QUIC protocol and hardware capabilities, the communication parameters will remain fixed for the lifetime of all connections.

[0088] According to an embodiment, the communication parameters also include the maximum number of frames per data transmission message. In one example, after the initiation of a communication session, data transmission messages 104A to 104N are generated based on communication parameters, including the maximum number of frames per data transmission message, such as a maximum of two frames 106A and 106B per data transmission message. Furthermore, when data transmission messages 104A and 104B are received (e.g., by communication device 112 or data transmission controller 102), the beginning of each of data transmission messages 104A and 104B will include all the headers of each frame. Therefore, compared to conventional methods, there are no extra frames (and headers) deep within data transmission messages 104A and 104B, which makes it easier for the modified QUIC protocol to be parsed by hardware within the data transmission controller 102.

[0089] According to an embodiment, the field size includes one or more field type sizes. Therefore, during the initiation of a communication session, the field size of one or more fields 108A to 108N can be fixed to an indicated size (or negotiated to a smaller value) based on one or more field type sizes. Furthermore, the data transmission controller 102 does not need to retain the field size (or per connection state) that includes the field sizes of one or more fields 108A to 108N.

[0090] According to the embodiment, at least one of the field type sizes is zero. In other words, at least one of fields 108A to 108N can be negotiated at size zero based on the field type size, which means that the corresponding field does not exist and can be reserved for future use.

[0091] According to an embodiment, the communication parameters also include a parsing depth. Because the communication parameters include a parsing depth, the data transmission controller 102 can negotiate the parsing depth for hardware parsing of the modified QUIC protocol.

[0092] According to an embodiment, the data transmission controller 102 is also configured to negotiate one or more communication parameters with the communication device 112 during communication session initialization. Therefore, the data transmission controller 102 with a hardware offload variant of the QUIC protocol can also negotiate flexibly in various aspects.

[0093] According to an embodiment, the data transmission controller 102 is also configured to execute an application-program interface (API) with two modes: a stream-aware mode and a stream-insensitive mode. In other words, the data transmission controller 102 is configured to execute the application interface. Furthermore, the application interface supports two operating modes, such as a stream-aware mode and a stream-insensitive mode. In one example, the stream-aware mode is aware of QUIC streams (e.g., QUIC streams of one or more data transmission packets 104A to 104N) and also supports applications (e.g., web applications) defining multiple QUIC streams. Conversely, the stream-insensitive mode is not aware of QUIC streams.

[0094] Therefore, the data transfer controller 102 with an offloaded variant of the QUIC protocol is highly useful in performance-sensitive environments (i.e., requiring low latency) such as Hypertext Transfer Protocol Secure (HTTPS) web servers. Furthermore, the offloaded variant of the QUIC protocol can be used for non-HTTP applications running on the traditional QUIC protocol. Additionally, the data transfer controller 102 provides and enables a generic socket class application interface, allowing applications to run on the modified QUIC protocol, replacing the traditional transmission control protocol (TCP), for example, for applications requiring efficient resource consumption through hardware offloading.

[0095] In one implementation, the data transfer controller 102 executes an application programming interface (API) that can be designed in a generic manner to support various application types running on offloaded variants of the QUIC protocol. Examples of such application types include, but are not limited to, remote direct memory access (RDMA) and various other applications that are either stream-aware or stream-non-aware. Since QUIC streams are a concept not present in the transport control protocol, legacy applications are expected to potentially need to run transparently on the data transfer controller 102 with offloaded variants of the QUIC protocol in a stream-non-aware manner. Furthermore, legacy applications such as the secure shell protocol (SSH) (or file transfer protocol (FTP)) can run on the stream-non-aware API in a way that supports a smooth migration from existing implementations.

[0096] According to an embodiment, the stream-aware mode is based on one or more generated data transmission packets 104A to 104N. Because the stream-aware mode is based on one or more data transmission packets 104A to 104N, new applications (e.g., Hypertext Transfer Protocol version 3) can benefit from using multiple QUIC streams per connection and utilizing stream-aware application programming interfaces (APIs). Furthermore, applications written in stream-aware mode run on the modified QUIC protocol and are aware of the various API calls related to the modified QUIC protocol details.

[0097] According to an embodiment, the application-program interface (API) is configured to enable applications designed for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) to run on the modified QUIC protocol. In other words, the API performs a stream-aware mode that runs legacy applications without modification, meaning the legacy applications perceive themselves as running on Transmission Control Protocol (or UDP sockets). Furthermore, the data transmission controller 102 performs a special API to bridge differences to the modified QUIC protocol and, in turn, bridge back to the original differences on the receiver (e.g., the data transmission controller 102).

[0098] According to an embodiment, the stream-aware mode is the Transmission Control Protocol (TCP) socket application-program interface (API). In one implementation, the TCP API can hide whether the QUIC protocol is offloaded by hardware in stream-aware mode, which is unaware of QUIC-based streams. Therefore, a few connections, such as those to another communication device, can be offloaded in hardware, while others can run in software. For example, standard QUIC connections are offloaded in software, while offload variants of QUIC (OQUIC) connections are offloaded in hardware. Thus, for the QUIC protocol, there exists a generic application interface that presents the QUIC protocol as the TCP API to applications, which is implemented through hardware offloading for various applications to run. Furthermore, applications using the TCP API are subsequently bridged to the OQUIC API offloaded to hardware.

[0099] According to an embodiment, the stream-aware mode is the User Datagram Protocol (UDP) socket application-program interface (API). In one implementation, the UDP API can hide whether the modified QUIC protocol is offloaded by hardware in stream-aware mode. Therefore, a few connections, such as connections to other communication devices, can be offloaded in hardware, while other connections can run in software. For example, standard QUIC connections are offloaded in software, while offloaded variants of QUIC are offloaded in hardware. Therefore, for the modified QUIC protocol, there exists a generic application interface that presents the UDP API to applications.

[0100] According to an embodiment, the data transfer controller 102 is used to process at least some of the generated data in hardware. In other words, the data transfer controller 102 is used to process at least some of the generated data in a hardware offload variant of the modified QUIC protocol. Therefore, the data transfer controller 102 defines a possible extension to the traditional QUIC protocol (or next-generation transmission control protocol), making it more versatile in hardware implementations.

[0101] According to an embodiment, the data transmission controller 102 is used to receive data transmission messages and parse the received data transmission messages in hardware. In other words, the data transmission controller 102 is used to receive data transmission messages, such as data transmission message 104A, from a communication device such as communication device 112. Optionally, the beginning of the received data transmission message includes all headers, making the data transmission controller 102 hardware-friendly. Furthermore, the data transmission controller 102 defines a subset of the QUIC protocol that makes it hardware-friendly.

[0102] According to an embodiment, the data transmission controller 102 is hardware-based. In other words, the data transmission controller 102 is efficient for hardware implementations of the modified QUIC protocol. Furthermore, the data transmission controller 102 can significantly improve the performance of hardware-based servers and hosts running the modified QUIC protocol.

[0103] Therefore, the data transmission controller 102 utilizes a subset of the QUIC protocol's functionality in a way that enables hardware offloading of the QUIC protocol. Since the data transmission controller 102 is used to generate one or more data transmission messages 104A to 104N according to the modified QUIC (or OQUIC) protocol, it does not require the costly resource consumption of running the modified QUIC protocol. Furthermore, due to the fixed size of fields 108A to 108N, the data transmission controller 102 does not require complex iterative parsing to process one or more fields 108A to 108N, nor does it need to maintain per-connection state including the length of the corresponding fields 108A to 108N. This hardware offloading of the QUIC protocol is used for Remote Direct Memory Access (RoQET) via QUIC Resilient Transport, an alternative to Remote Direct Memory Access (RDMA) over-converged Ethernet (RoCE), offering reliability and low latency, and enabling deployment on wide area networks (WANs). Another potential use case for hardware offloading of the QUIC protocol is non-volatile memory-express (NVMe)-over-QUIC, which could be an alternative to non-volatile memory-express (NVMe)-over-faric, as well as NVMe-over-TCP, which is affected by the TCP issues that QUIC addresses.

[0104] This invention provides an efficient hardware implementation of the modified QUIC protocol. It can also significantly improve the performance of servers and hosts running the modified QUIC protocol and provides a universal application programming interface (API) for running various applications on the hardware offload implementation. Therefore, this data transfer controller 102, which implements a hardware offload variant of the QUIC protocol (also known as OQUIC), may be standardized within the Internet Engineering Task Force (IETF), potentially further influencing and enhancing the way the Internet is designed, used, and managed.

[0105] Figure 1B This is a block diagram of a data transmission controller provided in another embodiment of the present invention. Figure 1B and Figure 1A The components are shown together. (Reference) Figure 1B The diagram shows a block diagram 100B of a data transmission controller 102. In one implementation, the data transmission controller 102 further includes control circuitry 114, a memory 116, and a communication interface 110.

[0106] In this implementation, the operations performed by the data transfer controller 102 can be executed and controlled by the control circuit 114. Examples of the control circuit 114 may include, but are not limited to, microprocessors, microcontrollers, complex instruction set computing (CISC) processors, application-specific integrated circuit (ASIC) processors, reduced instruction set (RISC) processors, very long instruction word (VLIW) processors, central processing units (CPUs), state machines, data processing units, and other processors or circuits.

[0107] Memory 116 includes suitable logic, circuitry, and / or interfaces for storing one or more data transmission messages 104A to 104N generated by data transmission controller 102. Examples of implementations of memory 116 may include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), dynamic random access memory (DRAM), random access memory (RAM), read-only memory (ROM), hard disk drive (HDD), flash memory, secure digital (SD) cards, solid-state drives (SSDs), and / or CPU cache memory. Communication interface 110 may also be referred to as a network interface, including suitable logic, circuitry, and / or interfaces for communicating with… Figure 1A Communication with external devices such as communication equipment 112.

[0108] Figure 2 This is a block diagram of a data transmission controller provided in another embodiment of the present invention. Figure 2 and Figure 1A and Figure 1B The components are shown together. (Reference) Figure 2A block diagram 200 shows a data transmission controller 102 and incoming data 202. The incoming data 202 includes Transmission Control Protocol (TCP) instructions 204 or User Datagram Protocol (UDP) instructions 206. The incoming data 202 also includes instructions 210 according to an application-program interface (API) 208. The API 208 includes a stream-aware mode 212 and a stream-insensitive mode 214.

[0109] Incoming data 202 includes Transmission Control Protocol (TCP) instructions 204, User Datagram Protocol (UDP) instructions 206, and instructions 210 according to application programming interface (API) 208. In one example, incoming data 202 is received from a network sniffer (e.g., a wire), where both flow-aware and flow-non-aware modes are OQUIC messages, such as data transmission messages 104A to 104N. Furthermore, the conversion of incoming data 202 is performed at the software / firmware / hardware (SW / FW / HW) layer that changes TCP instructions 204 to OQUIC, and also at the network sniffer, so messages such as data transmission messages 104A to 104N will appear as OQUIC messages. In other words, at the network sniffer (or wire), incoming data 202 includes OQUIC messages. Optionally, the TCP instructions 204, UDP instructions 206, and instructions 210 of incoming data 202 correspond to the sequence order provided to the data transmission controller 102. Transmission Control Protocol (TCP) instruction 204 also includes multiple TCP instructions 204A to 204N, and User Datagram Protocol (UDP) instruction 206 also includes multiple UDP instructions 206A to 206N. Similarly, instruction 210 from application programming interface (API) 208 also includes multiple instructions 210A to 210N.

[0110] Stream-aware mode 212 corresponds to the mode that is aware of QUIC streams, and stream-insensitive mode 214 corresponds to the mode that is not aware of QUIC streams.

[0111] In another aspect, the present invention provides a data transmission controller 102, wherein the data transmission controller 102 is used for:

[0112] Receive incoming data 202 (e.g. from the application layer), the incoming data 202 includes transmission control protocol (TCP) instructions 204 or user datagram protocol (UDP) instructions 206 and instructions 210 according to application-program interface (API) 208;

[0113] One or more data transmission messages 104A to 104N are generated according to the modified QUIC protocol based on the transmission control protocol (TCP) instruction 204 or the user datagram protocol (UDP) instruction 206 and the instruction 210 of the application-program interface (API) 208. The application-program interface (API) 208 includes two modes: a stream-aware mode 212 and a stream-insensitive mode 214.

[0114] In operation, the data transmission controller 102 receives incoming data 202. The incoming data 202 includes Transmission Control Protocol (TCP) instructions 204 or User Datagram Protocol (UDP) instructions 206 and instructions 210 according to the application programming interface (API) 208. The data transmission controller 102 generates one or more data transmission messages 104A to 104N for the modified QUIC protocol based on the TCP instructions 204 or UDP instructions 206 and the instructions 210 according to the API 208. The API 208 includes two modes: a flow-aware mode 212 and a flow-insensitive mode 214. In other words, the data transmission controller 102 receives the incoming data 202 and generates one or more data transmission messages 104A to 104N for the modified QUIC (i.e., OQUIC) protocol, for example, generating data transmission message 104A for the modified QUIC protocol. In one implementation, incoming data 202 is received from the application layer via a communication interface. This incoming data 202 includes field sizes 108A to 108N and a predefined frame type order. Since the incoming data 202 includes Transmission Control Protocol (TCP) instructions 204 (or User Datagram Protocol (UDP) instructions 206) and instructions 210 from the Application Programming Interface (API) 208, the Data Transmission Controller 102 generates one or more data transmission messages 104A to 104N for the modified QUIC protocol based on the TCP instructions 204 (or UDP instructions 206) and also based on the instructions 210 from the API 208. In one implementation, the API 208 is executed by the Data Transmission Controller 102 and includes a stream-aware mode 212 and a stream-insensitive mode 214. Therefore, the Data Transmission Controller 102 uses the modified QUIC protocol, such as an offloaded variant of the QUIC protocol, which can be used in performance-sensitive environments, such as Hypertext Transfer Protocol Secure (HTTPS) web servers. Furthermore, offloading variants of the QUIC protocol can also be used for non-HTTP applications running on the traditional QUIC protocol. Therefore, the data transfer controller 102 provides and enables a generic socket class application interface 208, allowing applications to run on the modified QUIC protocol, replacing the traditional transmission control protocol (TCP), for example, for applications requiring efficient resource consumption through hardware offloading.

[0115] In one implementation, the data transfer controller 102 executes an application programming interface 208, which can be designed in a generic manner to support various application types running on offloaded variants of the QUIC protocol. Examples of application types include, but are not limited to, remote direct memory access (RDMA) and various other applications from either stream-aware mode 212 or stream-insensitive mode 214. Since QUIC streams are a concept not present in the transport control protocol, legacy applications are expected to potentially need to run transparently on the data transfer controller 102 with an offloaded variant of the QUIC protocol in a stream-insensitive manner. Furthermore, legacy applications such as the secure shell protocol (SSH) (or file transfer protocol (FTP)) can run on the stream-insensitive application interface in a manner that supports a smooth migration from existing implementations.

[0116] Since the data transmission controller 102 is used to generate one or more data transmission messages 104A to 104N for the modified QUIC protocol, the data transmission controller 102 does not require expensive resource consumption to run the modified QUIC protocol. Furthermore, the data transmission controller 102 uses a subset of the QUIC protocol functionality in a way that enables hardware offloading of the QUIC protocol.

[0117] According to an embodiment, the stream-aware mode 214 is a Transmission Control Protocol (TCP) socket application-program interface (API). In one implementation, the TCP API can hide whether the modified QUIC protocol is offloaded by hardware in stream-aware mode 214, which is unaware of QUIC streams. Therefore, a few connections, such as connections to other communication devices, can be offloaded in hardware, while other connections can run in software. For example, standard QUIC connections are offloaded in software, while offload variants of QUIC (OQUIC) connections are offloaded in hardware. Thus, for the modified QUIC protocol, there exists a generic application interface that presents the modified QUIC protocol as a TCP API to applications, which is implemented through hardware offloading for various applications to run.

[0118] According to an embodiment, the stream-aware mode 214 is a User Datagram Protocol (UDP) socket application-program interface (API). In one implementation, the UDP API can hide whether the modified QUIC protocol is offloaded by hardware in stream-aware mode 214. Therefore, a few connections, such as connections to other communication devices, can be offloaded in hardware, while other connections can run in software. For example, standard QUIC connections are offloaded in software, while offloaded variants of QUIC are offloaded in hardware. Therefore, for the modified QUIC protocol, there is a generic application interface that presents itself to applications as the UDP API.

[0119] According to an embodiment, the stream-aware mode 212 includes instructions for generating one or more data transmission packets 104A to 104N in such a way as to generate one or more fields 108A to 108N with a fixed field size in the one or more data transmission packets 104A to 104N, and to generate a predefined number of frames of different frame types in the one or more data transmission packets 104A to 104N in a predefined frame type order. In other words, the data transmission controller 102 is used to receive instructions from the stream-aware mode 212 of the application programming interface 208. The instructions received from the stream-aware mode 212 are also used to generate a predefined frame type order of fixed field sizes for fields 108A to 108N and a predefined number of frames (e.g., frames 106A and 106B). Thereafter, one or more data transmission packets 104A to 104N (e.g., for the OQUIC protocol) are generated, which include a predefined frame type order of fixed field sizes for fields 108A to 108N and a predefined number of frames. For example, a data transmission message 104A is generated from an instruction received from the self-flow sensing mode 212. Data transmission message 104A includes fixed field sizes for fields 108A to 108N and a predefined number of frames in a predefined frame type order, such as... Figure 2 As shown. Therefore, within one or more data transmission messages 104A to 104N, there may be a predefined number of frames (e.g., frames 106A and 106B) in a predefined combination of frame types. Furthermore, due to the fixed size of fields 108A to 108N, the data transmission controller 102 does not require complex iterative parsing to process one or more fields 108A to 108N within one or more data transmission messages 104A to 104N.

[0120] According to an embodiment, the flow-aware mode 212 includes instructions for limiting the number of frames in each of one or more data transmission packets 104A to 104N to a defined maximum number of frames for each data transmission packet. In other words, the instructions from the flow-aware mode 212 are used by the data transmission controller 102 to define an upper limit on the number of frames in one or more data transmission packets 104A to 104N, for example, for data transmission packets 104A and 104B. In one example, the maximum number of frames for each data transmission packet is limited to two frames for each data transmission packet 104A to 104N. For example, the data transmission controller 102 limits frames 106A and 106B for data transmission packet 104A, and the subsequent two frames are defined by the data transmission controller 102 for data transmission packet 104B. Furthermore, when data transmission packets 104A and 104B are received by a receiver (e.g., a communication device), the beginning of each of data transmission packets 104A and 104B will include all the headers of each frame. For example, the beginning of data transmission message 104A includes the headers of frames 106A and 106B. Similarly, the beginning of data transmission message 104B includes the headers of the following two frames. Therefore, there are no additional frames (and headers) deep within data transmission messages 104A and 104B, which makes it easy for the modified QUIC protocol to be parsed by hardware within the data transmission controller 102.

[0121] According to an embodiment, the stream-aware mode 212 includes instructions for setting all fields of a field type to a fixed field type size. In other words, the instructions from the stream-aware mode 212 are used by the data transmission controller 102 to set the field types of all fields 108A to 108N to a fixed field type size. Therefore, different fields 108A to 108N of different field types will have different fixed field type sizes, and compared to conventional methods, the data transmission controller 102 does not need complex iterative parsing to process all fields 108A to 108N.

[0122] According to an embodiment, the flow-aware mode 212 includes instructions for processing at least some of the generated data in hardware. Since the instructions from the flow-aware mode 212 are used by the data transfer controller 102 to process at least some of the generated data in hardware, the data transfer controller 102 defines possible extensions to the conventional QUIC protocol (or next-generation transmission control protocol), making it more versatile in hardware implementations.

[0123] Therefore, the data transfer controller 102 utilizes a subset of the QUIC protocol's functionality in a manner capable of hardware offloading the QUIC protocol. This invention provides an efficient hardware implementation of the modified QUIC protocol. This invention can also significantly improve the performance of servers and hosts running the modified QUIC protocol and provides a general application programming interface 208 to run various applications on the hardware offload implementation. Therefore, this data transfer controller 102, which implements a hardware offload variant of the QUIC protocol (also known as OQUIC), may be standardized within the Internet Engineering Task Force (IETF), potentially further influencing and enhancing the way the Internet is designed, used, and managed.

[0124] Figure 3 This is a flowchart of a data transmission method for generating one or more data transmission messages according to an embodiment of the present invention. Figure 3 Combination Figure 1A , Figure 1B and Figure 2 Component description. About Figure 3 This illustrates a data transmission method 300 for generating one or more data transmission messages 104A to 104N according to a modified QUIC protocol. The data transmission method 300 includes steps 302 and 304.

[0125] In another aspect, the present invention provides a data transmission method 300 for generating one or more data transmission messages 104A to 104N, comprising generating one or more data transmission messages 104A to 104N according to a modified QUIC protocol by: generating one or more fields 108A to 108N with fixed field sizes in the one or more data transmission messages 104A to 104N; and generating a predefined number of frames of different frame types in the one or more data transmission messages 104A to 104N in a predefined frame type order.

[0126] This invention provides a data transmission method 300 for generating one or more data transmission messages 104A to 104N according to a modified QUIC protocol. The data transmission method 300 uses a subset of the QUIC protocol functionality in a manner that enables hardware offloading of the QUIC protocol. Because the data transmission method 300 is used to generate one or more data transmission messages according to the modified QUIC protocol, the data transmission method 300 does not require expensive resource consumption to run the modified QUIC protocol. Furthermore, the data transmission method 300 uses a subset of the QUIC functionality in a manner that enables hardware offloading of the QUIC protocol.

[0127] In step 302, the data transmission method 300 includes generating one or more data transmission messages 104A to 104N with fixed field sizes according to a modified QUIC protocol by generating one or more fields 108A to 108N with fixed field sizes in one or more data transmission messages 104A to 104N. In other words, the data transmission method 300 uses the modified QUIC protocol to generate fields 108A to 108N with fixed field sizes. Thereafter, one or more data transmission messages 104A to 104N are generated (e.g., for the modified QUIC protocol) that include fields 108A to 108N with fixed field sizes. For example, data transmission message 104A includes fields 108A to 108N with fixed field sizes. In one example, the connection ID field (for both source (SRC) and destination (DST)) and the message sequence number, and other fields generated by the data transmission method 300 are considered to have defined (or fixed) field sizes (in bits). Therefore, due to the defined size of fields 108A to 108N, data transmission method 300 does not require complex iterative parsing to process one or more fields 108A to 108N within one or more data transmission messages 104A to 104N.

[0128] In step 304, the data transmission method 300 further includes generating a predefined number of frames of different frame types in one or more data transmission messages 104A to 104N according to a predefined frame type order. In other words, the data transmission method 300 uses a modified QUIC protocol to generate a predefined number of frames (e.g., frames 106A and 106B) in a predefined frame type order. Subsequently, one or more data transmission messages 104A to 104N are generated (e.g., for the modified QUIC protocol), which include a predefined number of frames in a predefined frame type order. Furthermore, each frame is arranged within one or more data transmission messages 104A to 104N in a predefined frame type order. For example, data transmission message 104A includes frames 106A and 106B in a predefined frame type order. Alternatively, frames 106A and 106B generated by the data transmission method 300 have a fixed, known order among frame types, for example, a stream frame always precedes an ACK frame. Therefore, within one or more data transmission messages 104A to 104N, there may be predefined combinations of frame types, which makes it hardware-friendly.

[0129] According to an embodiment, the data transmission method 300 further includes limiting the number of frames in each of the one or more data transmission messages 104A to 104N to a defined maximum number of frames per data transmission message. In other words, the data transmission method 300 includes defining an upper limit on the number of frames, such as frames 106A and 106B in one or more data transmission messages 104A to 104N. In one example, the maximum number of frames per data transmission message is limited to two frames per data transmission message 104A to 104N. Therefore, there are no extra frames (and headers) deep within the received data transmission messages 104A and 104B, making it easy for the modified QUIC protocol to be parsed by hardware within the data transmission controller 102.

[0130] According to an embodiment, the data transmission method 300 further includes setting the number of frames for each data transmission message to a maximum number of frames defined for each data transmission message 104A to 104N. In other words, the data transmission method 300 includes defining an upper limit on the number of frames for each data transmission message. In one example, the maximum number of frames for each data transmission message is set to two frames per data transmission message, making it easier for the modified QUIC protocol to be parsed by hardware within the data transmission controller 102.

[0131] According to an embodiment, the data transmission method 300 further includes setting all fields 108A to 108N of the field type to a fixed field type size. In other words, the data transmission method 300 includes setting the field type of all fields 108A to 108N to a fixed field type size. Therefore, different fields 108A to 108N of different field types will have a fixed field type size, and the data transmission controller 102 does not need complex iterative parsing to process all fields 108A to 108N.

[0132] According to an embodiment, the data transmission method 300 further includes a version number in one or more data transmission messages 104A to 104N, the version number indicating the protocol version to be used. In other words, one or more data transmission messages 104A to 104N generated according to the modified QUIC protocol include a version number indicating the protocol version to be used. In one example, the version number indicating the protocol version is used to identify the modified QUIC protocol of the present invention, which is also referred to as a hardware offload variant of the QUIC protocol (or OQUIC).

[0133] According to an embodiment, the data transmission method 300 further includes a mode in one or more data transmission messages 104A to 104N that indicates whether the data transmission messages 104A to 104N should be encrypted. In other words, the mode (e.g., an insecure operating mode) included in one or more data transmission messages 104A to 104N by the data transmission method 300 indicates whether one or more data transmission messages 104A to 104N should be encrypted. In one example, encryption of one or more data transmission messages 104A to 104N is disabled in the mode, for example, in an insecure operating mode, which can be used in internal domains and restricted networks. Advantageously, compared to conventional methods, the data transmission method 300 with a hardware offload variant of the QUIC protocol is not limited to encryption.

[0134] According to an embodiment, the data transmission method 300 further includes a communication interface 110. The data transmission method 300 also includes initiating a communication session with a communication device 112 through the communication interface 110. The data transmission method 300 further includes defining communication parameters during the initiation of the communication session, wherein the communication parameters include field sizes and frame type order, and wherein a predefined number of frames is a finite number of frames negotiated based on the communication parameters when establishing a connection with the communication device 112. In other words, the data transmission method 300 includes a communication interface 110 for initiating a communication session (or establishing a connection) with the communication device 112. Furthermore, during the initiation of the communication session, the communication parameters are defined by a data transmission controller 102, wherein the communication parameters include field sizes of fields 108A to 108N and a predefined number of frames (e.g., frames 106A and 106B) in frame type order. Therefore, the field sizes of fields 108A to 108N and the frame type order of the frames can be fixed to the indicated sizes, for example, a smaller value negotiated based on the communication parameters during the initiation of the communication session with the communication device 112. The communication parameters are also used to negotiate a finite (or constant) number of predefined frames, such as frames 106A and 106B, when establishing a connection with communication device 112. Advantageously, compared to the traditional QUIC protocol, the predefined number of frames in the modified QUIC protocol remains constant after connection establishment negotiation and also remains constant throughout the connection's lifetime.

[0135] According to an embodiment, the data transmission method 300 further includes executing an application-program interface (API) with two modes: a stream-aware mode and a stream-insensitive mode. In other words, the data transmission method 300 also includes executing the application interface. Furthermore, the application interface supports two operating modes, such as a stream-aware mode and a stream-insensitive mode. In one example, the stream-aware mode is aware of QUIC streams (e.g., QUIC streams of one or more data transmission packets 104A to 104N) and also supports applications (e.g., web applications) defining multiple QUIC streams. Conversely, the stream-insensitive mode is not aware of QUIC streams.

[0136] According to an embodiment, the data transmission method 300 further includes processing at least some of the generated data in hardware. In other words, the data transmission method 300 also includes processing at least some of the generated data in a hardware offload variant of the modified QUIC protocol. Therefore, the data transmission method 300 defines a possible extension to the traditional QUIC protocol (or a next-generation transmission control protocol), making it more versatile in hardware implementations.

[0137] According to an embodiment, the data transmission method 300 further includes receiving data transmission messages and parsing the received data transmission messages in hardware. In other words, the data transmission method 300 also includes receiving data transmission messages, such as data transmission message 104A, from a communication device such as communication device 112. Optionally, the beginning of the received data transmission message includes all headers, making the data transmission method 300 hardware-friendly. Furthermore, the data transmission method 300 defines a subset of the QUIC protocol that makes it hardware-friendly.

[0138] According to an embodiment, when a computer-readable medium carrying computer instructions is loaded into and executed by the control circuitry 114 of the data transfer controller 102, the data transfer controller 102 is enabled to implement the data transfer method 300. In one aspect, a computer program product is provided, comprising a non-transitory computer-readable medium storing computer instructions executable by the data transfer controller 102 to perform the data transfer method 300. Examples of implementations of the non-transitory computer-readable medium include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), read-only memory (ROM), hard disk drive (HDD), flash memory, secure digital (SD) cards, solid-state drives (SSDs), computer-readable storage media, and / or CPU cache memory. The computer-readable medium used to provide non-transitory storage may include, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof.

[0139] Therefore, data transmission method 300 utilizes a subset of the QUIC protocol's functionality in a manner that enables hardware offloading of the QUIC protocol. Since data transmission method 300 is used to generate one or more data transmission messages 104A to 104N according to the modified QUIC (or OQUIC) protocol, it does not require expensive resource consumption to run the modified QUIC protocol. Furthermore, due to the fixed size of fields 108A to 108N, data transmission method 300 does not require complex iterative parsing to process one or more fields 108A to 108N, nor does it require maintaining per-connection state including the length of the corresponding fields 108A to 108N. Hardware offloading of the QUIC protocol is used for Remote Direct Memory Access (RoQET) via QUIC Resilient Transport, an alternative to Remote Direct Memory Access (RDMA) over-converged Ethernet (RoCE), offering reliability and low latency, and can be deployed on wide area networks (WANs). Another potential use case for hardware offloading of the QUIC protocol is non-volatile memory-express (NVMe)-over-QUIC, which could be an alternative to non-volatile memory-express (NVMe)-over-faric, as well as NVMe-over-TCP, which is affected by the TCP issues that QUIC addresses.

[0140] This invention provides an efficient hardware implementation of the modified QUIC protocol. The data transmission method 300 can also significantly improve the performance of servers and hosts running the modified QUIC protocol and provides a universal application programming interface to run various applications on the hardware offload implementation. Therefore, this data transmission method 300, which implements a hardware offload variant of the QUIC protocol (also known as OQUIC), may be standardized within the Internet Engineering Task Force (IETF), potentially further influencing and enhancing the way the Internet is designed, used, and managed.

[0141] Figure 4 This is a flowchart of a data transmission method for generating one or more data transmission messages according to another embodiment of the present invention. Figure 4 Combination Figure 1A , Figure 1B and Figure 2 The components are shown. Regarding... Figure 4The present invention illustrates a data transmission method 400 for generating one or more data transmission messages 104A to 104N according to a modified QUIC protocol. The data transmission method 400 includes steps 402 and 404.

[0142] In another aspect, the present invention provides a data transmission method 400 for generating one or more data transmission packets 104A to 104N according to a modified QUIC protocol. The method 400 includes: receiving incoming data 202, the incoming data 202 including a transmission control protocol (TCP) instruction 204 or a user datagram protocol (UDP) instruction 206 and instructions 210 according to an application-program interface (API) 208; generating one or more data transmission packets 104A to 104N for the modified QUIC protocol according to the transmission control protocol (TCP) instruction 204 or the user datagram protocol (UDP) instruction 206, and based on the instructions 210 according to the application-program interface (API) 208, wherein the application-program interface (API) 208 includes two modes: a stream-aware mode 212 and a stream-insensitive mode 214.

[0143] This invention provides a data transmission method 400 for generating one or more data transmission messages 104A to 104N according to a modified QUIC protocol. Since the data transmission method 400 is used to generate one or more data transmission messages according to the modified QUIC protocol, it does not require expensive resource consumption to run the modified QUIC protocol. Furthermore, the data transmission method 400 uses a subset of QUIC functionality in a manner that enables hardware offloading of the QUIC protocol.

[0144] In step 402, the data transmission method 400 includes receiving incoming data 202, which includes Transmission Control Protocol (TCP) instructions 204 or User Datagram Protocol (UDP) instructions 206, and instructions 210 according to application programming interface (API) 208. In other words, the data transmission method 400 includes receiving incoming data 202, which includes Transmission Control Protocol instructions 204 (or UDP instructions 206) and instructions 210 from application programming interface 208. In one example, incoming data 202 is received from a network sniffer (e.g., a wire), where both flow-aware and flow-non-aware modes are OQUIC messages, such as data transmission messages 104A to 104N. Furthermore, the conversion of incoming data 202 is performed at the software / firmware / hardware (SW / FW / HW) layer that changes Transmission Control Protocol (TCP) instructions 204 to OQUIC, and also at the network sniffer. For example, data transmission packets 104A to 104N will appear as OQUIC packets. In other words, at the network sniffer (or wire), incoming data 202 always includes OQUIC packets. In one implementation, incoming data 202 includes the field sizes of fields 108A to 108N and a predefined frame type order, which the data transmission method 400 uses to generate one or more data transmission packets 104A to 104N.

[0145] In step 404, the data transmission method 400 includes: generating one or more data transmission packets 104A to 104N for the modified QUIC protocol according to Transmission Control Protocol instruction 204 (or User Datagram Protocol instruction 206) and instruction 210 of application programming interface (API) 208, wherein the API 208 includes two modes: a flow-aware mode 212 and a flow-insensitive mode 214. In other words, the data transmission method 400 includes receiving incoming data 202 and generating one or more data transmission packets 104A to 104N for the modified QUIC protocol, for example, generating data transmission packet 104A for the modified QUIC protocol. Since the incoming data 202 includes Transmission Control Protocol (TCP) instructions 204 (or User Datagram Protocol (UDP) instructions 206) and instructions 210 from the Application Programming Interface (API) 208, the data transmission method 400 generates one or more data transmission messages 104A to 104N for the modified QUIC protocol based on the TCP instructions 204 (or UDP instructions 206) and also based on the instructions 210 from the API 208. In one implementation, the API 208 is executed by the data transmission method 400 and includes a stream-aware mode 212 and a stream-insensitive mode 214. Therefore, the data transmission method 400 uses the modified QUIC protocol, such as an offloaded variant of the QUIC protocol, which can be used in performance-sensitive environments, such as Hypertext Transfer Protocol Secure (HTTPS) web servers. Furthermore, the data transmission method 400 can also be used for non-HTTP applications running on the traditional QUIC protocol. Therefore, the data transmission method 400 provides and enables the generic socket class application interface 208, enabling applications to run on the modified QUIC protocol to replace the traditional transmission control protocol (TCP), for example, for applications that require efficient resource consumption through hardware offloading.

[0146] In one implementation, data transfer method 400 executes application programming interface 208, which can be designed in a generic manner to support various application types running on offloaded variants of the QUIC protocol. Examples of application types include, but are not limited to, remote direct memory access (RDMA) and various other applications from either stream-aware mode 212 or stream-insensitive mode 214. Since QUIC streams are a concept not present in the transport control protocol, legacy applications are expected to potentially need to run transparently on data transfer method 400 with offloaded variants of the QUIC protocol in a stream-insensitive manner. Furthermore, legacy applications such as secure shell protocol (SSH) (or file transfer protocol (FTP)) can run on the stream-insensitive application interface in a manner that supports a smooth migration from existing implementations.

[0147] Since data transmission method 400 is used to generate one or more data transmission messages 104A to 104N for the modified QUIC protocol, data transmission method 400 does not require expensive resource consumption to run the modified QUIC protocol. Furthermore, data transmission method 400 uses a subset of the QUIC protocol's functionality in a way that enables hardware offloading of the QUIC protocol.

[0148] According to an embodiment, when a computer-readable medium carrying computer instructions is loaded into and executed by the control circuitry 114 of the data transfer controller 102, the data transfer controller 102 is enabled to implement the data transfer method 400. In one aspect, a computer program product is provided, comprising a non-transitory computer-readable medium storing computer instructions executable by the data transfer controller 102 to perform the data transfer method 400. Examples of implementations of the non-transitory computer-readable medium include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), read-only memory (ROM), hard disk drive (HDD), flash memory, secure digital (SD) cards, solid-state drives (SSDs), computer-readable storage media, and / or CPU cache memory. The computer-readable medium used to provide non-transitory storage may include, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof.

[0149] Therefore, data transmission method 400 utilizes a subset of the QUIC protocol's functionality in a manner capable of hardware offloading the QUIC protocol. This invention provides an efficient hardware implementation of the modified QUIC protocol. Data transmission method 400 can also significantly improve the performance of servers and hosts running the modified QUIC protocol and provides a general application programming interface 208 to run various applications on the hardware offload implementation. Therefore, this data transmission method 400, which implements a hardware offload variant of the QUIC protocol (also known as OQUIC), may be standardized within the Internet Engineering Task Force (IETF), potentially further influencing and enhancing the way the Internet is designed, used, and managed.

[0150] Figure 5A This is a diagram of the X-over-QUIC offload variant (OQUIC) application interface provided in an embodiment of the present invention. Figure 5A Combination Figure 1A , Figure 1B and Figure 2 The components of A are shown. Regarding... Figure 5AThe diagram 500A illustrates an X-over-QUIC Offload Variant (OQUIC) application interface 502, which serves as a general application interface. The X-over-QUIC Offload Variant application interface 502 includes an Ethernet layer 504, an Internet Protocol (IP) layer 506, a User Datagram Protocol (UDP) layer 508, a QUIC Offload Variant layer 510, and an X layer 512.

[0151] Ethernet layer 504 provides a communication interface for initiating communication sessions with communication devices. Internet Protocol layer 506 and User Datagram Protocol layer 508 are communication protocols. Internet Protocol layer 506 is used to encapsulate data and transmit it from one point to another, while User Datagram Protocol layer 508 is used to establish low-latency and loss-tolerant connections between applications on the Internet. Internet Protocol layer 506 can also be called the Transmission Control Protocol.

[0152] QUIC Offload Variant Layer 510 is a subset of the QUIC protocol, making it hardware-friendly. QUIC Offload Variant Layer 510 defines possible extensions to the traditional QUIC protocol, making it more versatile in hardware implementations. X Layer 512 corresponds to applications (e.g., web applications).

[0153] X-over-QUIC offload variant application interface 502 corresponds to the generic socket class application interface, which enables applications to run on the modified QUIC protocol as an alternative to the transport control protocol. Therefore, X-over-QUIC offload variant application interface 502 offloads expensive functionality (i.e., resource consumption) to hardware (e.g., the host running the modified QUIC protocol).

[0154] Figure 5B This is a diagram of the X-over-QUIC (OQUIC) application interface provided in another embodiment of the present invention. Figure 5B Combination Figure 1A , Figure 1B , Figure 2 A and Figure 5A The components are shown. Regarding... Figure 5BThe diagram 500B illustrates an X-over-QUIC Offload Variant (OQUIC) application interface 502, which serves as a generic application interface. The X-over-QUIC Offload Variant application interface 502 includes a Stream-Aware Socket Application Interface (API) 514, a Stream-Insensitive Socket Application Interface (API) 516, an InfiniBand (IB) Remote Direct Memory Access (RDMA) 518, an application 520, a Remote Direct Memory Access via QUIC Resilient Transport (RoQET) 522, an Ethernet layer 504, an Internet Protocol (IP) layer 506, a User Datagram Protocol (UDP) layer 508, an OQUIC Offload Variant layer 510, and an X layer 512.

[0155] Stream-aware socket application programming interface 514 is aware of QUIC streams and supports applications (e.g., application 520) defining multiple QUIC streams. However, stream-insensitive socket application programming interface 516 is not aware of QUIC streams and does not support applications (e.g., application 520) defining multiple QUIC streams. Stream-insensitive socket application programming interface 516 also has a layer for converting from TCP / UDP socket APIs to OQUIC.

[0156] InfiniBand Remote Direct Memory Access 518 corresponds to an implementation of Remote Direct Memory Access (RDMA) technology using an InfiniBand network. Remote Direct Memory Access via QUIC Resilient Transport (RoQET) 522 is an alternative to Remote Direct Memory Access (RDMA) over-converged-ethernet (RoCE), offering reliability and low latency, and can be deployed over a wide area network (WAN).

[0157] X-over-QUIC offload variant application interface 502 provides hardware offloading of the QUIC protocol for Remote Direct Memory Access (RoQET) 522 via QUIC Elastic Transport. Another potential use case for X-over-QUIC offload variant application interface 502 is non-volatile memory-express (NVMe)-over-QUIC, which can be an alternative to non-volatile memory-express (NVMe)-over-faric, as well as NVMe-over-TCP, which is affected by the TCP issues addressed by QUIC.

[0158] In one implementation, the X-over-QUIC offload variant application interface 502 can be designed in a general manner to support various application types running on the X-over-QUIC offload variant application interface 502. Examples of application types include, but are not limited to, remote direct memory access (or InfiniBand remote direct memory access 518), and various other applications based on stream-aware socket application interface 514 and stream-insensitive socket application interface 516. Since QUIC streams are a concept not present in the transport control protocol, legacy applications are expected to require transparent operation on the X-over-QUIC offload variant application interface 502 in a stream-insensitive manner, for example, transparent operation in the stream-insensitive socket application interface 516. However, newer applications may benefit from using multiple streams per connection. Therefore, the present invention provides a general application interface, such as the X-over-QUIC offload variant application interface 502, for running various applications on a hardware offload implementation.

[0159] Modifications to the embodiments of the invention described above may be made without departing from the scope of the invention as defined in the appended claims. Expressions such as “comprising,” “integrating,” “having,” “is / are,” etc., used to describe and claim the invention are intended to be interpreted in a non-exclusive manner, allowing for the presence of items, components, or elements not explicitly described. Singular references should also be interpreted as relating to the plural. The word “exemplary” as used herein means “as an example, instance, or illustration.” Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments, or does not exclude features in combination with other embodiments. The word “optionally” as used herein means “provided in some embodiments and not in others.” It should be understood that certain features of the invention described in the context of a single embodiment for clarity may also be provided in combination in a single embodiment. Conversely, various features of the invention described in the context of a single embodiment for brevity may also be provided individually or in any suitable combination or as embodiments of any other described aspect of the invention.

Claims

1. A data transmission controller (102), characterized in that, The data transmission controller (102) is used for: One or more data transmission packets (104A to 104N) are generated according to the modified QUIC protocol in the following manner: One or more fields (108A to 108N) with a fixed field size are generated in the one or more data transmission messages (104A to 104N). In the one or more data transmission messages (104A to 104N), a predefined number of frames of different frame types are generated in a predefined frame type order.

2. The data transmission controller (102) according to claim 1, characterized in that, The data transmission controller (102) is also configured to limit the number of frames in each data transmission message (104A to 104N) to the maximum number of frames defined for each data transmission message.

3. The data transmission controller (102) according to claim 2, characterized in that, The data transmission controller (102) is also configured to set the number of frames of each data transmission message to the maximum number of frames defined for each data transmission message.

4. The data transmission controller (102) according to any one of the preceding claims, characterized in that, The data transmission controller (102) is also used to set all fields of a field type to a fixed field type size.

5. The data transmission controller (102) according to any one of the preceding claims, characterized in that, The data transmission controller (102) is also configured to include a version number in the one or more data transmission messages (104A to 104N), the version number indicating the protocol version to be used.

6. The data transmission controller (102) according to any one of the preceding claims, characterized in that, The data transmission controller (102) is also configured to include a mode in the one or more data transmission messages (104A to 104N) indicating whether the data transmission messages (104A to 104N) are to be encrypted.

7. The data transmission controller (102) according to any one of the preceding claims, characterized in that, It also includes a communication interface (110), wherein the data transmission controller (102) is further configured to initiate a communication session with the communication device (112) through the communication interface (110) and define communication parameters during the initiation of the communication session, wherein the communication parameters include field size and frame type order, and wherein the predefined number of frames is a limited number of frames negotiated based on the communication parameters when establishing a connection with the communication device (112).

8. The data transmission controller (102) according to claim 7, characterized in that, The communication parameters also include the maximum number of frames per data transmission message.

9. The data transmission controller (102) according to claim 7 or 8, characterized in that, The field size includes the size of one or more field types.

10. The data transmission controller (102) according to any one of claims 7 to 9, characterized in that, At least one of the field type sizes is zero.

11. The data transmission controller (102) according to any one of claims 7 to 10, characterized in that, The communication parameters also include the resolution depth.

12. The data transmission controller (102) according to any one of claims 7 to 11, characterized in that, The data transmission controller (102) is also configured to negotiate one or more of the communication parameters with the communication device during the initialization of the communication session.

13. The data transmission controller (102) according to any one of the preceding claims, characterized in that, The data transmission controller (102) is also used to execute an application-program interface (API) (208) with two modes: a stream-aware mode (212) and a stream-insensitive mode (214).

14. The data transmission controller (102) according to claim 13, characterized in that, The flow-aware (212) mode is based on one or more generated data transmission packets (104A to 104N).

15. The data transmission controller (102) according to claim 13 or 14, characterized in that, The application-program interface (API) (208) is configured to enable applications designed for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) to run on the modified QUIC protocol.

16. The data transmission controller (102) according to claim 15, characterized in that, The stream-aware mode (214) is the Transmission Control Protocol (TCP) socket application-program interface (API).

17. The data transmission controller (102) according to claim 15, characterized in that, The stream-aware mode (214) is the User Datagram Protocol (UDP) socket application-program interface (API).

18. The data transmission controller (102) according to any one of the preceding claims, characterized in that, The data transmission controller (102) is used to process at least some of the generated data in hardware.

19. The data transmission controller (102) according to any one of the preceding claims, characterized in that, The data transmission controller (102) is used to receive data transmission messages and parse the received data transmission messages in hardware.

20. The data transmission controller (102) according to any one of the preceding claims, characterized in that, The data transmission controller (102) is hardware-based.

21. A data transmission method (300) for generating one or more data transmission messages (104A to 104N), characterized in that, include: The one or more data transmission packets (104A to 104N) are generated according to the modified QUIC protocol in the following manner: Generate one or more fields with a fixed field size in the one or more data transmission messages (104A to 104N). In the one or more data transmission messages (104A to 104N), a predefined number of frames of different frame types are generated in a predefined frame type order.

22. A computer-readable medium, characterized in that, When computer instructions are loaded into the control circuit (114) of the data transmission controller (102) and executed by the control circuit (114), the data transmission controller (102) is enabled to implement the data transmission method (300) according to claim 21.

Images