A method, apparatus and equipment for limiting flow rate

Abstract

This application provides a traffic rate limiting method, apparatus, and device. The method includes: determining target scenario model parameters based on traffic scenario data corresponding to a target port; wherein the target scenario model parameters include at least the fiber length corresponding to a long-distance optical fiber; querying a target rate limiting policy corresponding to the target scenario model parameters based on a mapping table; and rate limiting CNP packets received by the target port based on the target rate limiting policy, wherein the CNP packets are used to control the source device to reduce the transmission rate of a specified type of data; wherein the mapping table includes the correspondence between scenario model parameters and rate limiting policies, and the rate limiting policy is used to enable the target port to have optimal data transmission performance under the scenario model parameters. Through the technical solution of this application, the forwarding performance of the target port can be improved, enabling the network device to achieve optimal data transmission performance.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus and device for limiting data flow. Background Technology

[0002] With the increase in high-concurrency, low-latency services, network devices (such as switches and routers) are prone to network congestion at their outgoing ports. Network congestion refers to the phenomenon where a large amount of data is stuck (buffered) in the outgoing queue (the queue corresponding to the outgoing port) when the traffic received by a network device through its incoming port is much greater than the traffic sent through its outgoing port. This affects network performance such as data transmission latency and throughput.

[0003] To resolve network congestion, network devices add congestion markers to the data when forwarding it to the destination device. After receiving the data carrying the congestion marker, the destination device sends a CNP (Congestion Notification Packet) message to the source device. Upon receiving the CNP message, the source device reduces its data transmission rate, thereby reducing the traffic received by the network device through the ingress port and resolving network congestion.

[0004] However, in long-distance fiber optic scenarios, the large distance between the source and destination devices results in significant network link latency, meaning longer transmission times for CNP packets. This can cause the source device to be unable to reduce its data transmission rate in a timely manner, leading to poor data transmission performance on the network. For example, a network device might receive a large amount of data during one period, causing network congestion, and then receive a small amount of data during another period, failing to fully utilize the bandwidth resources of its outgoing ports. This process repeats itself, resulting in poor data transmission performance. Summary of the Invention

[0005] This application provides a traffic limiting method applied to a network device, the network device including a target port, the target port being connected to other devices via a long-distance optical fiber, the method comprising:

[0006] The target scenario model parameters are determined based on the traffic scenario data corresponding to the target port; wherein, the target scenario model parameters include at least the fiber length corresponding to the long-distance fiber.

[0007] Based on the mapping table, query the target speed limiting strategy corresponding to the target scene model parameters;

[0008] Based on the target rate limiting policy, the congestion notification data packet (CNP) received by the target port is rate-limited, and the CNP packet is used to control the source device to reduce the sending rate of a specified type of data.

[0009] The mapping table includes the correspondence between scene model parameters and rate limiting strategies. The rate limiting strategy is used to ensure that the target port has optimal data transmission performance under the scene model parameters.

[0010] This application provides a traffic limiting device applied to a network device, the network device including a target port, the target port being connected to other devices via a long-distance optical fiber, the device comprising:

[0011] The determination module is used to determine target scenario model parameters based on the traffic scenario data corresponding to the target port; wherein, the target scenario model parameters include at least the fiber length corresponding to the long-distance optical fiber;

[0012] The acquisition module is used to query the target rate limiting policy corresponding to the target scene model parameters based on the mapping table; wherein, the mapping table includes the correspondence between scene model parameters and rate limiting policies, and the rate limiting policy is used to enable the target port to have the optimal data transmission performance under the scene model parameters;

[0013] The processing module is used to rate-limit the CNP packets received by the target port based on the target rate-limiting policy. The CNP packets are used to control the source device to reduce the transmission rate of specified data types.

[0014] This application provides a network device, including: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the traffic limiting method of the above example.

[0015] As can be seen from the above technical solutions, in the embodiments of this application, in long-distance fiber optic scenarios, the rate limiting of CNP packets received by the target port can be implemented, thereby preventing the source device from receiving a large number of CNP packets in a short period of time. This results in a more balanced and smoother distribution of CNP packets received by the source device, making the rate reduction process (i.e., the process of reducing the data transmission rate) of the source device smoother. It avoids the source device experiencing a large rate reduction for a period of time followed by a small or no rate reduction for another period. This leads to better data transmission performance of the network device, preventing network congestion caused by receiving a large amount of data in one period and insufficient bandwidth utilization caused by receiving a small amount of data in another. Furthermore, the rate limiting of CNP packets received by the target port can be based on the target rate limiting strategy corresponding to the target scenario model parameters (i.e., actual scenario model parameters) of the network device. The target rate limiting strategy matches the actual scenario of the network device, resulting in better rate limiting effect. The target scenario model parameters at least include the fiber length corresponding to the long-distance fiber, making the target rate limiting strategy related to the fiber length. This means finding the target rate limiting strategy that best matches the fiber length further improves the forwarding performance of the target port, allowing the network device to achieve optimal data transmission performance. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments of this application or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this application.

[0017] Figure 1 This is a flowchart illustrating a traffic rate limiting method in one embodiment of this application;

[0018] Figure 2 This is a schematic diagram of an application scenario of data center interconnection in one embodiment of this application;

[0019] Figure 3 This is a schematic diagram of a long-distance fiber optic data center interconnection scenario in one embodiment of this application;

[0020] Figure 4 This is a flowchart illustrating the testing process in one embodiment of this application;

[0021] Figure 5 This is a flowchart illustrating the application process in one embodiment of this application;

[0022] Figure 6 This is a schematic diagram of the flow rate limiting device in one embodiment of this application;

[0023] Figure 7 This is a hardware structure diagram of a network device according to one embodiment of this application. Detailed Implementation

[0024] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” as used in this application and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0025] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."

[0026] This application proposes a traffic limiting method, which can be applied to network devices (such as routers, switches, etc.). The network device includes a target port, and the target port is connected to other devices via long-distance optical fiber. See [link to relevant documentation]. Figure 1 The diagram shown is a flowchart of the method, which may include:

[0027] Step 101: Determine the target scenario model parameters based on the traffic scenario data corresponding to the target port; wherein, the target scenario model parameters may include at least the fiber length corresponding to the long-distance fiber.

[0028] Step 102: Query the target speed limiting strategy corresponding to the target scene model parameters based on the mapping table.

[0029] For example, the mapping table may include the correspondence between scene model parameters and rate limiting policies, whereby the rate limiting policy is used to ensure that the target port has optimal data transmission performance under the given scene model parameters. Since the mapping table includes the correspondence between scene model parameters and rate limiting policies, after obtaining the target scene model parameters, the target rate limiting policy corresponding to the target scene model parameters can be obtained by querying the mapping table.

[0030] Step 103: Rate limit the CNP messages received at the target port based on the target rate limiting policy. The CNP messages are used to control the source device to reduce the transmission rate of specified data types.

