Network congestion control method and device based on token

Abstract

The invention provides a network congestion control method and device based on a token, relates to the technical field of communication, and can improve the control effect on network congestion. The method comprises the following steps: when a sending node sends a message to an intermediate node, a message header comprises an identification bit for identifying whether a token value is allowed to be modified or not and a numerical field for identifying the token value; when the intermediate node forwards the message, if the identification bit indicates that the token value is allowed to be modified, an expected speed increasing and decreasing ratio and a recommended token value are calculated according to the resource use condition of the intermediate node, a numerical value field in a message header is modified according to the recommended token value, and meanwhile resource reservation is conducted according to the numerical value field; the receiving node aggregates the token value according to the numerical fields of the plurality of messages, generates a feedback message, and sends the feedback message to the sending node; and the sending node limits the data volume sent to the receiving node or adjusts the sending rate according to the numerical field in the feedback message.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a token-based network congestion control method and apparatus. Background Art

[0002] In order to enable the network to achieve lossless and packet-free transmission performance, congestion control technologies are used to finely control the traffic, thereby providing a lossless transmission channel.

[0003] Currently, there are many solutions for congestion control technologies. For example, general data center quantized congestion notification (DCQCN), high precision congestion control (HPCC), Timely, and Tita protocols. However, HPCC, Timely, and Tita are private solutions and are not publicly available, and the control effect of using DCQCN for network congestion is poor. Summary of the Invention

[0004] This application provides a token-based network congestion control method and apparatus, which can improve the control effect of network congestion.

[0005] To achieve the above object, this application adopts the following technical solutions:

[0006] In a first aspect, this application provides a token-based network congestion control method, which is applied to a sending node. The method includes: sending a first message to an intermediate node, where the first message includes a plurality of identification bits, and the plurality of identification bits include a first identification bit, a second identification bit, and a numerical value field including a plurality of numerical bits; wherein, the first identification bit is used to indicate whether to allow modifying the numerical value of the numerical value field, the second identification bit is used to indicate whether to reserve transmission resources according to the numerical value of the numerical value field, and the numerical value field is used to determine the data volume or rate; receiving a first feedback message from a receiving node, and restricting the data volume of sending data to the receiving node or adjusting the rate of sending data to the receiving node according to the plurality of identification bits in the first feedback message.

[0007] In a possible implementation manner, restricting the data volume of sending data to the receiving node or adjusting the rate of sending data to the receiving node according to the plurality of identification bits in the first feedback message includes: determining a corresponding token value according to the numerical value of the numerical value field in the first feedback message; restricting the data volume of sending data to the receiving node according to the token value; or determining a rate change amount based on an interval duration according to the token value, and adjusting the rate of sending data to the receiving node according to the rate change amount.

[0008] Second aspect, the present application provides a token-based network congestion control method, which is applied to an intermediate node. The method includes: receiving a first message from a sending node, the first message including multiple identification bits, the multiple identification bits including a first identification bit, a second identification bit, and a numerical field including multiple numerical bits; wherein, the first identification bit is used to indicate whether to allow modifying the numerical value of the numerical field, the second identification bit is used to indicate whether to reserve transmission resources according to the numerical value of the numerical field, and the numerical field is used to determine the data volume or rate; when the first identification bit in the first message is a first value, determining its own resource usage situation, determining a recommended token value according to the resource usage situation, and modifying the numerical value of the numerical field in the first message according to the recommended token value; when the first identification bit in the first message is a second value, not modifying the numerical value of the numerical field in the first message; when the second identification bit in the first message is a first value, reserving transmission resources according to the numerical value of the numerical field in the first message; sending the first message to a receiving node.

[0009] In a possible implementation manner, determining its own resource usage situation includes: obtaining the number of bytes passed, the number of allocated tokens, and a transmission volume threshold within a preset statistical period, the transmission volume threshold representing the upper limit of the data volume that can be tolerated within the preset statistical period and obtained according to the physical bandwidth and the preset statistical period; obtaining an up / down speed adjustment space according to the difference between the transmission volume threshold and the number of allocated tokens; obtaining an up / down speed ratio according to the ratio between the up / down speed adjustment space and the number of bytes passed.

[0010] In a possible implementation manner, the method further includes: determining an upper limit of the recommended token value, the upper limit of the recommended token value being the product of the transmission volume threshold and a preset coefficient, the preset coefficient being greater than or equal to 1.

[0011] In a possible implementation manner, determining a recommended token value according to the resource usage situation and modifying the numerical value of the numerical field in the first message according to the recommended token value includes: determining the recommended token value according to the up / down speed ratio and the message length of the first message; if the number of allocated tokens exceeds the upper limit of the recommended token value, adjusting the recommended token value to 0; when the recommended token value is less than the current value of the numerical field in the first message, modifying the numerical field in the first message to the recommended token value; when the recommended token value is greater than or equal to the current value of the numerical field in the first message, not modifying the numerical field in the first message.

[0012] In a third aspect, the present application provides a token-based network congestion control method, which is applied to a receiving node. The method includes: receiving a first message from an intermediate node, where the first message includes a plurality of identification bits, and the plurality of identification bits include a first identification bit, a second identification bit, and a numerical field including a plurality of numerical bits; wherein, the first identification bit is used to indicate whether to allow modifying the numerical value of the numerical field, the second identification bit is used to indicate whether to reserve transmission resources according to the numerical value of the numerical field, and the numerical field is used to determine the data volume or rate; determining a first feedback message according to at least one first message; and sending the first feedback message to a sending node.

[0013] In a possible implementation manner, determining the first feedback message according to at least one first message includes: aggregating the numerical values of the numerical fields in at least one first message, and filling the aggregated numerical value of the numerical field into the first feedback message; filling the first identification bit in the first feedback message with a second numerical value, and filling the second identification bit in the first feedback message with a second numerical value, to obtain the first feedback message.

[0014] In a possible implementation manner, the first message further includes a third identification bit or a fourth identification bit. The third identification bit is used to indicate whether to allow per-pack equal-cost multi-path load balancing, and the fourth identification bit is used to indicate the transmission distance of the message, and the transmission distance includes long distance and short distance.

[0015] In a fourth aspect, the present application provides a token-based network congestion control device, which includes: a processor and a communication interface; the communication interface is coupled to the processor, and the processor is configured to run a computer program or instruction to implement the token-based network congestion control method described in the first aspect, any possible implementation manner of the first aspect, the second aspect, any possible implementation manner of the second aspect, the third aspect, and any possible implementation manner of the third aspect.

[0016] The above technical solutions at least bring the following beneficial effects: The sending node sends a first message to the intermediate node. The intermediate node can actively modify the numerical field in the first message according to its own resource usage situation and perform resource reservation. The receiving node generates a first feedback message according to the numerical field modified by the intermediate node and sends the first feedback message to the sending node. That is to say, in the token-based network congestion control method provided by the embodiments of the present application, when the sending node adjusts the sending rate, it limits the sending amount according to the numerical field actively given by the intermediate node, so that the intermediate node can perform resource reservation more actively and accurately during the communication process, thereby improving the control effect on network congestion. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a flowchart of a token-based network congestion control method provided by an embodiment of the present application;

[0018] Figure 2 Schematic diagram of a token - based network congestion control method provided by an embodiment of this application;

[0019] Figure 3 Schematic diagram of a parameter related to the speed - up ratio provided by an embodiment of this application;