[0031] For example, before querying the target rate-limiting policy corresponding to the target scenario model parameters based on the mapping table, a process of establishing the mapping table may also be included. Specifically, during the process of establishing the mapping table, scenario model parameters can be determined based on the traffic scenario data corresponding to the target port in the test environment, and multiple rate-limiting policies corresponding to the scenario model parameters can be obtained. For each rate-limiting policy, the CNP packets received by the target port can be rate-limited based on the rate-limiting policy, and the data transmission performance of the target port after rate-limiting can be statistically analyzed. Based on the data transmission performance corresponding to each rate-limiting policy, the correspondence between the scenario model parameters and the rate-limiting policy corresponding to the optimal data transmission performance is recorded in the mapping table.

[0032] For example, the target port corresponds to multiple priority queues, and the multiple priority queues include a target priority queue for carrying a specified type of data. Statistical analysis of the data transmission performance of the target port after rate limiting may include, but is not limited to: calculating the average bandwidth of the queues corresponding to the target priority queues, and calculating the round-trip latency corresponding to the specified type of data in the target priority queues; based on the average bandwidth of the queues and / or the round-trip latency, the data transmission performance of the target port after rate limiting can be determined; wherein, the data transmission performance is directly proportional to the average bandwidth of the queues, and inversely proportional to the round-trip latency.

[0033] For example, the target port corresponds to multiple priority queues, and the multiple priority queues include a target priority queue for carrying data of a specified type. The target scenario model parameters may also include, but are not limited to, at least one of the following: the device type of the network device, the outgoing port rate of the target port, the number of incoming ports corresponding to the specified type of data in the target priority queue, and the queue level of the target priority queue.

[0034] The queue level can be determined based on the average bandwidth of the target priority queue and the average bandwidth of other priority queues besides the target priority queue.

[0035] For example, the target ECN (Explicit Congestion Notification) parameter corresponding to the target port can also be obtained; in this way, when sending data of a specified type in the target priority queue corresponding to the target port, a congestion flag is added to the specified type of data based on the target ECN parameter; wherein, the specified type of data with the congestion flag is used to enable the destination device to send a CNP message to the source device.

[0036] For example, the target ECN parameters may include, but are not limited to, the target baseline, the target high watermark, and the target labeling probability. Based on these parameters, adding congestion labels to specified data types may include, but are not limited to: if the queue length of the target priority queue is greater than the target baseline and the queue length of the target priority queue is not greater than the target high watermark, then adding congestion labels to specified data types based on the target labeling probability; if the queue length of the target priority queue is greater than the target high watermark, then adding congestion labels to all specified data types in the target priority queue.

[0037] For example, the target rate limiting policy may include, but is not limited to, a rate limit value for CNP packets, where the rate limit value represents the number of bytes of CNP packets allowed to pass per second, or the rate limit value represents the number of CNP packets allowed to pass per second. The specified data type may include, but is not limited to, ROCE (RDMA over Converged Ethernet) data.

[0038] As can be seen from the above technical solutions, in the embodiments of this application, in long-distance fiber optic scenarios, the rate limiting of CNP packets received by the target port can be implemented, thereby preventing the source device from receiving a large number of CNP packets in a short period of time. This results in a more balanced and smoother distribution of CNP packets received by the source device, making the rate reduction process (i.e., the process of reducing the data transmission rate) of the source device smoother. It avoids the source device experiencing a large rate reduction for a period of time followed by a small or no rate reduction for another period. This leads to better data transmission performance of the network device, preventing network congestion caused by receiving a large amount of data in one period and insufficient bandwidth utilization caused by receiving a small amount of data in another. Furthermore, the rate limiting of CNP packets received by the target port can be based on the target rate limiting strategy corresponding to the target scenario model parameters (i.e., actual scenario model parameters) of the network device. The target rate limiting strategy matches the actual scenario of the network device, resulting in better rate limiting effect. The target scenario model parameters at least include the fiber length corresponding to the long-distance fiber, making the target rate limiting strategy related to the fiber length. This means finding the target rate limiting strategy that best matches the fiber length further improves the forwarding performance of the target port, allowing the network device to achieve optimal data transmission performance.

[0039] The following describes the traffic limiting method of this application embodiment in conjunction with specific application scenarios.

[0040] See Figure 2The diagram illustrates an application scenario for data center interconnection. When a server in DC1 (Data Center) sends data to a server in DC2, the server in DC1 is referred to as the sending server (also known as the source device), and the server in DC2 is referred to as the receiving server (also known as the destination device). When a server in DC2 sends data to a server in DC1, the server in DC2 is referred to as the source device, and the server in DC1 is referred to as the destination device. For ease of description, in the following embodiments, the server in DC1 is used as the source device and the server in DC2 is used as the destination device.

[0041] There are multiple network devices (such as routers, switches, etc.) between the source device and the destination device, and the source device and the destination device are connected through multiple network devices. Device A and Device B are network devices located between the source device and the destination device. Device A and Device B serve as the egress devices for data center interconnection. Device A is the egress device for DC1, and Device B is the egress device for DC2.

[0042] With the increase in high-concurrency and low-latency services, network device outgoing ports are prone to network congestion, which affects network performance such as data transmission latency and throughput. To ensure high performance in data centers, lossless Ethernet needs to be built to guarantee packet-free network transmission; therefore, it is necessary to solve the network congestion problem. To solve this problem, network devices add congestion markers to the data when forwarding it to the destination device. After receiving the data carrying the congestion marker, the destination device sends a CNP message to the source device. Upon receiving the CNP message, the source device reduces its data transmission rate, thus reducing the traffic received by the network device through its incoming port and resolving the network congestion problem. For example, when network congestion occurs at the outgoing port of Device A, Device A will send data carrying the congestion marker to the receiving server (i.e., the destination device) of DC2. The receiving server of DC2 will then send a CNP message to the sending server (i.e., the source device) of DC1. After receiving the CNP message, the sending server of DC1 will reduce its data transmission rate, thus reducing the traffic received by Device A and resolving the network congestion problem.

[0043] However, in long-distance fiber optic scenarios, due to the large distance between the source and destination devices (i.e., the distance between the sending server of DC1 and the receiving server of DC2) and the large network link latency, the transmission time of CNP messages is long. As a result, the source device cannot reduce the data transmission rate in time, resulting in poor data transmission performance of network devices (such as Device A, Device B, etc.).

[0044] For example, in long-distance fiber optic interconnection scenarios for data centers, the length of the fiber optic cable can reach tens or even hundreds of kilometers. Although the data propagation rate on long-distance fiber optic cables is very fast, there is also a relatively long latency in such scenarios, which may reach the millisecond level. This means that the network link latency is large, resulting in a long transmission time for CNP packets. The CNP packets have a large delay, which in turn prevents the source device from reducing the data transmission rate in time, causing a serious deterioration in the data transmission performance of the network device.