[0020] Figure 4 Schematic diagram of a parameter related to the speed - down ratio provided by an embodiment of this application;

[0021] Figure 5 Schematic diagram of a receiving node sending a first feedback message provided by an embodiment of this application;

[0022] Figure 6 Schematic diagram of calculating the rate change amount provided by an embodiment of this application;

[0023] Figure 7 Schematic diagram of a token - based network congestion control method provided by an embodiment of this application;

[0024] Figure 8 Schematic diagram of another token - based network congestion control method provided by an embodiment of this application;

[0025] Figure 9 Schematic diagram of another token - based network congestion control method provided by an embodiment of this application;

[0026] Figure 10 Schematic diagram of another token - based network congestion control method provided by an embodiment of this application;

[0027] Figure 11 Schematic diagram of another network topology structure provided by an embodiment of this application;

[0028] Figure 12 Schematic diagram of the rate in the initial stage provided by an embodiment of this application;

[0029] Figure 13 Schematic diagram of the rate in the first speed - up stage provided by an embodiment of this application;

[0030] Figure 14 Schematic diagram of the rate in the second speed - up stage provided by an embodiment of this application;

[0031] Figure 15 Schematic diagram of another network topology structure provided by an embodiment of this application;

[0032] Figure 16 Schematic diagram of another network topology structure provided by an embodiment of this application;

[0033] Figure 17 It is a schematic diagram of another network topology structure provided by an embodiment of the present application;

[0034] Figure 18 It is a schematic diagram of another network topology structure provided by an embodiment of the present application;

[0035] Figure 19 It is a schematic diagram of another network topology structure provided by an embodiment of the present application;

[0036] Figure 20 It is a schematic diagram of a sending node adjusting the deceleration step length provided by an embodiment of the present application;

[0037] Figure 21 It is a schematic diagram of the encapsulation positions of multiple identification bits provided by an embodiment of the present application. Detailed implementation manners

[0038] The token-based network congestion control method and device provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0039] The term "and / or" in this document is merely a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone.

[0040] The terms "first" and "second" in the specification and drawings of the present application are used to distinguish different objects or different processes for the same object, rather than to describe the specific order of the objects.

[0041] In addition, the terms "including" and "having" and any variations thereof mentioned in the description of the present application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally further include other unlisted steps or units, or may optionally further include other steps or units inherent to these processes, methods, products or devices.

[0042] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner.

[0043] In the description of the present application, unless otherwise specified, the meaning of "a plurality of" refers to two or more.

[0044] In addition, actions, terms, etc. involved among the embodiments of this application can be referenced to each other without limitation. The message names or parameter names in the messages exchanged between devices in the embodiments of this application are just examples, and other names can also be used in specific implementations without limitation.

[0045] Currently, intelligent computing / supercomputing are both hot issues in the big data era. In intelligent computing centers / supercomputing centers, issues related to large-scale graphics processing unit (GPU) cluster networking and high-performance storage cluster networking are involved. The use of remote direct memory access (RDMA) technology is currently the most mainstream solution, and the network communication technologies used to support RDMA mainly include infiniband (IB) technology and remote direct memory access over converged ethernet version 2 (RoCEv2) technology.

[0046] RDMA technology has very high requirements for network performance quality. If packet loss occurs in the network, it will have a huge impact on RDMA transmission performance. Therefore, currently, in order to support upper-layer RDMA applications, near-lossless performance requirements are put forward for the network. The current common IB technology can ensure lossless packet-free, and the common RoCEv2 technology also provides a lossless guarantee effect close to that of IB technology through some technical means.

[0047] In order to provide near-lossless packet-free transmission performance, the network will use congestion control technology. Through key technologies such as headroom buffer, priority-based flow control (PFC), and explicit congestion notification (ECN), the traffic is finely controlled to provide a lossless transmission channel.

[0048] Currently, there are many solutions for congestion control technology. For example, the general DCQCN, HPCC, Timely, and Tita protocols. However, HPCC, Timely, and Tita are private solutions and not publicly available, and the control effect of using DCQCN for network congestion is poor.

[0049] In view of this, an embodiment of the present application provides a token-based network congestion control method. A sending node sends a first message to an intermediate node, and the intermediate node can actively modify the numerical field in the first message according to its own resource usage situation and perform resource reservation. The receiving node generates a first feedback message based on the numerical field modified by the intermediate node and sends the first feedback message to the sending node. That is to say, in the token-based network congestion control method provided by the embodiment of the present application, when the sending node adjusts the sending rate, it limits the sending amount according to the numerical field actively given by the intermediate node, so that the intermediate node can perform resource reservation more actively and accurately during the communication process, and thus can improve the control effect on network congestion.

[0050] The following describes the token-based network congestion control method provided by the embodiment of the present application with reference to the accompanying drawings. Among them, actions, terms, etc. involved between various embodiments of the present application can be referred to each other without limitation. The message names or parameter names in the messages exchanged between various devices in the embodiments of the present application are only examples, and other names can also be used in specific implementations without limitation. The actions involved in the embodiments of the present application are only examples, and other names can also be used in specific implementations. For example, "included in" in the embodiment of the present application can also be replaced by "carried on" or "carried in", etc.

[0051] As Figure 1 shown, an embodiment of the present application proposes a token-based network congestion control method, which includes:

[0052] S101. The sending node sends a first message to the intermediate node. Correspondingly, the intermediate node receives the first message from the sending node.

[0053] Among them, the first message includes multiple identification bits, and the multiple identification bits include a first identification bit, a second identification bit, and a numerical field including multiple numerical bits. The first identification bit is used to indicate whether to allow modification of the numerical value in the numerical field. The second identification bit is used to indicate whether to reserve transmission resources according to the numerical value in the numerical field. The numerical field is used to determine the data volume or rate.

[0054] In a possible implementation manner, the forward message allows the intermediate node to modify the numerical value in the numerical field and reserve transmission resources according to the numerical value in the numerical field. For example, the sending node fills the first identification bit of the first message with 1 (that is, allowing modification of the numerical value in the numerical field), fills the second identification bit with 1 (that is, reserving transmission resources according to the numerical value in the numerical field), sets the numerical field to be empty, and sends the first message to the intermediate node. Correspondingly, the intermediate node receives the first message from the sending node.

[0055] Exemplarily, the above-mentioned sending node may be a server. For example, it can be a network interface card (NIC) on the terminal side, a super NIC, a RoCE NIC, or a data processing unit (DPU) chip on the NIC. The above-mentioned intermediate node may be a switch or a router.

[0056] Optionally, the number of bits included in the above-mentioned numerical field may be 8 bits, that is, 8 bit.

[0057] It should be noted that the above-mentioned multiple identification bits are encapsulated at the 2nd layer and are encapsulated in the header of the first message. They can be located after the VLAN header. If there is no VLAN header, they are located after the MAC header. When the first identification bit is 1, it means that the value of the numerical field is allowed to be modified. When the first identification bit is 0, it means that the value of the numerical field is not allowed to be modified. When the second identification bit is 1, it means that transmission resources are reserved according to the value of the numerical field. When the second identification bit is 0, there is no restriction on reserving transmission resources.

[0058] S102. When the first identification bit in the first message is the first value, the intermediate node determines its own resource usage situation, determines a recommended token value according to the resource usage situation, and modifies the value of the numerical field in the first message according to the recommended token value; when the first identification bit in the first message is the second value, the intermediate node does not modify the value of the numerical field in the first message; when the second identification bit in the first message is the first value, the intermediate node reserves transmission resources according to the value of the numerical field in the first message.