[0045] See Figure 3 The diagram shown illustrates a long-distance fiber optic interconnection scenario for data centers. This diagram is designed for... Figure 2 The simplified diagram shows the sending server as the source device, the receiving server as the destination device, and Device A and Device B as network devices. Device A is connected to Device B through a long-distance port, and there is a long-distance optical fiber between Device A and Device B.

[0046] In the above network environment, assuming the long-distance fiber optic cable between Device A and Device B is 60km, when the sending server sends 100G data to the receiving server, with CNP messages enabled to resolve network congestion, the test shows that the receiving server can only receive 52G of traffic. If the long-distance fiber optic cable between Device A and Device B is replaced with a short-distance fiber optic cable, such as a few kilometers, when the sending server sends 100G data to the receiving server, with CNP messages enabled to resolve network congestion, the test shows that the receiving server can receive more than 90G of traffic. In summary, it can be seen that in long-distance fiber optic scenarios, data transmission performance is relatively poor, and the traffic rate periodically decreases from nearly 100G (line speed) to a much lower level, such as 52G.

[0047] In response to the above findings, this application proposes a traffic rate limiting method. In long-distance fiber optic scenarios, the rate of CNP packets received by the target port can be limited, thereby preventing the source device from receiving a large number of CNP packets in a short period of time. This makes the CNP packets received by the source device more balanced and smooth, and the rate reduction process of the source device is smoother, thus improving the data transmission performance of the network device.

[0048] This application embodiment involves testing and application processes. During testing, the correspondence between scenario model parameters and rate-limiting policies can be obtained, and this correspondence is recorded in mapping table A. Similarly, the correspondence between traffic scenario parameters and ECN parameters can be obtained, and this correspondence is recorded in mapping table B. During application, target ECN parameters can be obtained based on mapping table B, and data can be sent based on these target ECN parameters. Target rate-limiting policies can be obtained based on mapping table A, and rate-limiting of CNP packets can be applied based on these target rate-limiting policies.

[0049] In one possible implementation, see Figure 4 The diagram shown is a flowchart of the testing process.

[0050] Step 401: The network device obtains the traffic scenario data corresponding to the target port in the test environment.

[0051] For example, if a port of a network device is connected to other devices via a long-distance optical fiber, this port is referred to as the target port. That is, the target port of the network device is connected to other devices via a long-distance optical fiber. Long-distance optical fiber is a type of optical fiber that indicates that the optical fiber is relatively long, such as the optical fiber length being greater than a length threshold.

[0052] For example, the target port corresponds to multiple priority queues, and these priority queues include a target priority queue for carrying data of a specified type, which may include, but is not limited to, ROCE data. The target priority queue needs to have PFC (Priority-based Flow Control) and ECN configurations enabled to enable lossless forwarding.

[0053] For example, a target port can correspond to eight priority queues, denoted as cos0, cos1, cos2, cos3, cos4, cos5, cos6, and cos7. Cos4 and / or cos5 can be set as the target priority queue, and PFC and ECN configurations can be enabled for them. Of course, other queues can also be set as target priority queues; there are no restrictions on this. After receiving data of a specified type (such as ROCE data), if the network device needs to forward the specified type of data through the target port, it will store the specified type of data in the target priority queue.

[0054] For example, a test environment can be pre-built (such as in a laboratory), and the network device can obtain traffic scenario data for the target port under that test environment. For instance, test environment 1 can be built first, and traffic scenario data for the target port under test environment 1 can be obtained. Then, test environment 2 can be built, and traffic scenario data for the target port under test environment 2 can be obtained. Then, test environment 3 can be built, and traffic scenario data for the target port under test environment 3 can be obtained, and so on.

[0055] By constructing numerous test environments and collecting traffic scenario data under different test environments, traffic scenario parameters and scenario model parameters can be obtained for each test environment. The differences between the different test environments are as follows: different test environments may correspond to different incasts (representing the number of ingress ports corresponding to a specified type of data in the target priority queue, i.e., how many ingress ports correspond to the target port), meaning different test environments are constructed by changing the incast; the average bandwidth of the ingress ports may differ between test environments, meaning different test environments are constructed by changing the average bandwidth of the ingress ports; different test environments may correspond to different fiber lengths of long-distance optical fibers, meaning different test environments are constructed by changing the fiber length of long-distance optical fibers; different test environments may correspond to different outgress port rates, meaning different test environments are constructed by changing the outgress port rate of the target port; different test environments may correspond to different numbers of ROCE data streams, meaning different test environments are constructed by changing the number of ROCE data streams. Of course, the above are just a few examples and are not a limitation; a large number of different test environments can be constructed, and traffic scenario data can be collected under different test environments.

[0056] For each test environment, in order to obtain the traffic scenario data corresponding to the target port in that test environment, the specified type of data (such as ROCE data) in the target priority queue can be sent to the FPGA (Field Programmable Gate Array) or CPU (Central Processing Unit) by sampling and mirroring. The FPGA or CPU will then perform statistics on the specified type of data to obtain the traffic scenario data corresponding to the target port in that test environment.

[0057] For example, traffic scenario data may include, but is not limited to, at least one of the following: the number of packets in a ROCE data stream (taking ROCE data as an example, ROCE data with the same 3-tuples constitute a ROCE data stream, and the 3-tuples may include source IP, destination IP, and destination QP, etc.), the total length of packets in a ROCE data stream (i.e., the total length of all packets in a ROCE data stream), the average length of packets in a ROCE data stream (i.e., the quotient of the total length of packets and the number of packets), the service flow rate of a ROCE data stream, the number of packet losses in a ROCE data stream (i.e., how many packets are lost in a ROCE data stream), the ingress and egress ports of a ROCE data stream, the VXLAN (Virtual Extensible Local Area Network) encapsulation information of a ROCE data stream, and the inactivity time of a ROCE data stream, etc. When there are multiple ROCE data streams, the traffic scenario data can include the number of packets corresponding to each ROCE data stream, the total packet length, the average packet length, the service flow rate, the number of packet losses, the ingress and egress ports, VXLAN encapsulation information, and the inactive time.

[0058] Using a target priority queue as the unit, select ROCE data flows that are dequeued from that target priority queue. Aggregate and statistically analyze the aforementioned information of the ROCE data flows (such as the number of packets, total packet length, average packet length, service flow rate, number of packet losses, ingress and egress ports, VXLAN encapsulation information, and inactive time). Traffic scenario data may also include, but is not limited to, at least one of the following: the average bandwidth corresponding to the target priority queue, and the number of ingress ports corresponding to the target priority queue (the number of ingress ports can be called Incast, used to represent the total number of ingress ports corresponding to all ROCE data flows in the target priority queue, i.e., determining the ingress ports of all ROCE data flows and counting the total number of ingress ports). The number of data streams per ingress port corresponding to the target priority queue (i.e., the number of ROCE data streams, which can be called Flow), the number of high-bandwidth data streams per ingress port corresponding to the target priority queue (i.e., the number of ROCE data streams with high bandwidth, where high bandwidth refers to bandwidth greater than a certain threshold, and the number of high-bandwidth data streams can be called BigFlow), the average bandwidth of each ingress port corresponding to the target priority queue, the ratio of different types of ROCE data streams corresponding to the target priority queue (e.g., the ratio between write-type ROCE data streams, read-type ROCE data streams, and send-type ROCE data streams), and the RTT (Round Trip Time) corresponding to the target priority queue.