[0059] In a possible implementation manner, the intermediate node identifies the first identification bit and the second identification bit in the first message, processes the first message according to the identification result, and sends the processed first message to the receiving node. Correspondingly, the receiving node receives the processed first message from the intermediate node. Specifically, reference can be made to the Figure 2 described embodiments, which will not be elaborated here.

[0060] Exemplarily, the specific process of the above-mentioned intermediate node processing the first message according to the identification result is divided into the following four situations.

[0061] 1-1 The first identification bit in the first message is the first value

[0062] When the intermediate node identifies that the first identification bit in the first message is the first value (i.e., 1), the intermediate node determines its own resource usage situation, determines a recommended token value according to the resource usage situation, and allows the value of the numerical field in the first message to be modified according to the recommended token value.

[0063] 1-2 The first identification bit in the first message is the second value

[0064] When the intermediate node recognizes that the first identification bit in the first message is the second value (i.e., 0), the intermediate node is not allowed to modify the value in the value field of the first message.

[0065] 1-3 The second identification bit in the first message is the first value

[0066] When the intermediate node recognizes that the second identification bit in the first message is the first value (i.e., 1), the intermediate node reserves transmission resources according to the value in the value field of the first message.

[0067] 1-4 The second identification bit in the first message is the second value

[0068] When the intermediate node recognizes that the second identification bit in the first message is the second value (i.e., 0), the intermediate node can reserve transmission resources according to the message length of the first message or not impose any restrictions.

[0069] S103. The intermediate node sends the first message to the receiving node. Correspondingly, the receiving node receives the first message from the intermediate node.

[0070] S104. The receiving node determines the first feedback message according to at least one first message.

[0071] In a possible implementation, the receiving node aggregates the values in the value fields of at least one first message and fills the aggregated value in the value field into the first feedback message. The receiving node fills the first identification bit in the first feedback message with the second value (i.e., 0) and fills the second identification bit in the first feedback message with the second value (i.e., 0) to obtain the first feedback message.

[0072] S105. The receiving node sends the first feedback message to the sending node. Correspondingly, the sending node receives the first feedback message from the receiving node.

[0073] S106. The sending node restricts the data volume sent to the receiving node or adjusts the data rate sent to the receiving node according to multiple identification bits in the first feedback message.

[0074] In a possible implementation, the sending node determines the corresponding token value according to the value in the value field of the first feedback message and restricts the data volume sent to the receiving node according to the token value.

[0075] In another possible implementation, the sending node determines the corresponding token value according to the value in the value field of the first feedback message. The sending node determines the rate change amount according to the token value and the interval duration and adjusts the data rate sent to the receiving node according to the rate change amount.

[0076] In the token-based network congestion control method provided by this application, the sending node sends a first message to the intermediate node. The intermediate node can actively modify the numerical field in the first message according to its own resource usage and make resource reservation. The receiving node generates a first feedback message based on the numerical field modified by the intermediate node and sends the first feedback message to the sending node. That is to say, in the token-based network congestion control method provided by the embodiments of this application, when the sending node adjusts the sending rate, it limits the sending amount according to the numerical field actively given by the intermediate node, so that the intermediate node can make more active and accurate resource reservation during the communication process, and further improve the control effect on network congestion.

[0077] In one embodiment, as Figure 2 shown, the above S101 to S106 can be specifically determined by the following S201 to S211.

[0078] S201. The sending node sends a first message to Switch 1. Correspondingly, Switch 1 receives the first message from the intermediate node.

[0079] Among them, the first identification bit in the first message is 1, the second identification bit in the first message is 1, and the numerical field in the first message is empty.

[0080] S202. Switch 1 recognizes that the first identification bit in this first message is 1 and calculates the recommended up / down speed ratio.

[0081] As an example, taking Switch 1 calculating the up-speed ratio as an example, it may include the following steps.

[0082] S2021. Switch 1 obtains the number of bytes passed and the number of tokens allocated in this period according to the increments of the byte counter passed and the token counter allocated within the preset statistical period, and calculates the transmission volume threshold in this period according to the physical bandwidth of the port.

[0083] Among them, the transmission volume threshold represents the upper limit of the data volume that can be tolerated within the preset statistical period.

[0084] For example, the preset statistical period is 10 us, the port of Switch 1 is a 100 Gbps physical port, the number of bytes passed at time t0 is 1,000,000, and the number of tokens allocated is 1,200,000. Switch 1 triggers the calculation of the up / down speed ratio at time t1 = t0 + 10 us, and the number of bytes passed at time t1 is 1,075,000, and the number of tokens allocated is 1,300,000. The preset coefficient of Switch 1 is 1.2.

[0085] The number of bytes passed in this period is: 1,075,000 - 1,000,000 = 75,000 B.

[0086] The number of allocated tokens in this period is: 1300000 - 1200000 = 100000B.

[0087] The transmission volume threshold in this period is: 100Gbps × 10us = 125000B.

[0088] The upper limit of the recommended token value for the next period is: 1300000 + 125000 × 1.2 = 1450000B.

[0089] S2022. Switch 1 calculates the transmission volume threshold minus the number of allocated tokens to obtain the speed-up space (i.e., greater than 0).

[0090] Specifically, the transmission volume threshold - the number of allocated tokens is: 125000 - 100000 = 25000B, that is, the speed-up space is 25000B.

[0091] Exemplarily, Figure 3 is a schematic diagram of the parameters related to the speed-up ratio provided by an embodiment of the present application. As Figure 3 shown, the byte count passed is 75000B, the number of allocated tokens is 100000B, the transmission volume threshold is 125000B, and the speed-up space is 25000B.

[0092] S2023. Switch 1 calculates the ratio between the speed-up space and the byte count passed to obtain the speed-up ratio.

[0093] Specifically, the speed-up ratio is: 25000 / 75000 = 33%.

[0094] In addition, an upper limit of the speed-up ratio can be set (for example, the upper limit of the speed-up ratio is 20%), and then the actual speed-up ratio of Switch 1 is min(33%, 20%) = 20%.

[0095] It can be understood that setting the upper limit of the speed-up ratio is to avoid sudden large-scale speed-up. The upper limit of the speed-up ratio is used to control the gradual speed-up and can affect the rate convergence time.

[0096] Another example, taking Switch 1 calculating the deceleration ratio as an example, it can include the following steps.

[0097] S2021. Switch 1 obtains the byte count passed and the number of allocated tokens in this period according to the increments of the byte counter passed and the allocated token counter within the preset statistical period, and calculates the transmission volume threshold in this period according to the physical bandwidth of the port.

[0098] For example, the preset statistical period is 10 us, the port of switch 1 is a 100 Gbps physical port, the number of bytes passed at time t0 is 1,000,000, and the number of tokens allocated is 1,200,000. Switch 1 triggers the calculation of the speed-up / speed-down ratio at time t1 = t0 + 10 us. The number of bytes passed at time t1 is 1,120,000, and the number of tokens allocated is 1,330,000.

[0099] The number of bytes passed in this period is: 1,120,000 - 1,000,000 = 120,000 B.

[0100] The number of tokens allocated in this period is: 1,330,000 - 1,200,000 = 130,000 B.