[0059] Based on the aforementioned traffic scenario data (i.e., data obtained from specified types of data in the target priority queue), traffic scenario data for network devices can also be statistically analyzed. For example, traffic scenario data may include, but is not limited to, at least one of the following: network device type, fiber length corresponding to the long-distance fiber, and outgoing port rate of the target port. The network device type can be, for example, XGS, June, Marvel, etc., without limitation. For the fiber length corresponding to the long-distance fiber, multiple candidate lengths can be pre-configured, such as positive integer multiples of 10km, such as 10km, 20km, 30km, etc. When the target port is connected to other devices via the long-distance fiber, the actual length of the long-distance fiber can be calculated, and the candidate length closest to this actual length can be selected from all candidate lengths. This candidate length is the fiber length corresponding to the long-distance fiber. The outgoing port rate of the target port can be, for example, 25G, 100G, etc., without limitation.

[0060] Of course, the above are just a few examples of traffic scenario data, and there are no restrictions on this type of traffic scenario data.

[0061] Step 402: The network device determines the traffic scenario parameters based on the traffic scenario data corresponding to the target port.

[0062] For example, for each test environment, after obtaining the traffic scenario data corresponding to the target port in that test environment, the traffic scenario parameters corresponding to that test environment can be determined based on the traffic scenario data, thus obtaining the traffic scenario parameters for each test environment. These traffic scenario parameters may include, but are not limited to, at least one of the following: the network device type, the outgoing port rate of the target port, the number of ingoing ports corresponding to a specified type of data in the target priority queue, and the queue level of the target priority queue. Of course, the above are just a few examples; traffic scenario parameters may also include other parameters, and there are no restrictions on this.

[0063] Regarding the device type of network devices, since the traffic scenario data includes the device type of network devices, the device type of network devices can be directly determined based on the traffic scenario data. The device type of network devices can be such as XGS type, June type, Marvel type, etc., without any restrictions.

[0064] Regarding the outgoing port rate of the target port, since the traffic scenario data includes the outgoing port rate of the target port, the outgoing port rate of the target port can be determined directly based on the traffic scenario data. The outgoing port rate of the target port can be, for example, 25G, 100G, etc., without any restrictions.

[0065] Specifically, regarding the number of ingress ports corresponding to a specified type of data in the target priority queue, since the traffic scenario data includes the number of ingress ports corresponding to the target priority queue, the number of ingress ports corresponding to a specified type of data in the target priority queue can be directly determined based on the traffic scenario data. The number of ingress ports can be called Incast, which indicates how many ingress ports correspond to the target port.

[0066] Specifically, the queue range value (i.e., the queue level of the target priority queue) can be determined based on the average bandwidth of the target priority queue and the average bandwidth of other priority queues. For example, it can be determined based on the average bandwidth of the target priority queue (determined based on traffic scenario data), the average bandwidth of other priority queues (determined based on traffic scenario data), and the outgoing port rate of the target port (determined based on traffic scenario data). Assuming the average bandwidth of the target priority queue is 10G, the average bandwidth of other priority queues is 5G, and the outgoing port rate of the target port is 25G, then the queue range value could be 10 / (25-5), or 0.5.

[0067] In summary, we can obtain traffic scenario parameters such as the network device type, the egress rate of the target port, the number of ingress ports, and the queue level of the target priority queue. These parameters are used to identify the traffic scenario of the target port. These parameters are grouped into a parameter vector (DeviceType, PortSpeed, Incast, Range), which serves as the basis for dividing the scenario model; different parameter vectors correspond to different scenario models. DeviceType represents the network device type, PortSpeed ​​represents the egress rate of the target port, Incast represents the number of ingress ports, and Range represents the queue level of the target priority queue.

[0068] Step 403: The network device determines the scenario model parameters based on the traffic scenario data corresponding to the target port.

[0069] For example, for each test environment, after obtaining the traffic scenario data corresponding to the target port in that test environment, the scenario model parameters corresponding to that test environment can be determined based on the traffic scenario data, thus obtaining the scenario model parameters for each test environment. These scenario model parameters may include, but are not limited to, at least one of the following: the fiber length corresponding to the long-distance fiber (i.e., the long-distance fiber corresponding to the target port), the device type of the network device, the outgoing port rate of the target port, the number of incoming ports corresponding to a specified type of data in the target priority queue, and the queue level of the target priority queue. Of course, the above are just a few examples of scenario model parameters; other parameters may also be included, without limitation.

[0070] Specifically, regarding the fiber length corresponding to long-distance optical fibers, since the traffic scenario data includes the fiber length corresponding to long-distance optical fibers, the fiber length can be directly determined based on the traffic scenario data. Regarding the network device type, since the traffic scenario data includes the network device type, the network device type can be directly determined based on the traffic scenario data. Regarding the outgoing port rate of the target port, since the traffic scenario data includes the outgoing port rate of the target port, the outgoing port rate of the target port can be directly determined based on the traffic scenario data. Regarding the number of incoming ports corresponding to a specified type of data in the target priority queue, since the traffic scenario data includes the number of incoming ports corresponding to the target priority queue, the number of incoming ports corresponding to the specified type of data in the target priority queue can be directly determined based on the traffic scenario data. Regarding the queue level (i.e., queue range value) of the target priority queue, it can be determined based on the average queue bandwidth of the target priority queue (determined based on traffic scenario data) and the average queue bandwidth of other priority queues besides the target priority queue (determined based on traffic scenario data).

[0071] In summary, we can obtain scenario model parameters such as the fiber length corresponding to long-distance optical fiber, the device type of network equipment, the outgoing port rate of the target port, the number of incoming ports, and the queue level of the target priority queue. These scenario model parameters are used to identify the traffic scenario of the target port. Taking the fiber length corresponding to long-distance optical fiber, the device type of network equipment, the outgoing port rate of the target port, and the number of incoming ports as examples, we can form a parameter vector (DeviceType, PortSpeed, Incast, Dist) based on these parameters. This parameter vector serves as the basis for dividing the scenario model; different parameter vectors correspond to different scenario models. DeviceType represents the device type of the network equipment, PortSpeed ​​represents the outgoing port rate of the target port, Incast represents the number of incoming ports, and Dist represents the fiber length corresponding to long-distance optical fiber, which can be a positive integer multiple of 10km.

[0072] Step 404: For each traffic scenario parameter, the network device determines the corresponding ECN parameter and records the correspondence between the traffic scenario parameter and the ECN parameter in the mapping table B.