[0101] The transmission volume threshold in this period is: 100 Gbps × 10 us = 125,000 B.

[0102] It should be noted that since the calculation of the speed-up / speed-down ratio and the cancellation of the allocated bandwidth are not triggered by each packet, but are triggered periodically once, there will be a situation where the number of tokens allocated exceeds the transmission volume threshold.

[0103] S2022. Switch 1 calculates the transmission volume threshold minus the number of tokens allocated to obtain the speed-down space (i.e., less than 0).

[0104] Specifically, the transmission volume threshold - the number of tokens allocated is: 125,000 - 130,000 = -5000 B, that is, the speed-down space is -5000 B.

[0105] Exemplarily, Figure 4 is a schematic diagram of the parameters related to the speed-down ratio provided by an embodiment of the present application. As Figure 4 shown, the number of bytes passed is 120,000 B, the number of tokens allocated is 130,000 B, the transmission volume threshold is 125,000 B, and the speed-down space is -5000 B.

[0106] S2023. Switch 1 calculates the ratio between the speed-down space and the number of bytes passed to obtain the speed-down ratio.

[0107] Specifically, the speed-down ratio is: -5000 / 120000 = -4%.

[0108] S203. Switch 1 obtains the value of the corresponding numerical field according to the speed-up / speed-down ratio and the packet length of the first packet.

[0109] Taking the above speed-up ratio of 20% as an example, calculate the recommended token value as 1472×(1 + 20%) = 1766 B, and convert it into the value of the numerical field as 1766 / 64 (rounded down) = 27, and the actual corresponding token value is 27×64 = 1728 B.

[0110] Another example, taking the above deceleration ratio of -4% as an example, the recommended token value is calculated as 1472×(1 - 4%) = 1413B. Converted into the value of the numerical field, it is 1413 / 64 = 22, and the actual corresponding number of tokens is 22×64 = 1408B.

[0111] S204. Switch 1 modifies the value of the numerical field in the first packet according to the obtained value of the numerical field.

[0112] For example, after speed increase and decrease calculation, Switch 1 decides to increase the speed by 5%, and modifies the numerical field in this first packet to 23 + 23×5% = 24, corresponding to the number of tokens 24×64 = 1536B.

[0113] It should be noted that when Switch 1 receives this first packet, the numerical field in the first packet is empty. Therefore, the numerical field in the first packet is directly modified.

[0114] S205. Switch 1 recognizes that the second identification bit in this first packet is 1, reserves transmission resources according to the modified numerical field (that is, increases the allocated number of tokens), and sends the first packet to Switch 2. Correspondingly, Switch 2 receives the first packet from Switch 1.

[0115] Specifically, the numerical field is 24, and the corresponding number of tokens is 24×64 = 1536B. The allocated number of tokens is increased by 1536.

[0116] S206. Switch 2 recognizes that the first identification bit in this first packet is 1, calculates the recommended speed increase / decrease ratio, calculates the value of the numerical field to be pre-modified, and determines whether to make a modification.

[0117] Specifically, if the value of the numerical field to be pre-modified is greater than or equal to the current value, it means that the previous network device does not allow a greater speed increase value, and no modification is made. If the value of the numerical field to be pre-modified is less than the current value, a modification is made.

[0118] For example, after speed increase and decrease calculation, Switch 2 decides to increase the speed by 20%, and pre-modifies the value of the numerical field to 23 + 23×20% = 27. However, 27 is greater than the current value of 24, so Switch 2 does not modify the numerical field and still maintains the value of 24, still corresponding to the number of tokens 1536B.

[0119] In addition, if the allocated number of tokens exceeds the upper limit of the recommended token value, the value of the numerical field is modified to 0.

[0120] S207. Switch 2 recognizes that the second identification bit in this first packet is 1, and writes off resources according to the numerical field (24) (same as S105).

[0121] S208. After receiving two first messages, the receiving node sends one first feedback message to Switch 2. Correspondingly, Switch 2 receives the first feedback message from the receiving node.

[0122] S2081. The receiving node aggregates the numerical fields in the two forward messages.

[0123] For example, if the numerical fields in the two forward messages are both 24, the numerical field in the reverse message is obtained as 48.

[0124] S2082. The receiving end fills the first identification bit in the first feedback message with 0, fills the second identification bit in the first feedback message with 0, and sends the first feedback message to Switch 2.

[0125] Exemplarily, Figure 5 is a schematic diagram of a receiving node sending a first feedback message provided by an embodiment of the present application. As Figure 5 shown, after receiving two first messages, the receiving node passes the messages through the intermediate node and sends one first feedback message to the receiving node.

[0126] S209. Switch 2 identifies that the first identification bit in this first feedback message is 0 and does not modify the numerical field of this first feedback message. Switch 2 identifies that the second identification bit in this first feedback message is 0 and does not reserve transmission resources according to the numerical field.

[0127] Optionally, Switch 2 can cancel resources according to the actual size of this first feedback message.

[0128] For example, if the actual size of the first feedback message is 1472B, Switch 2 increases the number of allocated tokens by 1472.

[0129] S210. Switch 1 receives this first feedback message and performs the same processing as S209.

[0130] S211. The sending node receives this first feedback message and restricts the amount of data sent to the receiving node or adjusts the rate of data sent to the receiving node.

[0131] Taking the example of the sending node restricting the amount of data sent to the receiving node as an example, the implementation process of the above S211 is specifically as follows: Every time the sending node receives a new first feedback message and identifies that the value of the numerical field of the first feedback message is 48, the corresponding new confirmed token number is 3072B. The sending node can send two new first messages and have a remaining token of 128B. Furthermore, every time the sending node receives 12 first feedback messages, the remaining token number is 1536B, which is greater than the 1472B required to send one first message. That is, the sending node can send one more first message every time it receives 12 first feedback messages, forming a speed-up effect.

[0132] Another example, taking the sending node adjusting the data sending rate to the receiving node as an example, the implementation process of the above S211 may include the following steps.

[0133] S2111. The sending node calculates the corresponding number of tokens according to the numerical field of this first feedback message.

[0134] For example, the numerical field of the reverse message is 48, and the corresponding number of tokens is 48 × 64 = 3072B.

[0135] S2112. The sending end passes the number of tokens to the upper-layer transport protocol.

[0136] One example is that the upper-layer transport protocol is TCP, and the sending end passes the number of tokens into the TCP protocol stack.

[0137] Another example is that the upper-layer transport protocol is DCQCN, and the sending end passes the number of tokens into the DCQCN protocol stack.

[0138] S2113. The upper-layer transport protocol at the sending end adjusts the sending rate according to the number of tokens.

[0139] One example is that the TCP protocol stack at the sending end raises the congestion window (cwnd) to the value of the number of tokens.

[0140] Another example is that the DCQCN protocol stack at the sending end calculates the rate change amount ΔRt ((number of tokens - amount of confirmation) / interval duration) and changes the sending rate. Specifically, 1 reverse message confirms 2 forward messages, the amount of confirmation is 1472 × 2 = 2944B, ΔRt = (3072B - 2944B) / 2us = 0.512Gbps, and the sending rate is increased by 0.512Gbps.

[0141] Exemplarily, Figure 6 is a schematic diagram of calculating the rate change amount provided by an embodiment of the present application. As Figure 6 shown, the confirmed number of tokens is 3072B, and the confirmed data volume is 2944B. The rate change amount ΔRt is determined according to the difference between the confirmed number of tokens and the confirmed data volume and the interval duration.