[0073] For each test environment, after obtaining the traffic scenario parameters corresponding to that test environment, the corresponding ECN parameter can be determined within that test environment. This allows for the selection of an appropriate ECN parameter for the traffic scenario (i.e., the traffic scenario within that test environment). There are no restrictions on the method of selecting this ECN parameter; the ECN parameter should ensure that the traffic of the target priority queue meets good performance indicators (i.e., data transmission performance indicators, such as the average bandwidth of the target priority queue and the round-trip delay of the target priority queue). In other words, under the traffic scenario corresponding to the traffic scenario parameters, the ECN parameter should ensure that the traffic of the target priority queue meets good performance indicators.

[0074] After obtaining the ECN parameter corresponding to the traffic scenario parameter, the correspondence between the traffic scenario parameter and the ECN parameter can be recorded in mapping table B. See Table 1 for an example of mapping table B.

[0075] Table 1

[0076] Traffic Scenario Parameters ECN parameters Traffic scenario parameter a1 ECN parameter b1 Traffic scenario parameter a2 ECN parameter b2 ... ...

[0077] Step 405: For each scenario model parameter, the network device determines the rate limiting policy corresponding to that scenario model parameter and records the correspondence between the scenario model parameter and the rate limiting policy in mapping table A.

[0078] For each test environment, after obtaining the scenario model parameters corresponding to that test environment, a rate limiting strategy corresponding to those scenario model parameters can be determined within that test environment. This allows for the selection of an appropriate rate limiting strategy for the traffic scenario (i.e., the traffic scenario within that test environment). There are no restrictions on the method of selecting this rate limiting strategy. The goal is to ensure that the traffic of the target priority queue meets good performance indicators (i.e., data transmission performance indicators, such as the average bandwidth of the target priority queue and the round-trip latency of the target priority queue). In other words, under the traffic scenario corresponding to the scenario model parameters, this rate limiting strategy should ensure that the traffic of the target priority queue meets good performance indicators.

[0079] For example, for each scene model parameter (i.e., the scene model parameter corresponding to each test environment), taking one scene model parameter as an example, step 405 can be implemented using the following steps:

[0080] Step 4051: Obtain multiple speed limiting strategies corresponding to the scene model parameters. For example, multiple speed limiting strategies can be pre-configured and used as the speed limiting strategies corresponding to the scene model parameters.

[0081] Step 4052: Enable the ECN parameter for the target port, i.e., the ECN parameter takes effect.

[0082] For example, when determining the rate limiting policy corresponding to the scenario model parameters of a certain test environment, the rate limiting policy is determined in the test environment. The ECN parameter corresponding to the traffic scenario parameters of the test environment is known, as can be seen in step 404. Therefore, this ECN parameter can be enabled for the target port.

[0083] For example, after enabling the ECN parameter for the target port, when sending specified type data (such as ROCE data) from the target priority queue corresponding to the target port, a congestion flag can be added to the specified type data based on the ECN parameter. The specified type data with the congestion flag is used to enable the destination device to send a CNP message to the source device. In other words, after receiving the specified type data with the congestion flag, the destination device can send a CNP message to the source device. Regarding the process of adding a congestion flag to the specified type data based on the ECN parameter, the ECN parameter can include, but is not limited to, the baseline, the high watermark, and the marking probability. Based on this, if the queue length of the target priority queue is greater than the baseline and not greater than the high watermark, a congestion flag can be added to the specified type data based on the marking probability; if the queue length of the target priority queue is greater than the high watermark, a congestion flag can be added to all specified type data in the target priority queue. Of course, the above is just an example of adding a congestion flag to specified type data; this embodiment does not limit the method of adding this congestion flag.

[0084] Step 4053: For each rate limiting policy, rate limit the CNP packets received by the target port based on the rate limiting policy, and calculate the data transmission performance of the target port after rate limiting.

[0085] For example, after enabling the ECN parameter for the target port, the network device can receive CNP packets (i.e., CNP packets sent by the destination device to the source device) through the target port. Therefore, the CNP packets received by the target port can be rate-limited based on a rate-limiting policy. This rate-limiting policy may include, but is not limited to, a rate-limiting value for CNP packets, where the rate-limiting value represents the number of bytes of CNP packets allowed to pass per second, or the rate-limiting value represents the number of CNP packets allowed to pass per second.

[0086] For example, after rate-limiting CNP packets received at a target port based on a rate-limiting policy, the network device can statistically analyze the data transmission performance of the target port after rate limiting. For instance, it can calculate the average bandwidth of the target priority queue and the round-trip latency for a specified data type within the target priority queue. Based on the average bandwidth and / or the round-trip latency, the data transmission performance of the target port after rate limiting can be determined. Specifically, the data transmission performance can be directly proportional to the average bandwidth of the queue and inversely proportional to the round-trip latency.

[0087] Among them, the average queue bandwidth can be a Throughput performance indicator. After rate limiting the CNP packets received by the target port, the average queue bandwidth corresponding to the target priority queue can be calculated.

[0088] Round-trip delay (RTD) can be used as a latency performance metric. After rate limiting the CNP packets received at the target port, the RTD corresponding to a specified type of data in the target priority queue can be calculated. For example, the sending time and receiving time of a specified type of data can be determined, i.e., the sending and receiving times of the same data. The sending time represents the time when the network device sends the specified type of data, and the receiving time represents the time when the network device receives the response data for the specified type of data. The difference between the receiving time and the sending time is used to determine the RTD.

[0089] After obtaining the average queue bandwidth and round-trip delay, the data transmission performance of the target port can be determined based on these parameters. For example, the average queue bandwidth and round-trip delay can be normalized to the same numerical level, and then a weighted calculation can be performed to obtain the data transmission performance. The weighting coefficient for the average queue bandwidth can be greater than, equal to, or less than the weighting coefficient for the round-trip delay. Of course, the above is just an example and is not a limitation.

[0090] When determining the data transmission performance of a target port based on average queue bandwidth and round-trip delay, data transmission performance is directly proportional to average queue bandwidth; that is, the larger the average queue bandwidth, the better the data transmission performance, and the smaller the average queue bandwidth, the worse the data transmission performance. Data transmission performance is inversely proportional to round-trip delay; that is, the larger the round-trip delay, the worse the data transmission performance, and the smaller the round-trip delay, the better the data transmission performance.

[0091] In summary, for each rate-limiting policy, after rate-limiting the CNP packets received by the target port based on that policy, the data transmission performance corresponding to that rate-limiting policy can be obtained.

[0092] Step 4054: Based on the data transmission performance corresponding to each rate limiting strategy, select the rate limiting strategy corresponding to the optimal data transmission performance (i.e., the maximum data transmission performance) from all rate limiting strategies.

[0093] Step 4055: Record the correspondence between scene model parameters and rate limiting strategies corresponding to optimal data transmission performance in mapping table A. For example, after obtaining the rate limiting strategy corresponding to the optimal data transmission performance, use this rate limiting strategy as the rate limiting strategy for matching scene model parameters, and record the correspondence between the scene model parameters and the rate limiting strategy in mapping table A. See Table 2 for an example of mapping table A.

[0094] Table 2

[0095] Scene model parameters Speed ​​limiting policy Scene model parameter c1 Speed ​​limiting policy d1 Scene model parameter c2 Speed ​​limiting policy d2 ... ...

[0096] Clearly, since the rate limiting strategy is the rate limiting strategy corresponding to the optimal data transmission performance, under the traffic scenario corresponding to the scenario model parameters, this rate limiting strategy can enable the traffic of the target priority queue to meet good performance indicators, such as good throughput performance indicators and latency performance indicators.

[0097] For example, since the rate limiting is applied to CNP packets received at the target port, the above rate limiting process can also be called sending a CNP-based CAR policy to the inbound direction of the target port. The CAR policy is a rate limiting policy, which limits the rate of CNP packets passing through the target port. This rate limiting can make the CNP packets sent by the destination device smoother, greatly improving the system's throughput performance.

[0098] Rate limiting policies can be rate limits for CNP packets, which can be pps, representing the number of bytes of CNP packets allowed to pass per second, or Bps, representing the number of CNP packets allowed to pass per second.

[0099] The testing process is now complete, and mapping table A and mapping table B are obtained. Mapping table A includes the correspondence between scenario model parameters and rate limiting policies, and mapping table B includes the correspondence between traffic scenario parameters and ECN parameters.

[0100] In one possible implementation, see Figure 5 The diagram shown is a flowchart of the application process.

[0101] Step 501: The network device obtains the traffic scenario data corresponding to the target port.

[0102] For example, the target port of the network device is connected to other devices via a long-distance optical fiber, the length of which exceeds a length threshold. The target port corresponds to multiple priority queues, and these priority queues include a target priority queue for carrying a specified type of data, which is ROCE data.

[0103] For example, during the actual operation of a network device, the network device can obtain traffic scenario data corresponding to the target port. For instance, the network device can periodically obtain traffic scenario data corresponding to the target port, and after obtaining the traffic scenario data each time, subsequent steps can be used to implement traffic rate limiting.

[0104] For details on how to obtain traffic scenario data, please refer to step 401. It will not be repeated here.

[0105] Step 502: The network device determines the target traffic scenario parameters based on the traffic scenario data corresponding to the target port. For example, after obtaining the traffic scenario data corresponding to the target port, the target traffic scenario parameters can be determined based on this data. The target traffic scenario parameters may include, but are not limited to, at least one of the following: the network device type, the outgoing port speed of the target port, the number of ingoing ports corresponding to a specified type of data in the target priority queue, and the queue level of the target priority queue. For instance, the target traffic scenario parameters are used to identify the traffic scenario of the target port. These parameters are grouped into a parameter vector (DeviceType, PortSpeed, Incast, Range), which serves as the basis for defining the scenario model.

[0106] Step 503: The network device determines the target scenario model parameters based on the traffic scenario data corresponding to the target port. For example, after obtaining the traffic scenario data corresponding to the target port, the target scenario model parameters can be determined based on this data. These parameters may include, but are not limited to, at least one of the following: the fiber length of the long-distance fiber (i.e., the long-distance fiber corresponding to the target port), the device type of the network device, the outgoing port rate of the target port, the number of incoming ports corresponding to a specified type of data in the target priority queue, and the queue level of the target priority queue. For instance, the scenario model parameters can be grouped into a parameter vector (DeviceType, PortSpeed, Incast, Dist), which serves as the basis for dividing the scenario model.

[0107] Step 504: The network device queries the target ECN parameter corresponding to the target traffic scenario parameter based on mapping table B. For example, since mapping table B includes the correspondence between traffic scenario parameters and ECN parameters (see Table 1), after obtaining the target traffic scenario parameter, the target ECN parameter corresponding to the target traffic scenario parameter can be obtained by querying mapping table B using the target traffic scenario parameter.

[0108] Step 505: Enable the target ECN parameter for the target port on the network device, that is, the target ECN parameter takes effect.

[0109] For example, after enabling the target ECN parameter for the target port, when the network device sends a specified type of data (such as ROCE data) in the target priority queue corresponding to the target port, it can add a congestion mark to the specified type of data based on the target ECN parameter. The specified type of data with the congestion mark is used to enable the destination device to send a CNP message to the source device. In other words, after receiving the specified type of data with the congestion mark, the destination device can send a CNP message to the source device.

[0110] Regarding the process of adding congestion markers to specified data types based on target ECN parameters, the target ECN parameters may include, but are not limited to, the target baseline, the target high watermark, and the target marking probability. Based on this, if the queue length of the target priority queue is greater than the target baseline and not greater than the target high watermark, then congestion markers can be added to the specified data types based on the target marking probability; if the queue length of the target priority queue is greater than the target high watermark, then congestion markers can be added to all specified data types in the target priority queue. Of course, the above is only an example of adding congestion markers to specified data types, and this embodiment does not limit the method of adding these congestion markers.

[0111] Step 506: The network device queries the target rate limiting policy corresponding to the target scenario model parameters based on mapping table A. For example, since mapping table A includes the correspondence between scenario model parameters and rate limiting policies, and this rate limiting policy is used to ensure the target port has optimal data transmission performance under the scenario model parameters (see Table 2), after obtaining the target scenario model parameters, mapping table A can be queried using the target scenario model parameters to obtain the target rate limiting policy corresponding to the target scenario model parameters.

[0112] Step 507: The network device limits the rate of CNP packets received at the target port based on the target rate limiting policy. The CNP packets are used to control the source device to reduce the sending rate of specified data types.

[0113] For example, after enabling the target ECN parameter for the target port, the network device can receive CNP packets (i.e., CNP packets sent by the destination device to the source device) through the target port. Therefore, the CNP packets received by the target port can be rate-limited based on the target rate-limiting policy. The target rate-limiting policy may include, but is not limited to, a rate-limiting value for CNP packets, where the rate-limiting value represents the number of bytes of CNP packets allowed to pass per second, or the rate-limiting value represents the number of CNP packets allowed to pass per second.

[0114] In summary, this embodiment demonstrates that by recognizing changes in the scenario, the ECN parameters and rate limiting policies (Car parameters) can be dynamically adjusted. In other words, the network device can periodically acquire traffic scenario data corresponding to the target port. After each acquisition of traffic scenario data, the ECN parameters and rate limiting policies can be dynamically adjusted, thereby enabling the traffic of the target priority queue of the target port to achieve good performance indicators.

[0115] For example, during the operation of network devices, traffic scenario data is continuously collected. Based on this data, changes in the traffic scenario are identified, and appropriate ECN parameters and rate limiting policies are selected and sent to the network devices. In this way, changes in traffic scenarios can be intelligently detected and identified, and the impact of long-distance fiber optic cables can be minimized by adjusting ECN parameters and rate limiting policies.