[0142] In one embodiment, as Figure 7 shown, the sending node can implement forcibly maintaining the sending rate unchanged through the first identification bit and the second identification bit, which specifically includes the following steps.

[0143] It should be noted that the device cell is 64B, the message is sent in a size of 1472B, corresponding to 23 cells, and the sending node hopes to forcibly maintain the sending rate unchanged.

[0144] S301. The sending node sends the first message 1 to switch 1. Correspondingly, switch 1 receives the first message 1 from the intermediate node.

[0145] Among them, the first flag bit in the first message 1 is 0 (i.e., the value of the numerical field is not allowed to be modified), the second flag bit in the first message 1 is 1 (i.e., transmission resources are reserved according to the value of the numerical field), and the numerical field in the first message 1 is 23 (i.e., equal to the message size).

[0146] S302. Switch 1 recognizes that the first flag bit in this first message 1 is 0 and does not modify the numerical field of this first message 1. Switch 1 recognizes that the second flag bit in this first message 1 is 1 and reserves transmission resources according to the value 23 of the numerical field (i.e., increases the number of allocated tokens by 1472). Switch 1 sends the first message 1 to switch 2.

[0147] S303. Switch 2 receives this first message 1 and performs the same processing as S302.

[0148] S304. After receiving 2 first messages 1, the receiving node sends 1 first feedback message to switch 2.

[0149] S3041. The receiving node aggregates the numerical fields in 2 first messages 1, and the value of the numerical field in the first feedback message is obtained as 23 + 23 = 46.

[0150] S3042. The receiving node fills the first flag bit and the second flag bit in the first feedback message with 0.

[0151] S305. Switch 2 recognizes that the first flag bit in this first feedback message is 0 and does not modify the numerical field of this first feedback message. Switch 2 recognizes that the second flag bit in this first feedback message is 0 and does not reserve transmission resources according to the numerical field. Switch 2 sends this first feedback message to switch 1.

[0152] S306. Switch 1 receives this first feedback message, performs the same processing as S305, and sends this first feedback message to the sending node.

[0153] S307. The sending node receives this first feedback message, recognizes that the value of the numerical field of this first feedback message is 46, the corresponding new confirmed token number is 46 × 64 = 2944B, allows the sending of 2 first messages, and there are no remaining tokens.

[0154] It should be noted that since the actual size of 2 first messages is also 2944B, the sending node can send 2 first messages without remaining tokens, that is, the sending rate of the sending node remains unchanged.

[0155] In one embodiment, as Figure 8 shown, the sending node can reserve guaranteed transmission resources through the first identification bit and the second identification bit, which specifically includes the following steps.

[0156] It should be noted that the device cell is 64B, and the message is sent in a size of 1472B, corresponding to 23 cells. The sending node hopes to reserve guaranteed transmission resources.

[0157] S401. The sending node sends the first message 1.

[0158] Among them, the first identification bit in the first message 1 is 0 (that is, the value of the numerical field is not allowed to be modified), the second identification bit in the first message 1 is 1 (that is, transmission resources are reserved according to the value of the numerical field), and the numerical field in the first message 1 is 23 (that is, equal to the message size).

[0159] S402. The sending node sends the first message 2.

[0160] Among them, the first identification bit in the first message 2 is 1 (that is, the value of the numerical field is allowed to be modified), the second identification bit in the first message 2 is 1 (that is, transmission resources are reserved according to the value of the numerical field), and the numerical field in the first message 2 is empty.

[0161] S403. When the intermediate node processes the first message 1, the processing is the same as S302.

[0162] It should be noted that regardless of whether the network traffic is high or low, when the intermediate node processes the first message 1, the number of allocated tokens is increased by 1472, thereby forming the effect of reserving transmission resources.

[0163] S404. When the intermediate node processes the first message 2, the processing is the same as S202 to S205.

[0164] It should be noted that in the case of low network traffic, when the intermediate node processes the first message 2, the numerical field of the message is modified according to the speed-up ratio, and the number of allocated tokens is increased according to the modified numerical field, thereby forming the effect of speed increase. In the case of high network traffic, when the intermediate node processes the first message 2, the value of the numerical field of the message is modified to 0, thereby forming the effect of speed reduction.

[0165] S405. The sending node controls the ratio of sending the first message 1 and the first message 2.

[0166] It can be understood that by controlling the ratio of sending the first message and the second message, the sending end can form the effect of reserving guaranteed transmission resources.

[0167] In one embodiment, as Figure 9As shown, the sending node can achieve a stable increase in the sending rate through the first identification bit and the second identification bit, which specifically includes the following steps.

[0168] It should be noted that the device cell is 64B, and the message is sent in a size of 1472B, corresponding to 23 cells. The sending node hopes to achieve a stable increase in the sending rate (i.e., does not want to reduce the speed).

[0169] S501. The sending node sends the first message 3.

[0170] Among them, the first identification bit in the first message 3 is 0 (i.e., the value of the numerical field is not allowed to be modified), the second identification bit in the first message 3 is 1 (i.e., transmission resources are reserved according to the value of the numerical field), and the numerical field in the first message 3 is 46 (i.e., twice the size of the message).

[0171] S502. The sending node sends the first message 2.

[0172] Among them, the first identification bit in the first message 2 is 1 (i.e., the value of the numerical field is allowed to be modified), the second identification bit in the first message 2 is 1 (i.e., transmission resources are reserved according to the value of the numerical field), and the numerical field in the first message 2 is empty.

[0173] S503. When processing the first message 3, the intermediate node recognizes that the first identification bit of this message is 0 and does not modify the numerical field of this message. The intermediate node recognizes that the second identification bit of this message is 1 and reserves transmission resources according to the value 46 of the numerical field of this message (46 corresponds to 2944B of token numbers, that is, the allocated token numbers are increased by 2944).

[0174] It should be noted that regardless of the network traffic level, when processing the first message 3, the intermediate node will increase the allocated token numbers by 2944 (i.e., the size of 2 messages).

[0175] S504. When processing the first message 2, the intermediate node performs the same processing as in S202 to S205.

[0176] It should be noted that in the case of low network traffic, when processing the first message 2, the intermediate node modifies the numerical field of the message according to the speed increase ratio and increases the allocated token numbers according to the modified numerical field, thereby achieving the effect of speed increase. In the case of high network traffic, when processing the first message 2, the intermediate node cannot obtain tokens and cannot increase the speed.

[0177] S505. The sending node controls the first message 3 and the first message 2 to be sent in a ratio of 1:1.

[0178] It can be understood that by controlling the first message 3 and the first message 2 to be sent in a 1:1 ratio, the sending node can achieve the effect of only increasing speed and not decreasing speed.

[0179] In one embodiment, as Figure 10 shown, the sending node can limit the upper speed increase limit through the first identification bit and the second identification bit, which specifically includes the following steps.

[0180] It should be noted that the device cell is 64B, and the message is sent in a size of 1472B, corresponding to 23 cells. The sending node hopes to limit the upper speed increase limit (for example, limit the upper speed increase limit to 5%) to avoid the intermediate node reserving redundant transmission resources.

[0181] S601. The sending node sends the first message 4.

[0182] Among them, the first identification bit in the first message 4 is 1 (that is, allowing the value in the numerical field to be modified), the second identification bit in the first message 4 is 1 (that is, reserving transmission resources according to the value in the numerical field), and the numerical field in the first message 4 is 24 (that is, equivalent to a 5% speed increase, 23 + 23×5% = 24).