[0116] As can be seen from the above technical solutions, in the embodiments of this application, in long-distance fiber optic scenarios, the rate limiting of CNP packets received by the target port can be implemented, thereby preventing the source device from receiving a large number of CNP packets in a short period of time. This results in a more balanced and smoother distribution of CNP packets received by the source device, making the rate reduction process (i.e., the process of reducing the data transmission rate) of the source device smoother. It avoids the source device experiencing a large rate reduction for a period of time followed by a small or no rate reduction for another period. This leads to better data transmission performance of the network device, preventing network congestion caused by receiving a large amount of data in one period and insufficient bandwidth utilization caused by receiving a small amount of data in another. Furthermore, the rate limiting of CNP packets received by the target port can be based on the target rate limiting strategy corresponding to the target scenario model parameters (i.e., actual scenario model parameters) of the network device. The target rate limiting strategy matches the actual scenario of the network device, resulting in better rate limiting effect. The target scenario model parameters at least include the fiber length corresponding to the long-distance fiber, making the target rate limiting strategy related to the fiber length. This means finding the target rate limiting strategy that best matches the fiber length further improves the forwarding performance of the target port, allowing the network device to achieve optimal data transmission performance. This embodiment proposes a scheme to optimize the forwarding performance of long-distance ports through a rate-limiting strategy. A CNP-based rate-limiting strategy is issued on the inbound direction of the long-distance port (i.e., the target port) to rate-limit CNP packets passing through the target port. This rate limiting smooths out the CNP packets sent by the destination device, improving the system's throughput performance. By combining ECN parameters with the rate-limiting strategy, the impact of long-distance ports is minimized, while ensuring that the traffic of the target priority queue on the target port achieves good performance indicators. This approach is adaptable to various network scenarios and effectively solves the problem of reduced forwarding performance caused by network latency in long-distance fiber optic data center scenarios.

[0117] Based on the same concept as the above method, this application proposes a traffic limiting device for use in a network device. The network device includes a target port, which is connected to other devices via a long-distance optical fiber. (See [link]). Figure 6 The diagram shown is a structural schematic of the device, which includes:

[0118] The determining module 61 is used to determine target scenario model parameters based on the traffic scenario data corresponding to the target port; wherein, the target scenario model parameters include at least the fiber length corresponding to the long-distance optical fiber;

[0119] The acquisition module 62 is used to query the target rate limiting strategy corresponding to the target scene model parameters based on the mapping table; wherein, the mapping table includes the correspondence between scene model parameters and rate limiting strategies, and the rate limiting strategy is used to enable the target port to have the optimal data transmission performance under the scene model parameters;

[0120] Processing module 63 is used to rate limit the CNP packets received by the target port based on the target rate limiting policy, wherein the CNP packets are used to control the source device to reduce the transmission rate of specified data types.

[0121] For example, the acquisition module 62 is further configured to determine scenario model parameters based on the traffic scenario data corresponding to the target port in the test environment, and acquire multiple rate limiting strategies corresponding to the scenario model parameters; for each rate limiting strategy, the CNP packets received by the target port can be rate-limited based on the rate limiting strategy, and the data transmission performance of the target port after rate limiting can be statistically analyzed; based on the data transmission performance corresponding to each rate limiting strategy, the correspondence between the scenario model parameters and the rate limiting strategy corresponding to the optimal data transmission performance is recorded in the mapping table.

[0122] For example, the target port may correspond to multiple priority queues, and the multiple priority queues include a target priority queue for carrying a specified type of data; when the acquisition module 62 calculates the data transmission performance of the target port after rate limiting, it is specifically used to: calculate the average bandwidth of the queue corresponding to the target priority queue, and calculate the round-trip delay corresponding to the specified type of data in the target priority queue; based on the average bandwidth of the queue and / or the round-trip delay, determine the data transmission performance of the target port after rate limiting; wherein, the data transmission performance may be directly proportional to the average bandwidth of the queue, and the data transmission performance may be inversely proportional to the round-trip delay.

[0123] For example, the target scenario model parameters may also include at least one of the following: the device type of the network device, the outgoing port rate of the target port, the number of incoming ports corresponding to the specified type of data in the target priority queue, and the queue level of the target priority queue.

[0124] For example, the queue level is determined based on the average queue bandwidth of the target priority queue and the average queue bandwidth of other priority queues besides the target priority queue.

[0125] For example, the acquisition module 62 is further configured to acquire the ECN parameter corresponding to the target port; the processing module 63 is further configured to add a congestion flag to the specified type data based on the target ECN parameter when sending the specified type data in the target priority queue corresponding to the target port; the specified type data with the congestion flag is used to enable the destination device to send the CNP message to the source device.

[0126] For example, the target ECN parameters include the target base waterline, the target high waterline, and the target label probability. When the processing module 63 adds congestion labels to the specified type of data based on the target ECN parameters, it specifically performs the following: if the queue length of the target priority queue is greater than the target base waterline but not greater than the target high waterline, it adds congestion labels to the specified type of data based on the target label probability; if the queue length is greater than the target high waterline, it adds congestion labels to all specified type of data in the target priority queue.

[0127] For example, the target rate limiting policy includes a rate limiting value for CNP packets, which represents the number of bytes of CNP packets allowed to pass per second, or the rate limiting value represents the number of CNP packets allowed to pass per second; the specified data type includes ROCE data.

[0128] Based on the same application concept as the above method, this application proposes a network device, see [link to application]. Figure 7 As shown, the network device includes a processor 71 and a machine-readable storage medium 72, the machine-readable storage medium 72 storing machine-executable instructions that can be executed by the processor 71; the processor 71 is used to execute the machine-executable instructions to implement the traffic rate limiting method disclosed in the above example of this application.

[0129] Based on the same concept as the above method, this application also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the traffic limiting method disclosed in the above examples of this application.

[0130] The aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0131] The systems, devices, modules, or units described in the above embodiments can be implemented by a computer entity or by a product with a certain function. A typical implementation device is a computer, which can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0132] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0133] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0134] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0135] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0136] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0137] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method of flow rate throttling, characterized by, The method is applied to a network device, the network device comprises a target port, the target port is connected with other devices through a long-distance optical fiber, and the method comprises the following steps: determining a target scene model parameter based on traffic scene data corresponding to the target port; wherein the target scene model parameter at least comprises an optical fiber length corresponding to the long-distance optical fiber; querying a target rate limiting strategy corresponding to the target scene model parameter based on a mapping table; limiting a congestion notification data packet (CNP) message received by the target port based on the target rate limiting strategy, wherein the CNP message is used to control a source device to reduce the sending rate of specified type data; wherein the mapping table comprises a corresponding relationship between a scene model parameter and a rate limiting strategy, and the rate limiting strategy is used to make the target port have optimal data transmission performance under the scene model parameter; wherein before the step of querying a target rate limiting strategy corresponding to the target scene model parameter based on a mapping table, the method further comprises the following steps: determining a scene model parameter based on traffic scene data corresponding to the target port in a test environment, and obtaining a plurality of rate limiting strategies corresponding to the scene model parameter; for each rate limiting strategy, limiting a CNP message received by the target port based on the rate limiting strategy, and counting data transmission performance corresponding to the target port after rate limiting; based on the data transmission performance corresponding to each rate limiting strategy, recording the corresponding relationship between the scene model parameter and the rate limiting strategy corresponding to the optimal data transmission performance in the mapping table; and determining a traffic scene parameter corresponding to the test environment based on traffic scene data corresponding to the target port, determining an ECN parameter corresponding to the traffic scene parameter, enabling the ECN parameter for the target port, and adding a congestion mark in specified type data based on the ECN parameter when sending the specified type data corresponding to the target port, wherein the specified type data with the congestion mark is used to make a destination device send a CNP message to a source device.