[0183] S602. When the switch 1 and the switch 2 process the first message 4, it is recognized that the first identification bit of this message is 1, and it is pre-planned to change the numerical field of this message to 23 + 23×20% = 27 (that is, the calculated speed increase ratio of the switch 1 and the switch 2 is 20%), but 27 > the current value 24, so the switch 1 and the switch 2 do not modify the numerical field of this message.

[0184] S603. When the switch 1 and the switch 2 process the first message 4, it is recognized that the second identification bit of this message is 1, and reserve transmission resources according to the value 24 in the numerical field (that is, increase the number of allocated tokens by 24×64 = 1536B).

[0185] S604. After receiving 2 first messages 4, the receiving node sends 1 first feedback message to the switch 2.

[0186] Among them, the first identification bit and the second identification bit of the first feedback message are 0, and the value of the numerical field is 24 + 24 = 48.

[0187] S605. The switch 2 receives this first feedback message, recognizes that the first identification bit of this first feedback message is 0, and does not modify the numerical field of this first feedback message. The switch 2 recognizes that the second identification bit in this first feedback message is 0, and does not reserve transmission resources according to the numerical field. The switch 2 sends this first feedback message to the switch 1.

[0188] S606. The switch 1 receives this first feedback message, processes it in the same way as S605, and sends this first feedback message to the sending node.

[0189] S607. The sending node receives this first feedback message, recognizes that the numerical field of this first feedback message is 48, the corresponding new confirmation token number is 48 × 64 = 3072B, allowing 2 first messages to be sent, and there is a balance of 128B of tokens (i.e., 3072 - 1472 × 2 = 128B).

[0190] It can be understood that since the sending node receives 12 first feedback messages each time, the balance of tokens is 1536B (12 × 128 = 1536B), which is greater than the 1472B required to send 1 first message. Therefore, the sending node can send 1 more first message every time it receives 12 first feedback messages, thereby achieving an acceleration effect of 5%.

[0191] In one embodiment, taking the following Figure 11 shown network topology as an example, the sending node can achieve multiple iterative rate convergence through the first identification bit and the second identification bit, specifically including the following steps.

[0192] It should be noted that as Figure 11 shown, the bandwidths of the sending node 1 and the sending node 2 connected to the switch 1 are both 100G, the bandwidths of the receiving node 1 and the receiving node 2 connected to the switch 2 are 100G and 25G respectively, and the interconnection between the switch 1 and the switch 2 is 100G. There are 2 traffic flows in this network topology. Flow 1 is from the sending node 1 to the receiving node 1, and flow 2 is from the sending node 2 to the receiving node 2.

[0193] Initial stage: As Figure 12 shown, the rates of both flow 1 and flow 2 are 10Gbps.

[0194] S701. The output interface of the switch 1 calculates the speed-up ratio as 500% based on the physical bandwidth of 100G and the actual traffic of 20G. When the switch 1 processes the first messages of flow 1 and flow 2, it modifies the numerical field of the messages according to 500% of the message size.

[0195] S702. The output interface 1 of the switch 2 calculates the speed-up ratio as 1000% based on the physical bandwidth of 100G and the actual traffic of 10G. When the switch 2 processes the first messages of flow 1, it pre-modifies the numerical field of the messages according to 1000% of the message size, but since the pre-modified value is greater than 500% of the current value of the message size, no modification is made.

[0196] S703. The outgoing interface 2 of switch 2 calculates an acceleration ratio of 250% based on the physical bandwidth of 25G and the actual traffic of 10G. When switch 2 processes the first packet flowing to 2, it pre-modifies the numerical field of the packet according to 250% of the packet size, and the pre-modified value is less than 500% of the current packet size, then modifies the numerical field of the packet according to 250% of the packet size.

[0197] S704. When receiving node 1 receives the first packet flowing to 1, it replies to sending node 1 with the first feedback packet according to the number of tokens = 500% of the packet size.

[0198] S705. When receiving node 2 receives the first packet flowing to 2, it replies to sending node 2 with the first feedback packet according to the number of tokens = 250% of the packet size.

[0199] Acceleration stage 1: As Figure 13 shown, the sending node accelerates the flow to 1 to 500% which is 50Gbps and the flow to 2 to 250% which is 25Gbps according to the number of tokens feedback by the receiving node in the previous stage.

[0200] S706. The outgoing interface of switch 1 calculates an acceleration ratio of 133% based on the physical bandwidth of 100G and the actual traffic of 75G. When switch 1 processes the first packets flowing to 1 and flowing to 2, it modifies the numerical fields of the packets according to 133% of the packet size.

[0201] S707. The outgoing interface 1 of switch 2 calculates an acceleration ratio of 200% based on the physical bandwidth of 100G and the actual traffic of 50G. When switch 2 processes the first packet flowing to 1, it pre-modifies the numerical field of the packet according to 200% of the packet size, but since the pre-modified value is greater than 133% of the current packet size, no modification is made.

[0202] S708. The outgoing interface 2 of switch 2 calculates that the rate remains unchanged based on the physical bandwidth of 25G and the actual traffic of 25G. When switch 2 processes the first packet flowing to 2, it pre-modifies the numerical field of the packet according to 100% of the packet size, and the pre-modified value is less than 133% of the current packet size, then modifies the numerical field of the packet according to 100% of the packet size.

[0203] S709. When the receiving node receives the first packet flowing to 1, it replies to sending node 1 with the first feedback packet according to the number of tokens = 133% of the packet size.

[0204] S710. When the receiving node receives the first packet flowing to 2, it replies to sending node 2 with the first feedback packet according to the number of tokens = 100% of the packet size.

[0205] Acceleration stage 2: As Figure 14As shown, the sending node speeds up Flow 1 to 133% (i.e., 67 Gbps) based on the number of tokens feedback by the receiving node in the previous stage, and keeps the rate of Flow 2 at 25 Gbps.

[0206] S711. The outgoing interface of Switch 1 calculates an up - speed ratio of 108% based on the physical bandwidth of 100 G and the actual traffic of 92 G. When Switch 1 processes the first packets of Flow 1 and Flow 2, it modifies the numerical fields of the packets according to 108% of the packet size.

[0207] S712. The outgoing interface 1 of Switch 2 calculates an up - speed ratio of 149% based on the physical bandwidth of 100 G and the actual traffic of 67 G. When Switch 2 processes the first packet of Flow 1, it pre - modifies the numerical field of the packet according to 149% of the packet size. However, since the pre - modified value is greater than 108% of the current packet size, no modification is made.

[0208] S713. The outgoing interface 2 of Switch 2 calculates that the rate remains unchanged based on the physical bandwidth of 25 G and the actual traffic of 25 G. When Switch 2 processes the first packet of Flow 2, it pre - modifies the numerical field of the packet according to 100% of the packet size. Since the pre - modified value is less than 108% of the current packet size, the numerical field of the packet is modified according to 100% of the packet size.

[0209] S714. When the receiving node receives the first packet of Flow 1, it replies to the sending node 1 with the first feedback packet according to the number of tokens = 108% of the packet size.

[0210] S715. When the receiving node receives the first packet of Flow 2, it replies to the sending node 2 with the first feedback packet according to the number of tokens = 100% of the packet size.

[0211] Subsequent speed - up stage: The subsequent sending node gradually speeds up Flow 1 to 75 Gbps based on the number of tokens feedback by the receiving node in the previous stage, and keeps the rate of Flow 2 at 25 Gbps continuously.

[0212] In one embodiment, taking the following Figure 15 shown network topology structure as an example, per - packet load balancing can be achieved through the third identification bit.

[0213] It should be noted that, as Figure 15 shown, there are 3 equivalent paths in this network topology.

[0214] As an example, taking Flow 1 as an example, the dual - port NIC of Flow 1 does not support out - of - order. The specific steps are as follows.

[0215] S801. When the sending node sends Packet 1, Packet 2, and Packet 3, it identifies that the receiving node does not support out - of - order and fills the third identification bit of the packets with 0.

[0216] Among them, when the third identification bit of the message is 0, it indicates that equal-cost multi-path routing (ECMP) is not allowed for each packet.

[0217] S802. The left switch receives message 1, discovers it is a new flow direction, selects path 1 to forward message 1 through the hash algorithm. When receiving subsequent messages 2 and 3, it identifies that the third identification bit of the message is 0, adopts an in-sequence strategy, and selects path 1 to forward messages 2 and 3.

[0218] S803. The receiving node receives messages 1, 2, and 3 in sequence and delivers them to the upper layer for processing.

[0219] Another example, taking flow direction 2 as an example, the dual-port NIC of flow direction 2 supports out-of-sequence, which specifically includes the following steps.

[0220] S901. When the sending end sends message a and message b, it identifies that the receiving node supports out-of-sequence and fills the third identification bit of both messages with 1.

[0221] Among them, when the third identification bit of the message is 1, it indicates that per-packet ECMP is allowed.

[0222] S902. The left switch receives message a and message b, identifies that the third identification bit of the message is 1, performs per-packet ECMP, selects path 2 to forward message a, and selects path 3 to forward message b.

[0223] It should be noted that when the switch performs per-packet ECMP, it discovers 3 equivalent paths, but there is already a high load on path 1. Therefore, it only performs ECMP between path 2 and path 3. Finally, through the hash algorithm, message a is hashed to path 2 and message b is hashed to path 3.

[0224] S903. The receiving node receives messages a and b out of sequence, performs out-of-sequence rearrangement processing and then delivers them to the upper layer for processing.

[0225] In one embodiment, taking the following Figure 16 shown network topology as an example, per-packet balancing but in-sequence preservation of consecutive packets can be achieved through the third identification bit, which specifically includes the following steps.

[0226] It should be noted that the switch has enabled the per-packet ECMP function, but at the same time sets a flowlet interval of 5 us (that is, messages with a packet interval less than 5 us are considered to belong to the same flowlet). For the same flowlet, in-sequence transmission needs to be performed.

[0227] S1001. When the sending node sends packets a / b / c / d / e / f / g and recognizes that the receiving node supports out-of-order, it fills the third identification bit of the packets with 1.

[0228] S1002. When the switch receives packet a and recognizes that the third identification bit of packet a is 1, it performs per-packet ECMP and selects path 2 to forward packet a through the hash algorithm. When it receives packets b / c and finds that the packet intervals are both less than 5 us, it regards packets b / c as belonging to the same flowlet as packet a and forwards packets b / c along path 2 of packet a.

[0229] S1003. When the switch receives packet d and finds that the packet interval between packet d and packet c is greater than 5 us and the third identification bit of packet d is 1, it performs per-packet ECMP and selects path 3 to forward packet d through the hash algorithm. When it receives packets e / f / g and finds that the packet intervals are both less than 5 us, it regards packets e / f / g as belonging to the same flowlet as packet d and forwards packets e / f / g along path 3 of packet d.

[0230] It can be understood that by combining the flowlet in-order technology with the third identification bit, per-packet balance but consecutive-packet in-order can be achieved.

[0231] In one embodiment, taking the following Figure 17 shown network topology as an example, the transmission distance of the packet can be discriminated through the fourth identification bit, which specifically includes the following steps.

[0232] It should be noted that the fourth identification bit is used to indicate the transmission distance of the packet. The fourth identification bit being 0 indicates short-distance transmission, and the fourth identification bit being 1 indicates long-distance transmission.

[0233] S1101. When the sending node sends the first handshake packet, it fills the fourth identification bit of the packet with 0.

[0234] S1102. When Switch 1 forwards the packet and recognizes that the outgoing interface of this packet is an intra-domain link (i.e., a short-distance link), it does not modify the fourth identification bit of this packet.

[0235] S1103. When the intelligent computing gateway 1 forwards the packet and recognizes that the outgoing interface of this packet is a long-distance link, it modifies the fourth identification bit of this packet to 1.

[0236] S1104. When the intelligent computing gateway 2 forwards the packet and recognizes that the outgoing interface of this packet is an intra-domain link, it does not modify the fourth identification bit of this packet.

[0237] S1105. When Switch 2 forwards the packet and recognizes that the outgoing interface of this packet is an intra-domain link, it does not modify the fourth identification bit of this packet.

[0238] It should be noted that for intermediate nodes, if the outgoing interface of the message is identified as a short - distance link, the fourth identification bit of this message is not modified. If the outgoing interface of the message is identified as a long - distance link, the fourth identification bit of the message is modified to 1.

[0239] S1105. When the receiving node sends the first handshake feedback message, it copies the fourth identification bit of the received first handshake message to the fourth identification bit of the first feedback message.

[0240] S1106. When the sending node receives the first handshake feedback message and identifies that the fourth identification bit of the message is 1, it determines that this flow direction is long - distance transmission.

[0241] Furthermore, after the sending node identifies long / short - distance transmission during the handshake phase, it can adopt different congestion control strategies according to the discrimination result.

[0242] Exemplarily, taking the Figure 18 network topology shown below as an example, when the sending node conducts the handshake for Flow 1 and identifies that the fourth identification bit of the first handshake feedback message is 0, it determines that Flow 1 is short - distance transmission and adopts the normal version of the DCQCN congestion control algorithm. When the sending node conducts the handshake for Flow 2 and identifies that the fourth identification bit of the first handshake feedback message is 1, it determines that Flow 1 is long - distance transmission and adopts the long - distance optimized version of the DCQCN congestion control algorithm.

[0243] Optionally, taking the Figure 19 network topology shown below as an example, the intermediate node can determine the priority of processing messages according to the fourth identification bit of the received first message. Specifically, when Flow 1 sends the first message, since it does not pass through a long - distance link during the transmission process, the fourth identification bit of the message remains 0. When Flow 2 sends the first message, after passing through the intelligent computing gateway 1, the fourth identification bits of the messages all remain 1, and subsequent nodes can all identify this mark. When switch 2 processes the messages of Flow 1 and Flow 2 simultaneously and finds that the fourth identification bit of the message of Flow 2 is 1 and the fourth identification bit of the message of Flow 1 is 0, it preferentially processes the message of Flow 2.

[0244] In one embodiment, as shown in Figure 20 below, the sending node can adjust the deceleration step size adopted by the congestion control algorithm according to the fourth identification bit of the received congestion notification packet (CNP), which specifically includes the following steps.