2. The method of claim 1, wherein, The target port corresponds to a plurality of priority queues, and the plurality of priority queues comprise a target priority queue used to carry specified type data; The step of counting data transmission performance corresponding to the target port after rate limiting comprises the following steps: counting a queue average bandwidth corresponding to the target priority queue, counting a round-trip delay corresponding to the specified type data in the target priority queue, and determining data transmission performance corresponding to the target port after rate limiting based on the queue average bandwidth and / or the round-trip delay; wherein the data transmission performance is proportional to the queue average bandwidth, and the data transmission performance is inversely proportional to the round-trip delay.

3. The method of claim 1, wherein the target port corresponds to a plurality of priority queues, and the plurality of priority queues comprise a target priority queue used to carry specified type data, and the target scene model parameter further comprises at least one of the following: a device type of the network device, an out-port rate of the target port, a number of in-ports corresponding to the specified type data in the target priority queue, and a queue level of the target priority queue. The queue level is determined based on a queue average bandwidth of the target priority queue and a queue average bandwidth of other priority queues except the target priority queue.

4. The method according to any of claims 1 to 3, characterized in that, The method further includes: obtaining a target Explicit Congestion Notification (ECN) parameter corresponding to the target port; when sending data of a specified type in the target priority queue corresponding to the target port, adding a congestion mark in the data of the specified type based on the target ECN parameter; wherein the data of the specified type with the congestion mark is used to make a destination device send the CNP packet to the source device.

5. The method of claim 4, wherein the target ECN parameter includes a target base waterline, a target high waterline, and a target marking probability, and the adding of the congestion mark in the data of the specified type based on the target ECN parameter includes: if the queue length of the target priority queue is greater than the target base waterline and not greater than the target high waterline, adding the congestion mark in the data of the specified type based on the target marking probability; if the queue length of the target priority queue is greater than the target high waterline, adding the congestion mark in all data of the specified type in the target priority queue.

6. The method according to any one of claims 1 to 3, characterized in that, the target rate limiting strategy includes a rate limiting value for the CNP packet, and the rate limiting value represents a number of bytes of the CNP packet allowed to pass per second, or the rate limiting value represents a number of CNP packets allowed to pass per second; the data of the specified type is Remote Direct Memory Access (RDMA) over Converged Ethernet (ROCE) data.

7. A flow rate limiting device, characterized by, The device is applied to a network device, and the network device includes a target port connected to other devices through a long-distance optical fiber. A determining module is configured to determine a target scene model parameter based on traffic scene data corresponding to the target port, wherein the target scene model parameter at least includes an optical fiber length corresponding to the long-distance optical fiber. A obtaining module is configured to query a target rate limiting strategy corresponding to the target scene model parameter based on a mapping table, wherein the mapping table includes a corresponding relationship between scene model parameters and rate limiting strategies, and the rate limiting strategy is used to make the target port have optimal data transmission performance under the scene model parameter. A processing module is configured to limit a CNP packet received by the target port based on the target rate limiting strategy, and the CNP packet is used to control a source device to reduce a sending rate of data of a specified type. The obtaining module is further configured to determine a scenario model parameter based on the traffic scenario data corresponding to the target port in the test environment, and obtain a plurality of rate limiting strategies corresponding to the scenario model parameter; for each rate limiting strategy, limit the CNP packet received by the target port based on the rate limiting strategy, and count the data transmission performance corresponding to the target port after rate limiting; record the corresponding relationship between the scenario model parameter and the rate limiting strategy corresponding to the optimal data transmission performance in the mapping table based on the data transmission performance corresponding to each rate limiting strategy; determine the traffic scenario parameter corresponding to the test environment based on the traffic scenario data corresponding to the target port, and determine the ECN parameter corresponding to the traffic scenario parameter; enable the ECN parameter for the target port, and add a congestion mark in the specified type data based on the ECN parameter when sending the specified type data corresponding to the target port, and the specified type data with the congestion mark is used to make the destination device send the CNP packet to the source device.

8. The apparatus of claim 7, It is characterized in that, wherein, The target port corresponds to a plurality of priority queues, and the plurality of priority queues include a target priority queue used to carry the specified type data; when the obtaining module counts the data transmission performance corresponding to the target port after rate limiting, it is specifically configured to count the queue average bandwidth corresponding to the target priority queue, and count the round-trip delay corresponding to the specified type data in the target priority queue; determine the data transmission performance corresponding to the target port after rate limiting based on the queue average bandwidth and / or the round-trip delay; wherein the data transmission performance is proportional to the queue average bandwidth, and the data transmission performance is inversely proportional to the round-trip delay; wherein the target scenario model parameter further includes at least one of the following: a device type of the network device, an out-port rate of the target port, an in-port number corresponding to the specified type data in the target priority queue, and a queue level of the target priority queue; wherein the queue level is determined based on the queue average bandwidth of the target priority queue and the queue average bandwidth of other priority queues except the target priority queue; The obtaining module is further configured to obtain a target ECN parameter corresponding to the target port; and the processing module is further configured to add a congestion mark in the specified type data based on the target ECN parameter when sending the specified type data in the target priority queue corresponding to the target port; the specified type data with the congestion mark is used to make the destination device send the CNP packet to the source device; The target ECN parameter includes a target base water line, a target high water line and a target marking probability. The processing module is configured to: if the queue length of the target priority queue is greater than the target base water line and not greater than the target high water line, add a congestion mark in the specified type of data based on the target marking probability; if the queue length is greater than the target high water line, add a congestion mark in all specified types of data in the target priority queue. The target rate limiting strategy includes a rate limiting value for CNP packets. The rate limiting value represents the number of bytes of CNP packets allowed to pass per second, or the rate limiting value represents the number of CNP packets allowed to pass per second. The specified type of data includes ROCE data.

9. A network device, comprising: The method comprises: a processor and a machine readable storage medium, the machine readable storage medium storing machine executable instructions executable by the processor; the processor is configured to execute the machine executable instructions to implement the method of any one of claims 1-6.

Images