[0245] It should be noted that the fourth identification bit is modified to 1 only when the message passes through the long-distance link. Therefore, the fourth identification bit of the fast CNP message generated by the proximal congestion has not been set to 1, while the fourth identification bit of the fast CNP message generated by the distal congestion has been set to 1. The sending node can distinguish between proximal congestion and distal congestion based on the received fast CNP message, and then adopt different congestion control strategies.

[0246] Case 1: The proximal intermediate node detects congestion

[0247] S1201. The intelligent computing gateway 1 sends a fast CNP message to the sending node.

[0248] Among them, the fourth identification bit of the fast CNP message is 0.

[0249] S1202. The sending node receives the fast CNP message, identifies that the fourth identification bit of this message is 0, determines it as in-domain congestion, and adjusts the deceleration step size adopted by the congestion control algorithm to parameter 1.

[0250] It should be noted that parameter 1 is a small step size, the in-domain congestion feedback period is short, and using a small step size for deceleration can more accurately control the rate.

[0251] Case 2: The distal intermediate node detects congestion

[0252] S1301. The switch 2 sends a fast CNP message to the sending node.

[0253] Among them, the fourth identification bit of the fast CNP message is 1.

[0254] S1302. The sending node receives the fast CNP message, identifies that the fourth identification bit of this message is 1, determines it as out-of-domain congestion, and adjusts the deceleration step size adopted by the congestion control algorithm to parameter 2.

[0255] It should be noted that parameter 2 is a large step size, the out-of-domain congestion feedback period is long, and using a large step size for deceleration can quickly reduce the rate to a rate that will not cause congestion.

[0256] Exemplarily, Figure 21 is a schematic diagram of the encapsulation positions of multiple identification bits provided by an embodiment of the present application. As Figure 21 shown, the new message header includes a first identification bit, a second identification bit, a third identification bit, a fourth identification bit, and a numerical field. The message encapsulation format of the new message header is two-layer encapsulation, which can be located after the VLAN header, or after the MAC header if there is no VLAN header. The Roce inner-layer encapsulation includes an IP header, a UDP header, a BTH header, and a message core.

[0257] Optionally, the above new header may further include a reserved field. The reserved field can mark the protocol number of the upper-layer encapsulation.

[0258] It can be understood that the above token-based network congestion control method can be implemented by a token-based network congestion control device. In order to implement the above functions, the token-based network congestion control device includes the corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should easily realize that, combining the modules and algorithm steps of each example described in the embodiments disclosed in this application, the disclosed embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the disclosed embodiments of the present application.

[0259] The disclosed embodiments of the present application can perform the division of functional modules according to the token-based network congestion control device generated by the above method examples. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of a software functional module. It should be noted that the division of modules in the disclosed embodiments of the present application is illustrative, only a logical function division, and there can be other division methods in actual implementation.

[0260] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A token-based network congestion control method, characterized in that: Applied to a sending node, the method comprises: Sending a first message to an intermediate node, the first message comprising a plurality of identification bits, the plurality of identification bits comprising a first identification bit, a second identification bit, and a numerical field comprising a plurality of numerical bits; wherein the first identification bit is used to indicate whether modification of the numerical value of the numerical field is allowed, the second identification bit is used to indicate whether to reserve transmission resources according to the numerical value of the numerical field, and the numerical field is used to determine the data volume or rate; A first feedback message is received from a receiving node, and according to a plurality of identification bits in the first feedback message, an amount of data sent to the receiving node is limited or a rate of sending data to the receiving node is adjusted.

2. The method according to claim 1, characterized in that The limiting the amount of data sent to the receiving node or adjusting the rate of sending data to the receiving node according to the multiple identification bits in the first feedback message includes: Determine a corresponding token value according to the value of the value field in the first feedback message; According to the token value, the amount of data sent to the receiving node is limited; or according to the token value, the rate change is determined based on the interval duration, and the rate of sending data to the receiving node is adjusted according to the rate change.

3. A token-based network congestion control method, characterized in that: Applied to an intermediate node, the method comprises: Receive a first message from a sending node, the first message including a plurality of identification bits, the plurality of identification bits including a first identification bit, a second identification bit, and a numerical field including a plurality of numerical bits; wherein the first identification bit is used to indicate whether to allow modification of a numerical value of the numerical field, the second identification bit is used to indicate whether to reserve transmission resources according to the numerical value of the numerical field, and the numerical field is used to determine a data volume or a rate; In a case where the first identification bit in the first message is a first value, determining the resource usage of the device, determining a recommended token value according to the resource usage, and modifying the value of the value field in the first message according to the recommended token value; When the first identification bit in the first message is the second value, the value of the value field in the first message is not modified; When the second identification bit in the first message is a first value, reserving transmission resources according to the value of the value field in the first message; Send the first message to a receiving node.

4. The method according to claim 3, characterized in that: The determining of the resource usage of the self includes: Obtain the number of bytes passed, the number of tokens allocated, and a transmission volume threshold within a preset statistical period, wherein the transmission volume threshold represents the upper limit of the amount of data that can be tolerated within the preset statistical period and is obtained based on the physical bandwidth and the preset statistical period; Obtaining a speed increase or decrease space according to a difference between the transmission volume threshold and the number of allocated tokens; The speed increase / deceleration ratio is obtained according to the ratio between the speed increase / deceleration space and the number of bytes passed.

5. The method according to claim 4, characterized in that The method further comprises: Determine an upper limit of a recommended token value, where the upper limit of the recommended token value is the product of the transmission volume threshold and a preset coefficient, and the preset coefficient is greater than or equal to 1.

6. The method according to claim 5, characterized in that The determining the recommended token value according to the resource usage, and modifying the value of the value field in the first message according to the recommended token value, includes: Determining the recommended token value according to the speed increase / deceleration ratio and the message length of the first message; If the number of allocated tokens exceeds the upper limit of the recommended token value, the recommended token value is adjusted to 0; When the recommended token value is less than the current value of the numerical field in the first message, modifying the numerical field in the first message to the recommended token value; When the recommendation token value is greater than or equal to the current value of the numerical field in the first message, the numerical field in the first message is not modified.

7. A token-based network congestion control method, characterized in that: Applied to a receiving node, the method comprises: Receive a first message from an intermediate node, the first message including multiple identification bits, the multiple identification bits including a first identification bit, a second identification bit, and a numerical field including multiple numerical bits; wherein the first identification bit is used to indicate whether to allow modification of the numerical value of the numerical field, the second identification bit is used to indicate whether to reserve transmission resources according to the numerical value of the numerical field, and the numerical field is used to determine the data volume or rate; Determine a first feedback message according to at least one of the first messages; Send the first feedback message to the sending node.

8. The method according to claim 7, characterized in that The determining a first feedback message according to at least one of the first messages includes: Aggregate the values ​​of the numerical fields in the at least one first message, and fill the aggregated values ​​of the numerical fields into the first feedback message; The first identification bit in the first feedback message is filled with the second value, and the second identification bit in the first feedback message is filled with the second value to obtain a first feedback message.

9. The method according to any one of claims 1 to 8, characterized in that The first message also includes a third identification bit or a fourth identification bit, the third identification bit is used to indicate whether packet-by-packet equal-cost multi-path load balancing is allowed, and the fourth identification bit is used to indicate the transmission distance of the message, and the transmission distance includes long distance and short distance.

10. A token-based network congestion control device, characterized in that: include: A processor and a communication interface; the communication interface is coupled to the processor, and the processor is used to run a computer program or instruction to implement the token-based network congestion control method as described in any one of claims 1-9.

Images