Method for sending congestion notification message, and related apparatus

Abstract

The present application belongs to the technical field of networks. Disclosed are a method for sending a congestion notification message, and a related apparatus. The method comprises: a destination node generating a first congestion notification message, wherein the first congestion notification message carries a second congestion notification message; the destination node sending the first congestion notification message to a source node; the source node receiving the first congestion notification message from the destination node, wherein the first congestion notification message carries the second congestion notification message; and the source node sending the second congestion notification message to a sending end of a first data stream, wherein the second congestion notification message is used for instructing the sending end to control subsequent traffic of the first data stream. The present application can accurately control the subsequent traffic of a congested data stream without affecting the other traffic of a shared forwarding node, and can also improve the efficiency of sending a congestion notification message.

Description

Methods and related devices for sending congestion notification messages

[0001] This application claims priority to Chinese Patent Application No. 202410942608.X, filed on July 12, 2024, entitled “Method and Apparatus for Sending Congestion Notification Messages”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of network technology, and in particular to a method and related apparatus for sending congestion notification messages. Background Technology

[0003] As artificial intelligence (AI) models continue to grow in scale, a single graphics processing unit (GPU) or a single server can no longer meet the computational demands. Therefore, distributed parallel computing has been proposed, which distributes computational tasks across multiple servers in parallel to accelerate model computation. However, during distributed parallel computing, traffic congestion often occurs between these servers. Therefore, how to send congestion notification messages has become a pressing issue. Summary of the Invention

[0004] This application provides a method and related apparatus for sending congestion notification messages, which can accurately control the subsequent traffic of a congested data stream without affecting other traffic sharing the forwarding node, and can also improve the sending efficiency of congestion notification messages. The technical solution is as follows:

[0005] In a first aspect, a method for sending a congestion notification message is provided, the method comprising: a source node receiving a first congestion notification message from a destination node, the first congestion notification message carrying a second congestion notification message; the source node sending the second congestion notification message to a sender of a first data stream, the second congestion notification message being used to instruct the sender to control subsequent traffic of the first data stream.

[0006] The source node learns of congestion at the destination node by receiving a first congestion notification message from the destination node, rather than through hop-by-hop flow control mechanisms between the destination and source nodes. This prevents the congestion notification from spreading to other data streams, allowing for precise control of subsequent traffic from the first data stream without affecting other traffic sharing the same forwarding nodes. Furthermore, the first congestion notification message includes a second congestion notification message, which is then forwarded to the source node via intermediate forwarding nodes. This avoids waiting for these intermediate nodes to buffer messages, detect congestion, and generate hop-by-hop flow control messages. Upon receiving the first congestion notification message, the source node can directly extract the second congestion notification message without constructing it, enabling faster feedback of congestion to the sender of the first data stream and improving the efficiency of congestion notification message transmission.

[0007] In one possible implementation, the method further includes: the source node decapsulating the first congestion announcement message to obtain the second congestion announcement message. That is, the second congestion announcement message is completely encapsulated within the first congestion announcement message.

[0008] In one possible implementation, the second congestion notification message is carried in the payload of the first congestion notification message; the source node decapsulates the first congestion notification message to obtain the second congestion notification message, including: the source node strips the header of the first congestion notification message to obtain the second congestion notification message.

[0009] The second congestion announcement message is fully encapsulated in the payload of the first congestion announcement message. In this way, after the source node receives the first congestion announcement message, it can directly obtain the second congestion announcement message by stripping the header of the first congestion announcement message, without having to reconstruct the second congestion announcement message. This allows the sender of the first data stream to know about the congestion of the first data stream more quickly, thereby controlling the subsequent traffic of the first data stream more quickly and improving the speed of congestion relief.

[0010] In some other embodiments, the second congestion notification message may also be carried in other locations besides the payload in the first congestion notification message, and this application does not limit this.

[0011] In one possible implementation, the first congestion announcement message also carries a flag bit. Thus, after the source node receives the first congestion announcement message, if it determines that the flag bit is a specific value, it performs the step of decapsulating the first congestion announcement message to obtain the second congestion announcement message.

[0012] For example, the first congestion notification message includes a UDP header, and the flag bit is the port number in the UDP header. If the port number in the UDP header is a specific port number, then the step of decapsulating the first congestion notification message to obtain the second congestion notification message is performed. Alternatively, the first congestion notification message includes a TCP header, and the flag bit is the port number in the TCP header. If the port number in the TCP header is a specific port number, then the step of decapsulating the first congestion notification message to obtain the second congestion notification message is performed. Alternatively, the first congestion notification message includes other types of Layer 4 network protocol headers, and the flag bit is a reserved bit in that Layer 4 network protocol header. If the reserved bit in that Layer 4 network protocol header is a specific value, then the step of decapsulating the first congestion notification message to obtain the second congestion notification message is performed.

[0013] In one possible implementation, the second congestion notification message is a flow control message. For example, the second congestion notification message is a hop-by-hop flow control message.

[0014] In one possible implementation, the second congestion notification message used to instruct the sender to control subsequent traffic of the first data stream includes: the second congestion notification message used to instruct the sender to suspend sending subsequent traffic of the first data stream.

[0015] If the sending end suspends the transmission of subsequent traffic of the first data stream, the congestion of the first data stream can be alleviated relatively quickly.

[0016] In one possible implementation, the flow control message includes a priority-based flow control (PFC) message, which carries a pause duration. This pause duration indicates the duration for which the sender suspends sending subsequent traffic of the first data stream. In other words, the sender can stop sending subsequent traffic of the first data stream during this pause duration and resume sending subsequent traffic of the first data stream after the pause duration.

[0017] In one possible implementation, the flow control message includes a credit-based flow control message (referred to as a credit message), which carries an available credit limit, and the available credit limit is 0.

[0018] The available credit limit refers to the amount of data that the destination node can receive. When the available credit limit is 0, it indicates that the destination node is currently unable to receive data, and the sender can stop sending subsequent traffic of the first data stream.

[0019] In one possible implementation, the second congestion notification message instructing the sender to control subsequent traffic of the first data stream includes: the second congestion notification message instructing the sender to send subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

[0020] In one possible implementation, the flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

[0021] Based on the above description, the available credit limit refers to the amount of data the destination node can receive. Therefore, when the available credit limit is greater than 0, it indicates that subsequent traffic of the first data stream will not be stopped, but rather sent according to the amount of data the destination node can receive. This is equivalent to reducing the sending rate of subsequent traffic of the first data stream. Thus, while alleviating congestion of the first data stream, it also ensures that the services corresponding to the first data stream can continue.

[0022] Based on the above description, the ports of a forwarding node comprise multiple port queues, each corresponding to a priority. The port queues used for forwarding the first data stream at each forwarding node along the forwarding path can be the same or different. When the port queues used for forwarding the first data stream are the same across all forwarding nodes, the source node can directly instruct the sender of the first data stream to control the packets in the corresponding port queue, thereby controlling the subsequent traffic of the first data stream. When the port queues used for forwarding the first data stream are different across all forwarding nodes, the first congestion-passing packet can also carry priority indication information, such as a differentiated services code point (DSCP). This priority indication information indicates the priority of the port queue in which the packets of the first data stream reside. Thus, the source node can determine the port queue used for forwarding the first data stream within the source node based on this priority indication information, and then instruct the sender of the first data stream to control the packets in the corresponding port queue, thereby controlling the subsequent traffic of the first data stream.

[0023] In one possible implementation, the source node is configured with a local flow control mechanism, such as a local hop-by-hop flow control mechanism. However, the mechanism used in this embodiment to send the second congestion notification message via the first congestion notification message is another flow control mechanism. When the second congestion notification message is a PFC message, because the PFC message carries a pause duration, the sender of the first data stream can pause sending subsequent traffic of the first data stream according to this pause duration. Thus, the source node is unlikely to continue receiving subsequent traffic of the first data stream, and the local flow control mechanism in the source node will not be triggered. However, when the second congestion notification message is a credit message, since the available credit limit is used to indicate the amount of data the destination node can receive, if the second congestion notification message indicates that the sender of the first data stream needs to pause sending subsequent traffic of the first data stream or reduce the sending rate of subsequent traffic of the first data stream, and the source node's local flow control mechanism indicates that the downstream device can still receive a certain amount of data, then the sender of the first data stream will still continue sending subsequent traffic of the first data stream, thus rendering the second congestion notification message ineffective. Therefore, the source node also needs to control the flow control mechanism of the port to which the sending end is connected to, so that it fails within the target duration. This flow control mechanism is a local flow control mechanism for that port.

[0024] For example, the mechanism of sending a second congestion notice message via a first congestion notice message is called a remote flow control mechanism. The source node also has a hop-by-hop flow control mechanism configured locally. For a credit message, if the available credit limit carried by the second congestion notice message is 0, it indicates that the remote flow control mechanism instructs the sender to suspend sending subsequent traffic of the first data stream. However, the source node's hop-by-hop flow control mechanism indicates that downstream devices can still receive a certain amount of data. Therefore, the sender of the first data stream will continue to send subsequent traffic of the first data stream, rather than suspending it, thus rendering the second congestion notice message ineffective. Therefore, the source node also needs to control the hop-by-hop flow control mechanism of the port connected to the sender of the first data stream to become ineffective within the target duration.

[0025] In one possible implementation, the outgoing port used to forward the first data stream may also simultaneously forward a second data stream, and the source node of the second data stream is the same as the source node of the first data stream. In this case, the first congestion notification message also carries a third congestion notification message. In this scenario, the source node, in addition to sending the second congestion notification message to the sender of the first data stream, also sends the third congestion notification message to the sender of the second data stream. The third congestion notification message is used to instruct the sender of the second data stream to control the subsequent traffic of the second data stream.

[0026] Secondly, a method for sending a congestion notification message is provided, the method comprising: a destination node generating a first congestion notification message, the first congestion notification message carrying a second congestion notification message; the destination node sending the first congestion notification message to a source node, thereby causing the source node to send the second congestion notification message to a sender of a first data stream, the second congestion notification message being used to instruct the sender to control the subsequent traffic of the first data stream.

[0027] The destination node generates a first congestion notice (CHF) message, which carries a second CHF message. This first CHF message is then forwarded to the source node of the first data stream via intermediate forwarding nodes. The source node then forwards the second CHF message carried by the first CHF message to the sender of the first data stream. The sender of the first data stream directly controls the subsequent traffic of the first data stream. Instead of the destination node forwarding the second CHF message to directly connected upstream forwarding nodes, which buffer the data stream's packets and, if congestion occurs, regenerate hop-by-hop flow control messages and feed them back upstream until the sender of the first data stream. In this way, the congestion notice of the first data stream does not propagate to the paths of other data streams, allowing for precise control of the subsequent traffic of the first data stream without affecting other traffic sharing the forwarding nodes. Furthermore, by including a second congestion notification message in the first congestion notification message, the first congestion notification message is forwarded to the source node through intermediate forwarding nodes. This avoids the time spent waiting for intermediate forwarding nodes to perform message caching, handle congestion, and generate hop-by-hop flow control messages. Moreover, after receiving the first congestion notification message, the source node can directly extract the second congestion notification message from it without constructing it. This allows for faster feedback of congestion to the sender of the first data stream, thereby improving the transmission efficiency of the congestion notification message.

[0028] In one possible implementation, the method further includes: the destination node generating a second congestion notification message, and encapsulating the second congestion notification message to obtain the first congestion notification message. That is, the first congestion notification message carrying the second congestion notification message means that the second congestion notification message is completely encapsulated within the first congestion notification message.

[0029] The destination node is a forwarding node used to connect to the receiving end of the first data stream. The first congestion notice message is generated when congestion occurs at the outgoing port of the destination node used to forward the first data stream.

[0030] In one possible implementation, congestion at the egress port used to forward the first data stream includes: the queue depth of the egress port being greater than or equal to a first depth threshold. That is, the queue depth of the egress port, i.e., the amount of data in all packets buffered in the port queue of the egress port, is detected; if the queue depth of the egress port is greater than or equal to the first depth threshold, then the egress port is determined to be congested.

[0031] The first depth threshold is triggered earlier than the second depth threshold, which is the queue depth at the ingress port of the destination node used to forward the first data stream, triggering the flow control mechanism. That is, a first congestion notice message is sent before the flow control mechanism is triggered at the ingress port. This ensures that the second congestion notice message arrives at the sender of the first data stream before the flow control mechanism at the ingress port, allowing the sender to control subsequent traffic of the first data stream before the ingress port's flow control mechanism, thus preventing the flow control mechanism's messages from spreading across various paths and affecting other traffic.

[0032] Congestion at the outgoing port can be understood as congestion in the port queue of that outgoing port, or congestion at the destination node. Congestion at the outgoing port can occur when there is multi-call traffic within the destination node. Of course, it can also occur under other circumstances; this application does not limit the causes of congestion.

[0033] In another possible implementation, congestion at the egress port used to forward the first data stream includes: the port queue of the egress port being backpressured by the flow control mechanism. That is, the flow control status of the egress port queue is detected, which indicates whether the egress port queue is being backpressured by the flow control mechanism, i.e., whether the egress port queue is receiving a flow control signal. If the flow control status of the egress port queue indicates that the egress port queue is being backpressured by the flow control mechanism, then it is determined that the egress port is congested.

[0034] When the outgoing port queue is back-pressed by the flow control mechanism, the first congestion notification message is sent. In this way, after the second congestion notification message arrives at the sender of the first data stream, the sender can control the subsequent traffic of the first data stream, thereby keeping the flow control mechanism within the destination node and preventing it from spreading to other nodes and affecting other traffic.

[0035] Congestion at the output port can be understood as congestion in the port queue of the output port, or congestion at the destination node. Congestion at the output port can occur when the receiving end of the first data stream is congested, but it can also occur under other circumstances. This application does not limit the cause of congestion.

[0036] Based on the above description, a forwarding node has multiple ports. The port used to receive packets on the forwarding node is the ingress port, and the port used to send packets is the egress port. The first congestion notification message is generated by determining whether the egress port used to forward the first data stream is congested. Since the first congestion notification message carries a second congestion notification message, it can also be understood that the second congestion notification message is generated when the egress port used to forward the first data stream is congested. However, the ingress port is not a port directly connected to the receiving end, and packets received by the ingress port may correspond to different egress ports. Therefore, compared to triggering flow control mechanisms based on whether the ingress port is congested, determining whether the egress port is congested can clearly identify the specific data stream experiencing congestion, thus providing a guarantee for precise control of subsequent traffic from the congested data stream.

[0037] In one possible implementation, where the egress port used for forwarding the first data stream includes multiple port queues, in the two implementations described above, congestion at the egress port used for forwarding the first data stream refers to congestion in the port queue containing the first data stream at the egress port used for forwarding the first data stream in the destination node. That is, the first congestion notification message is generated when the port queue containing the first data stream at the egress port used for forwarding the first data stream in the destination node experiences congestion. In this case, in the embodiments of this application, the port queue used for forwarding the first data stream refers to the egress port queue containing the first data stream at the egress port used for forwarding the first data stream.

[0038] In some cases, the egress port used to forward the first data stream may also forward other data streams simultaneously. Therefore, if congestion occurs at this egress port, a congestion notice can be sent not only to the sender of the first data stream but also to the senders of other data streams. In this case, a first congestion notice message can be generated for each data stream forwarded through this egress port. Of course, in some other embodiments, a first congestion notice message can also be generated for at least two data streams.

[0039] As an example, the outgoing port used to forward the first data stream may also simultaneously forward a second data stream, and the source node of the second data stream is the same as the source node of the first data stream; that is, the sender of the first data stream and the sender of the second data stream are connected to the same forwarding node. In this way, the first congestion announcement message also carries a third congestion announcement message, which is used to instruct the sender of the second data stream to control the subsequent traffic of the second data stream. That is, the destination node not only generates the second congestion announcement message but also the third congestion announcement message, and encapsulates the second and third congestion announcement messages to obtain the first congestion announcement message.

[0040] In one possible implementation, the second congestion notification message is a flow control message. For example, the second congestion notification message is a hop-by-hop flow control message.

[0041] In one possible implementation, the second congestion notification message used to instruct the sender to control subsequent traffic of the first data stream includes: the second congestion notification message used to instruct the sender to suspend sending subsequent traffic of the first data stream.

[0042] In one possible implementation, the flow control message includes a priority-based flow control (PFC) message, the PFC message carrying a pause duration, the pause duration being used to indicate the duration for which the sender pauses sending subsequent traffic of the first data stream.

[0043] In one possible implementation, the flow control message includes a credit-based flow control message, which carries an available credit limit, and the available credit limit is 0.

[0044] In one possible implementation, the second congestion notification message instructing the sender to control subsequent traffic of the first data stream includes: the second congestion notification message instructing the sender to send subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

[0045] In one possible implementation, the flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

[0046] Thirdly, a congestion notification message sending system is provided, the system including a source node, a destination node and a sender;

[0047] The source node is used to implement the steps of the method described in the first aspect above;

[0048] The target node is used to implement the steps of the method described in the second aspect above;

[0049] The sending end is used to receive the second congestion notification message sent by the source node, and control the subsequent traffic of the first data stream based on the second congestion notification message.

[0050] Fourthly, a congestion notification message sending apparatus is provided, the apparatus having the function of implementing the method behavior described in the first aspect. The congestion notification message sending apparatus includes at least one module for implementing the method provided in the first aspect. Alternatively, the congestion notification message sending apparatus has the function of implementing the method behavior described in the second aspect. The congestion notification message sending apparatus includes at least one module for implementing the method provided in the second aspect.

[0051] Fifthly, a forwarding node is provided, the forwarding node including a processor and a memory, the memory being used to store a computer program for performing the method provided in the first aspect. The processor is configured to execute the computer program stored in the memory to implement the method described in the first aspect. Alternatively, the memory is used to store a computer program for performing the method provided in the second aspect. The processor is configured to execute the computer program stored in the memory to implement the method described in the second aspect.

[0052] Optionally, the source node may further include a communication bus for establishing a connection between the processor and the memory.

[0053] In a sixth aspect, a chip is provided, the chip including programmable logic circuitry and / or program instructions, which, when running, implements the method for sending congestion notification messages as described in the first aspect or provided in the first aspect.

[0054] In a seventh aspect, a computer-readable storage medium is provided, the storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in the first or second aspect.

[0055] Eighthly, a computer program product comprising instructions is provided, which, when executed on a computer, cause the computer to perform the method described in the first or second aspect above.

[0056] The technical effects achieved by the second aspect are similar to those achieved by the corresponding technical means in the first aspect, and the technical effects achieved by the third to eighth aspects are similar to those achieved by the corresponding technical means in the first or second aspect, which will not be elaborated here. Attached Figure Description

[0057] Figure 1 is a schematic diagram of a flow-by-flow forwarding path provided in an embodiment of this application;

[0058] Figure 2 is a schematic diagram of a packet-by-packet forwarding path provided in an embodiment of this application;

[0059] Figure 3 is a schematic diagram of the correspondence of port queues provided in an embodiment of this application;

[0060] Figure 4 is a schematic diagram of a hop-by-hop flow control mechanism provided in an embodiment of this application;

[0061] Figure 5 is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0062] Figure 6 is a flowchart illustrating a method for sending a congestion notification message according to an embodiment of this application;

[0063] Figure 7 is a schematic diagram of the structure of a PFC message provided in an embodiment of this application;

[0064] Figure 8 is a schematic diagram of the structure of a credit message provided in an embodiment of this application;

[0065] Figure 9 is a schematic diagram of the structure of a congestion notification message sending device provided in an embodiment of this application;

[0066] Figure 10 is a schematic diagram of the structure of a congestion notification message sending device provided in an embodiment of this application;

[0067] Figure 11 is a schematic diagram of the structure of a forwarding node provided in an embodiment of this application. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0069] Before providing a detailed explanation of the method for sending congestion notification messages provided in the embodiments of this application, the terms, application scenarios, and implementation environments involved in the embodiments of this application will be introduced first.

[0070] First, the terms used in the embodiments of this application will be introduced.

[0071] 1. AI Traffic Characteristics

[0072] To meet the computational demands of large-scale AI models, computational tasks are typically distributed across multiple servers in parallel (i.e., distributed parallel computing) to accelerate model training. These servers interact via a communication network. Ignoring the architecture of this network, the logical topology between the servers can be based on rings, trees, or similar structures. Ring-based topologies involve point-to-point communication at any given time, generating one-to-one traffic, with no many-to-one traffic. Furthermore, point-to-point communication usually involves only one or a few data streams, resulting in a small number of streams and a large bandwidth for each individual stream. Tree-based topologies can experience momentary 3-to-1 traffic. Additionally, many-to-many communication may also occur between these servers, generating momentary N-to-1 traffic.

[0073] 2. Load balancing mechanism

[0074] In AI model computation tasks, there are usually multiple equivalent paths between two servers, and traffic between these servers can be distributed across these multiple equivalent paths. The selection of equivalent paths is divided into two forwarding methods: flow-by-flow forwarding and packet-by-packet forwarding.

[0075] Flow-by-flow forwarding forwards the same data stream along the same path. The load balancing effect of flow-by-flow forwarding depends on the number of data streams in the network. When the number of data streams is small and the bandwidth of each individual data stream is large, routing conflicts between multiple data streams are likely to occur. In this case, if the data stream duration is long, network performance will plummet once congestion occurs due to routing conflicts. As shown in Figure 1, a communication network between multiple servers includes multiple forwarding nodes. If server A sends traffic to server B, and the packets of this traffic belong to the same data stream, then only one path (the path indicated by the arrow in Figure 1) can be used for forwarding. When other traffic chooses the same path as this traffic, a routing conflict will occur, and forwarding two data streams through a single path will degrade network performance.

[0076] Packet-by-packet forwarding does not distinguish between data streams. Instead, after receiving a packet, it randomly selects an available path to forward it. Compared to flow-by-flow forwarding, it achieves better network load balancing, but there is a possibility of out-of-order packets within a data stream. Therefore, when out-of-order packet reception is supported, packet-by-packet forwarding achieves better load balancing than flow-by-flow forwarding. As shown in Figure 2, server A sends traffic to server B. After receiving the traffic from server A, forwarding node 1 finds two equal-cost paths (as indicated by the arrows in Figure 2), and can therefore distribute the traffic across these two equal-cost paths.

[0077] 3. Forwarding Node

[0078] A forwarding node is a node in a communication network that has data forwarding capabilities. A forwarding node has multiple ports, through which it forwards packets. Forwarding nodes are typically configured with a buffer, also known as a port buffer, which stores all packets received by the forwarding node. The port on the forwarding node used to receive packets is called the ingress port, and the port used to send packets is called the egress port.

[0079] In some cases, each port of a forwarding node has multiple port queues (also called forwarding queues), each with a corresponding priority. For example, each port might have eight port queues, each with a specific priority. When a forwarding node receives a packet, it buffers the packet in its port buffer, determines the corresponding ingress and egress port queues, increments the packet data size for each queue, and then forwards the packets from each egress port queue sequentially. After the packet has been forwarded, the packet data size for each queue is decremented.

[0080] 4. Priority-based flow control (PFC) mechanism

[0081] PFC (Position Control) is currently the most widely used and effective hop-by-hop flow control technology to avoid packet loss, and it forms the foundation of lossless networks. Port queues with PFC enabled are called lossless queues. When a downstream device's ingress port becomes congested in its lossless queue, the downstream device notifies the upstream device to stop sending traffic from that queue, thus achieving zero-packet-loss transmission.

[0082] As shown in Figure 3, forwarding node A has 8 outgoing port queues, each with a corresponding priority. Forwarding node B has 8 incoming port queues, each with a corresponding priority. The priorities of the 8 outgoing port queues of forwarding node A and the 8 incoming port queues of forwarding node B correspond one-to-one. Thus, the 8 outgoing port queues of forwarding node A and the 8 incoming port queues of forwarding node B form 8 virtualized channels in the network. When incoming port queue 7 of forwarding node B becomes congested, i.e., the total data volume of all packets corresponding to incoming port queue 7 exceeds a certain threshold, forwarding node B sends a PFC message to the upstream device (i.e., forwarding node A in the direction of data inflow). After receiving the PFC message, forwarding node A stops sending packets corresponding to outgoing port queue 7. At this time, all packets corresponding to outgoing port queue 7 are buffered in the port buffer of forwarding node A, and the data volume of packets corresponding to outgoing port queue 7 gradually increases. Simultaneously, the data volume of packets in the incoming port queue corresponding to that outgoing port in forwarding node A also gradually increases. If a certain ingress port queue in forwarding node A also becomes congested, that is, the data volume of all packets corresponding to a certain ingress port queue of forwarding node A also exceeds the threshold, then the back pressure continues to be applied upstream, and so on, level by level, until the packet sending end, thereby eliminating packet loss caused by forwarding node congestion in the network.

[0083] 5. Credit-based flow control mechanism

[0084] Credit-based flow control is another widely used hop-by-hop flow control mechanism. Downstream devices send their available remaining buffer space in their inbound port queues as available credit to upstream devices. Upstream devices send traffic according to the available credit of downstream devices, and each time traffic is sent, a corresponding amount of credit is consumed. Upstream devices stop sending traffic when the available credit of a downstream device reaches 0.

[0085] Secondly, the application scenarios involved in the embodiments of this application will be introduced.

[0086] Based on AI traffic characteristics and load balancing effectiveness, per-packet forwarding is typically used to forward AI traffic. Furthermore, to ensure network congestion-free packet loss, hop-by-hop flow control mechanisms (such as PFC or credit mechanisms) are usually employed to implement AI traffic forwarding. That is, the per-packet forwarding load balancing mechanism avoids congestion caused by routing conflicts, and the hop-by-hop flow control mechanism ensures that even during congestion, packet loss will not lead to performance degradation. Per-packet forwarding allows packets to be forwarded on all equal-cost paths. When congestion occurs in the ingress queue of a forwarding node, the hop-by-hop flow control mechanism feeds back the congestion to every equal-cost path. For example, in a tree-based logical topology, many-to-one traffic can cause congestion, or internal server congestion can generate hop-by-hop flow control signals fed back to the forwarding node, causing accumulation in the ingress queue of that forwarding node. The hop-by-hop flow control mechanism then feeds back the congestion tier by tier to each path.

[0087] Different computing tasks may share some forwarding nodes, so triggering hop-by-hop flow control for one computing task will affect the traffic of other computing tasks. For example, as shown in Figure 4, there are two computing tasks in these multiple servers, namely computing task 1 and computing task 2. The traffic of computing task 1 needs to be sent to server C through server A. Suppose that during the process of server A sending traffic to server C, the traffic of computing task 1 becomes congested at forwarding node 4 and triggers the hop-by-hop flow control mechanism. At this time, forwarding node 4 will generate a hop-by-hop flow control message and feed it back to forwarding nodes 1 and 2 in the direction indicated by the arrow in Figure 4, where forwarding nodes 1 and 2 will buffer the message. If forwarding node 1 also becomes congested, forwarding node 1 will generate a hop-by-hop flow control message and feed it back to forwarding nodes 3 and 5 in the direction indicated by the arrow in Figure 4, where forwarding nodes 3 and 5 will buffer the message. If forwarding node 2 also becomes congested, it generates a hop-by-hop flow control message and feeds it back to forwarding nodes 3 and 5 in the direction indicated by the arrows in Figure 4. If forwarding node 3 also becomes congested, it generates a hop-by-hop flow control message and feeds it back to each server it is connected to. If forwarding node 5 also becomes congested, it generates a hop-by-hop flow control message and feeds it back to each server it is connected to. Computation task 2 and computation task 1 share some forwarding nodes, as shown in Figure 4 (forwarding nodes 4, 1, and 2). This means that these forwarding nodes forward traffic for computation task 1 as well as traffic for computation task 2. The hop-by-hop flow control messages generated for computation task 1 also cause these forwarding nodes to control the traffic for computation task 2. Therefore, the hop-by-hop flow control mechanism triggered for computation task 1 can affect the traffic for computation task 2, i.e., it may inadvertently harm the traffic of computation task 2.

[0088] Based on this, this application provides a method for sending congestion notification messages. The method involves generating a first congestion notification message at the destination node (forwarding node 4 in Figure 4), which carries a second congestion notification message (a hop-by-hop flow control message generated by forwarding node 4 in Figure 4). The first congestion notification message is then forwarded to the source node (forwarding node 3 in Figure 4) through an intermediate forwarding node. The source node then sends the second congestion notification message carried by the first congestion notification message to the sender of the congested data flow (server A in Figure 4), whereby the sender directly controls the subsequent traffic of the congested data flow. Instead of the destination node sending the second congestion notification message to the directly connected upstream forwarding node, which then buffers the data flow's messages and, if congestion occurs, regenerates a hop-by-hop flow control message and feeds it back upstream until the sender of the congested data flow reaches the destination node, this method prevents the congestion notification from spreading to other data flow paths, enabling precise control of the subsequent traffic of the congested data flow without affecting other traffic sharing the forwarding node. Furthermore, by including a second congestion announcement message in the first congestion announcement message, the first congestion announcement message is forwarded to the source node through intermediate forwarding nodes. This avoids the time spent waiting for intermediate forwarding nodes to perform message caching, handle congestion, and generate hop-by-hop flow control messages. Moreover, after receiving the first congestion announcement message, the source node can directly extract the second congestion announcement message from it without constructing it. This allows for faster feedback of congestion to the sending end of the congested data stream, thereby improving the transmission efficiency of congestion announcement messages.

[0089] Finally, the implementation environment involved in the embodiments of this application will be described.

[0090] Please refer to Figure 5, which is a schematic diagram of an implementation environment shown in an embodiment of this application. This implementation environment includes multiple computing devices 01 and multiple forwarding nodes 02. One computing device 01 establishes a communication connection with one forwarding node 02, and one forwarding node 02 establishes a communication connection with one or more computing devices 01. The multiple forwarding nodes 02 also establish communication connections with each other. To improve communication reliability, although not shown in the figure, it can be understood that one computing device 01 can also establish communication connections with two or more forwarding nodes 02. In this case, the two or more forwarding nodes 02 serve as backup nodes for each other. The communication connection can be wired or wireless; this embodiment of the application does not limit the specific type of connection.

[0091] The multiple computing devices 01 are devices with deployed services. For example, for an AI model, the multiple computing devices 01 are devices with deployed AI computing tasks. The multiple forwarding nodes 02 are nodes used to realize the interaction between the multiple computing devices 01, that is, the interaction data between the multiple computing devices 01 is forwarded through the multiple forwarding nodes 02.

[0092] The network comprised of these multiple forwarding nodes 02 is also called the communication network between these multiple computing devices 01. This communication network can adopt a two-layer network architecture (as shown in Figure 5) or a three-layer network architecture. The two-layer network includes a core layer and an access layer. The core layer is the high-speed switching backbone of the communication network, connected to the backbone network (also called the core network), for example, connected to the controller in the backbone network. The access layer is used to connect workstations to the communication network. These workstations can be the computing devices shown in Figure 5, or they can be base stations, access points, etc. The three-layer network architecture adds a convergence layer to the two-layer network architecture. The convergence layer provides convergence connections (such as connecting the access layer and the core layer). Forwarding nodes located in the access layer are called access layer nodes, forwarding nodes located in the convergence layer are called convergence layer nodes, and forwarding nodes located in the core layer are called core layer nodes.

[0093] Taking the two-layer network architecture shown in Figure 5 as an example, the forwarding nodes 02 connecting computing device 01 are located in the access layer, and these forwarding nodes 02 are called access layer nodes. The forwarding nodes 02 at the top layer are located in the core layer, and these forwarding nodes 02 are called core layer nodes. In some cases, the two-layer network architecture shown in Figure 5 is also called a spine-leaf architecture, where the forwarding nodes 02 connecting computing device 01 are called leaf nodes, and the forwarding nodes 02 at the top layer are called spine nodes.

[0094] Typically, the communication process between any two computing devices 01 through the above network architecture is as follows: The first computing device (e.g., the leftmost computing device 01 in Figure 5) sends a message to the first forwarding node (e.g., the leftmost forwarding node 02 in the middle layer of Figure 5). After receiving the message, the first forwarding node encapsulates it and then sends the encapsulated message to the second forwarding node (e.g., the rightmost forwarding node 02 in the middle layer of Figure 5) through the forwarding path. After receiving the message, the second forwarding node decapsulates it and then sends the decapsulated message to the second computing device (e.g., the rightmost computing device 01 in Figure 5), thus realizing communication between the two computing devices. Here, the first forwarding node is the forwarding node that establishes a communication connection with the first computing device, and the second forwarding node is the forwarding node that establishes a communication connection with the second computing device. The first computing device is also called the sender, and the second computing device is also called the receiver. In this case, the first forwarding node is also called the source node, and the second forwarding node is also called the destination node. That is, the source node is the first-hop forwarding node relative to the sender, and the destination node is the first-hop forwarding node relative to the receiver.

[0095] During communication between the two computing devices 01, if congestion occurs at the port connecting the destination node (the rightmost forwarding node 02 in the middle layer of Figure 5) to the second computing device, the destination node generates a first congestion notification message, which carries a second congestion notification message. The destination node sends the first congestion notification message to the source node (the leftmost forwarding node 02 in the middle layer of Figure 5). The source node receives the first congestion notification message from the destination node and sends the second congestion notification message to the sender (the leftmost computing device 01 in Figure 5) to instruct the sender to control subsequent traffic.

[0096] The computing device 01 refers to terminal devices, servers, etc. Terminal devices are any electronic products that allow human-computer interaction through one or more methods such as a keyboard, touchpad, touchscreen, remote control, voice interaction, or handwriting devices, such as personal computers (PCs), mobile phones, and tablets. Servers are virtual machines, bare metal (i.e., machines without an operating system), etc. A server can be a single independent server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, or a cloud computing service center.

[0097] Forwarding node 02 can be any device with data forwarding capabilities. Examples include network devices such as switches, routers, gateways (GWs), virtual switches (vSwitch), and virtual routers (vRouter). In other embodiments, forwarding node 02 can also be a chip or network interface card (NIC) with data forwarding capabilities within certain devices. For instance, forwarding node 02 is a chip with data forwarding capabilities in network devices such as switches, routers, and gateways, such as a network processor (NP) chip. As another example, forwarding node 02 is a NIC with data forwarding capabilities in a terminal device or server.

[0098] Those skilled in the art should understand that the above-described computing device 01 and forwarding node 02 are merely examples. Other existing or future computing devices or forwarding nodes that are applicable to the embodiments of this application should also be included within the scope of protection of the embodiments of this application, and are hereby incorporated by reference.

[0099] It should be noted that the application scenarios and implementation environments described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the emergence of new application scenarios and the evolution of implementation environments, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0100] The following section provides a detailed explanation of the method for sending congestion notification messages provided in the embodiments of this application.

[0101] Figure 6 is a flowchart of a method for sending a congestion notification message according to an embodiment of this application. Referring to Figure 6, the method includes the following steps.

[0102] Step 601: The destination node generates a first congestion notice message, which carries a second congestion notice message.

[0103] In some embodiments, the destination node generates a second congestion announcement message and encapsulates the second congestion announcement message to obtain a first congestion announcement message. That is, the first congestion announcement message carrying the second congestion announcement message means that the second congestion announcement message is completely encapsulated within the first congestion announcement message.

[0104] The destination node is a forwarding node used to connect to the receiving end of the first data stream. The first congestion notification message is generated when congestion occurs at the outgoing port of the destination node used to forward the first data stream. Congestion at the outgoing port used to forward the first data stream can be determined in two ways.

[0105] In the first implementation, congestion at the outgoing port used to forward the first data stream includes: the queue depth of the outgoing port being greater than or equal to a first depth threshold. That is, the queue depth of the outgoing port, i.e., the amount of data in all packets buffered in the port queue of the outgoing port, is detected. If the queue depth of the outgoing port is greater than or equal to the first depth threshold, then congestion at the outgoing port is determined.

[0106] In some embodiments, the first depth threshold is triggered earlier than the second depth threshold, where the second depth threshold is the queue depth at which the ingress port of the destination node, used for forwarding the first data stream, triggers the flow control mechanism. That is, a first congestion notice message is sent before the flow control mechanism is triggered at the ingress port. This allows the second congestion notice message to arrive at the sender of the first data stream before the flow control mechanism at the ingress port, enabling the sender to control subsequent traffic of the first data stream before the flow control mechanism at the ingress port, thus preventing the flow control mechanism messages from spreading across various paths and affecting other traffic.

[0107] In some embodiments, the sum of the first depth threshold and the reference depth is less than the second depth threshold. The reference depth refers to the value of the number of ingress ports within a reference time period; the reference time period refers to the time between the sending time of the first congestion notification message and the start time of subsequent traffic control of the first data stream by the sender of the first data stream; and the number of ingress ports refers to the number of ingress ports corresponding to the egress ports used to forward the first data stream.

[0108] Congestion at the outgoing port can be understood as congestion in the port queue of that outgoing port, or congestion at the destination node. Congestion at the outgoing port can occur when there is multi-call traffic within the destination node. Of course, it can also occur under other circumstances; this application does not limit the causes of congestion in its embodiments.

[0109] In some embodiments, if the queue depth of the output port is less than a first depth threshold, it is determined that the output port is not congested.

[0110] It should be noted that the first depth threshold is determined based on the maximum depth of the outgoing port queue, and the second depth threshold is determined based on the maximum depth of the incoming port queue. In other words, the first depth threshold will be different when the maximum depth of the outgoing port queue is different, and the second depth threshold will be different when the maximum depth of the incoming port queue is different.

[0111] The second implementation method, where congestion occurs at the egress port used to forward the first data stream, includes: the port queue of the egress port being back-pressurized by the flow control mechanism. That is, the flow control status of the egress port queue is detected. This flow control status indicates whether the egress port queue is being back-pressurized by the flow control mechanism, i.e., whether the egress port queue is receiving a flow control signal. If the flow control status of the egress port queue indicates that the egress port queue is being back-pressurized by the flow control mechanism, then it is determined that the egress port is congested.

[0112] When the outgoing port queue is back-pressed by the flow control mechanism, the first congestion notification message is sent. In this way, after the second congestion notification message arrives at the sender of the first data stream, the sender can control the subsequent traffic of the first data stream, thereby keeping the flow control mechanism within the destination node and preventing it from spreading to other nodes and affecting other traffic.

[0113] Congestion at the output port can be understood as congestion in the port queue of the output port, or congestion at the destination node. Congestion at the output port can occur when the receiving end of the first data stream is congested, but it can also occur in other situations. This application embodiment does not limit the cause of congestion.

[0114] In some embodiments, if the flow control status of the outgoing port queue indicates that the outgoing port queue is not under back pressure from the flow control mechanism, then it is determined that the outgoing port is not congested.

[0115] Based on the above description, a forwarding node has multiple ports. The port used to receive packets on the forwarding node is the ingress port, and the port used to send packets is the egress port. The first congestion notification message is generated by determining whether the egress port used to forward the first data stream is congested. Since the first congestion notification message carries a second congestion notification message, it can also be understood that the second congestion notification message is generated when the egress port used to forward the first data stream is congested. However, the ingress port is not a port directly connected to the receiving end, and packets received by the ingress port may correspond to different egress ports. Therefore, compared to triggering flow control mechanisms based on whether the ingress port is congested, determining whether the egress port is congested can clearly identify the specific data stream experiencing congestion, thus providing a guarantee for precise control of subsequent traffic from the congested data stream.

[0116] In some embodiments, where the egress port for forwarding the first data stream includes multiple port queues, in the two implementations described above, congestion at the egress port for forwarding the first data stream refers to congestion in the port queue containing the first data stream at the egress port for forwarding the first data stream in the destination node. That is, the first congestion notification message is generated when the port queue containing the first data stream at the egress port for forwarding the first data stream in the destination node is congested. In this case, in the embodiments of this application, the port queue for forwarding the first data stream refers to the egress port queue containing the first data stream at the egress port for forwarding the first data stream.

[0117] In some cases, the egress port used to forward the first data stream may also forward other data streams simultaneously. Therefore, if congestion occurs at this egress port, a congestion notice can be sent not only to the sender of the first data stream but also to the senders of other data streams. In this case, a first congestion notice message can be generated for each data stream forwarded through this egress port. Of course, in some other embodiments, a first congestion notice message can also be generated for at least two data streams.

[0118] As an example, the outgoing port used to forward the first data stream may also simultaneously forward a second data stream, and the source node of the second data stream is the same as the source node of the first data stream; that is, the sender of the first data stream and the sender of the second data stream are connected to the same forwarding node. In this way, the first congestion announcement message also carries a third congestion announcement message, which is used to instruct the sender of the second data stream to control the subsequent traffic of the second data stream. That is, the destination node not only generates the second congestion announcement message but also the third congestion announcement message, and encapsulates the second and third congestion announcement messages to obtain the first congestion announcement message.

[0119] Taking the second congestion notification message as an example, in some embodiments, the second congestion notification message is a flow control message. Of course, in other application scenarios, the second congestion notification message can also be other types of messages, and this flow control message can be a hop-by-hop flow control message, a PFC-based message (referred to as a PFC message), a credit-based flow control message (referred to as a credit message), or any other type of flow control message. This application does not limit this.

[0120] The encapsulation process of the second congestion notice message is described below.

[0121] The process of encapsulating a second congestion notification message to obtain a first congestion notification message includes: retrieving flow information of a first data flow from a congestion flow table; and encapsulating the second congestion notification message based on the flow information of the first data flow to obtain the first congestion notification message. The congestion flow table stores flow information of the data flows forwarded by each outgoing port where congestion occurs.

[0122] In some embodiments, a congestion flow table is used to store the identifier of the outgoing port experiencing congestion and the flow information of the data streams forwarded by that outgoing port. When congestion occurs at an outgoing port used to forward a first data stream, the destination node can look up the flow information of the data streams forwarded by that outgoing port in the congestion flow table based on the identifier of the outgoing port. If the flow information of one data stream is found, that data stream is identified as the first data stream; if the flow information of multiple data streams is found, any one of those multiple data streams is identified as the first data stream. Then, the flow information of the first data stream is encapsulated in the packet header, and a second congestion announcement message is encapsulated in the payload to obtain a first congestion announcement message. That is, the first congestion announcement includes flow information of the first data stream.

[0123] The flow information includes the address information of the sender and the address information of the receiver of the data stream. The sender's address information can be used as the destination address in the header of the first congestion notification message, and the receiver's address information can be used as the source address in the header of the first congestion notification message. In other words, taking the first data stream as an example, the source and destination addresses in the header of the first congestion notification message are obtained by reversing the source and destination addresses in the first data stream message; that is, the sender's address information is the source address in the first data stream message, and the receiver's address information is the destination address in the first data stream message. Thus, the network protocol used to send the first data stream can be the same as the network protocol used to send the first congestion notification message, eliminating the need to redefine the network protocol for the first congestion notification message.

[0124] As an example, if the network protocol used to forward the packets of the first data stream is the Internet Protocol (IP), then the stream information includes the IP address of the sender and the IP address of the receiver of the first data stream. The IP address of the sender is the source IP address in the packets of the first data stream, and the IP address of the receiver is the destination IP address in the packets of the first data stream. Then, the IP address of the sender of the first data stream is used as the destination IP address in the header of the first congestion notice message, and the IP address of the receiver of the first data stream is used as the source IP address in the header of the first congestion notice message, and these are encapsulated in the header. The second congestion notice message is encapsulated in the payload to obtain the first congestion notice message.

[0125] The above description uses the example of stream information including the address information of the sender and the address information of the receiver. In other embodiments, the stream information may include more or less information. Furthermore, the identifier of the congested output port can be its port number, or other information that uniquely identifies the output port.

[0126] The above description uses the example of the second congestion notification message being encapsulated in the payload. In other embodiments, the second congestion notification message may also be encapsulated in other locations besides the payload. This application does not limit this.

[0127] In some embodiments, the identifier of the outgoing port used to forward the first data stream and the flow information of the data stream forwarded by that outgoing port are stored when the outgoing port is congested. That is, when the outgoing port is congested, the identifier of the outgoing port and the flow information of the data stream forwarded by that outgoing port are obtained and stored in the congestion flow table. It is understood that a corresponding congestion flow table can also be generated separately for each outgoing port. In this case, the outgoing port identifier does not need to be recorded in the congestion flow table; only the flow information of the data stream forwarded by that outgoing port needs to be recorded.

[0128] In other embodiments, to improve the transmission rate of congestion notification messages, the destination node can further obtain the identifier of the outgoing port and the flow information of the data stream forwarded by the outgoing port when it detects that the queue depth of the outgoing port is greater than or equal to a third depth threshold, and store them in the congestion flow table. The third depth threshold is less than the first depth threshold. That is, the congestion flow table is constructed before generating the first congestion notification message. This allows the generation of the first congestion notification message to be directly implemented according to the information in the congestion flow table, without waiting for the construction of the congestion flow table, thereby reducing the time consumed in the generation process of the first congestion notification message and improving the generation efficiency of the first congestion notification message.

[0129] The above example illustrates how a congestion flow table is used to encapsulate the second congestion notification message. In other embodiments, it is not necessary to create a congestion flow table. Instead, when congestion occurs at the outgoing port used to forward the first data flow, the packets of the first data flow are directly collected from the port queue of that outgoing port, the flow information is obtained from the packets of the first data flow, and the second congestion notification message is encapsulated based on the flow information of the first data flow.

[0130] Based on the above description, the outgoing port used to forward the first data stream may also simultaneously forward a second data stream, and the source node of the second data stream is the same as the source node of the first data stream. In this case, the first congestion notification message also carries a third congestion notification message. In this situation, it is also necessary to determine the flow information of the second data stream, and based on the flow information of the second data stream, encapsulate the third congestion notification message into the first congestion notification message. That is, the first congestion notification message also carries the flow information of the second data stream.

[0131] The encapsulation process of the third congestion notification message is similar to that of the second congestion notification message, and will not be described in detail here.

[0132] The above description uses the example of a congestion flow table including the identifier of the outgoing port where congestion occurs and the flow information of each data stream forwarded by that outgoing port. In other embodiments, the congestion flow table may also include other information, such as the sending timestamp of the first congestion notification message, which can be stored after the first congestion notification message is sent.

[0133] In some embodiments, the first congestion notification message also carries a flag indicating the type of the first congestion notification message. For example, the first congestion notification message includes an unreliable datagram protocol (UDP) header, and the flag is the port number in the UDP header; or, the first congestion notification message includes a transmission control protocol (TCP) header, and the flag is the port number in the TCP header. Of course, if the first congestion notification message includes other types of Layer 4 network protocol headers, the flag is a reserved bit in that Layer 4 network protocol header.

[0134] In the embodiments of this application, the data stream can be understood as a data stream divided according to a quintuple, a data stream divided according to a septum, or a data stream divided according to a binary tuple. Of course, in some other embodiments, it can also be understood as a data stream divided in other ways, such as a data stream divided according to a quadruple.

[0135] The data stream is categorized into several tuples. A 5-tuple includes the source address, destination address, protocol number, source port, and destination port. A 7-tuple includes the source address, destination address, protocol number, source port, destination port, interface index, and type of service (ToS). A 2-tuple includes the source address and destination address. A 4-tuple includes the source address, destination address, source port, and destination port. The source address is the address of the sender of the data stream. The destination address is the address of the receiver of the data stream. The source port is the port used by the sender to transmit the data stream (a logical port). The destination port is the port used by the receiver to receive the data stream (a logical port). The protocol number indicates the protocol used by the sender and receiver to transmit the data stream. The interface index indicates the physical interface used to transmit the data stream; typically, one physical interface corresponds to multiple logical ports. The ToS indicates the priority of the data stream.

[0136] In other embodiments, for remote direct memory access (RDMA), the seven-tuple includes the source address, destination address, protocol number, source port, destination port, source queue pair (QP), and destination QP.

[0137] Step 602: The destination node sends a first congestion notice message to the source node corresponding to the first data stream.

[0138] In some embodiments, the first congestion notification message also carries flow information of the first data stream. Therefore, the destination node can find the forwarding path of the first congestion notification message according to the flow information of the first data stream, and then send the first congestion notification message to the source node corresponding to the first data stream according to the forwarding path. Intermediate forwarding nodes on this forwarding path are used to transparently transmit the first congestion notification message.

[0139] Based on the above description, the outgoing port used to forward the first data stream may also simultaneously forward a second data stream, and the source node of the second data stream is the same as the source node of the first data stream. In this case, the first congestion notification message also carries a third congestion notification message. In this scenario, the first congestion notification message also carries the flow information of the second data stream. The destination node can then use the flow information of the second data stream to find the forwarding path of the first congestion notification message and send the first congestion notification message according to that forwarding path.

[0140] In some embodiments, after the destination node sends a first congestion notification message to the source node corresponding to the first data stream, the sender of the first data stream controls the subsequent traffic of the first data stream. This traffic control duration is typically a fixed value; for example, the pause duration of PFC is usually a maximum of 83 microseconds. However, after one traffic control operation, the outgoing port in the destination node used to forward the first data stream may still be congested, requiring the first congestion notification message to be sent again. Based on the above description, the congestion flow table can also include a timestamp indicating the time of the most recent sending of the first congestion notification message. In this case, if no first congestion notification message has been sent before the current time, step 602 can be executed directly. If a first congestion notification message has been sent before the current time, and the time interval between the current time and the time of the last sending of the first congestion notification message (i.e., the time indicated by the timestamp) is greater than a time threshold, then step 602 is executed. In this way, congestion can be alleviated not only by sending the first congestion notice message multiple times, but the time interval between two consecutive first congestion notice messages can also be controlled, thereby avoiding the reduction of the destination node's processing capacity due to frequent sending of the first congestion notice message.

[0141] Step 603: The source node receives the first congestion notice message from the destination node.

[0142] Step 604: The source node sends a second congestion notification message to the sender of the first data stream. The second congestion notification message is used to instruct the sender of the first data stream to control the subsequent traffic of the first data stream.

[0143] Based on the above description, the first congestion notification message carries the second congestion notification message. Therefore, before the source node sends the second congestion notification message to the sender of the first data stream, it can also extract the second congestion notification message from the first congestion notification message.

[0144] In some embodiments, the source node decapsulates the first congestion announcement message to obtain the second congestion announcement message.

[0145] Based on the above description, the second congestion notification message can be carried in the payload of the first congestion notification message; at this time, the source node decapsulates the first congestion notification message to obtain the second congestion notification message, including: the source node strips the header of the first congestion notification message to obtain the second congestion notification message.

[0146] Based on the above description, the first congestion announcement message also carries a flag bit. Thus, after the source node receives the first congestion announcement message, if it determines that the flag bit is a specific value, it will perform the step of decapsulating the first congestion announcement message to obtain the second congestion announcement message.

[0147] For example, the first congestion notification message includes a UDP header, and the flag bit is the port number in the UDP header. If the port number in the UDP header is a specific port number, then the step of decapsulating the first congestion notification message to obtain the second congestion notification message is performed. Alternatively, the first congestion notification message includes a TCP header, and the flag bit is the port number in the TCP header. If the port number in the TCP header is a specific port number, then the step of decapsulating the first congestion notification message to obtain the second congestion notification message is performed. Alternatively, the first congestion notification message includes other types of Layer 4 network protocol headers, and the flag bit is a reserved bit in that Layer 4 network protocol header. If the reserved bit in that Layer 4 network protocol header is a specific value, then the step of decapsulating the first congestion notification message to obtain the second congestion notification message is performed.

[0148] The second congestion notification message is used to instruct the sender of the first data stream to control the subsequent traffic of the first data stream, and includes the following two implementation methods.

[0149] In the first implementation, the second congestion notification message is used to instruct the sender of the first data stream to suspend sending subsequent traffic of the first data stream.

[0150] Based on the above description, the second congestion notification message is a flow control message, which includes either a PFC message or a credit message.

[0151] In some embodiments, the flow control message includes a PFC message, which carries a pause duration. The pause duration is used to indicate the duration for which the sender of the first data stream suspends the transmission of subsequent traffic of the first data stream. That is, the sender can stop transmitting subsequent traffic of the first data stream during the pause duration and resume transmitting subsequent traffic of the first data stream after the pause duration.

[0152] PFC messages can be standard or non-standard. The format of a standard PFC message is shown in Figure 7. Referring to Figure 7, this PFC message includes a destination address field, a source address field, an ethertype field, a control opcode field, a priority enable vector, time(0)-time(n)-time(7), a padding field, and a cyclic redundancy check (CRC) field. The priority enable vector includes enable elements E(7)-E(n)-E(0).

[0153] The destination address field occupies 6 bytes and is used to carry a fixed Media Access Control (MAC) address, such as 0x01-80-c2-00-00-01. Thus, when the sender of the first data stream receives a PFC message, if it determines that the destination address of the PFC message is a fixed MAC address, it determines that the flow control mechanism for the first data stream needs to be triggered, i.e., controlling the subsequent traffic of the first data stream.

[0154] The source address field occupies 6 bytes. During the transmission of PFC messages, the source address field is usually not parsed, so the source address field may or may not carry a MAC address, and there are no restrictions on the MAC address carried.

[0155] The Ethernet type field occupies 2 bytes. The Ethernet type field is used to indicate the type of the PFC message, and is 0x8808.

[0156] The control opcode field occupies 2 bytes. A PFC message is a type of MAC control message; for PFC messages, the control opcode is typically 01-01.

[0157] The priority enable vector occupies 2 bytes. Figure 7 illustrates an example where each port of a forwarding node has 8 port queues. The enable elements E(7)-E(n)-E(0) in the priority enable vector in Figure 7 correspond one-to-one with the 8 port queues of the destination node, indicating which port queue is congested. For example, if port queue 7 is congested, E(7) is set to 1, and the others are set to 0.

[0158] The total time (0) - time (n) - time (7) occupies 16 bytes. Time (0) - time (n) - time (7) corresponds one-to-one with the 8 port queues of the destination node and is used to indicate the pause duration of the port queue that is congested. For example, if port queue 7 is congested, time (7) is set to 65535, and the others are set to 0.

[0159] Typically, the time(n) field can be set to a range of 0-65535, corresponding to a pause duration of (512 bits / network bandwidth) * time(n). For example, if the time(7) field is set to 65535 and the network bandwidth is 400Gbps, then the pause duration indicated by the time(7) field is (512 bits / 400Gbps) * 65535, approximately 83 microseconds. That is, the packets corresponding to port queue 7 need to be paused for 83 microseconds. In some embodiments, the pause duration corresponding to the congested port queue is a fixed value, and correspondingly, the time(n) field corresponding to the port queue is a fixed value within the range of 0-65535. Of course, the pause duration can also be set as needed, that is, the time(n) field corresponding to the port queue can be set to any value within the range of 0-65535 as needed.

[0160] The padding field occupies 26 bytes. The padding field is used to indicate that the PFC message has sufficient length to handle collision detection during transmission. During transmission, the value of the padding field is 0.

[0161] CRC occupies 4 bytes. CRC is used to indicate whether an error occurred during the transmission of a PFC message.

[0162] In other embodiments, the flow control message includes a credit-based flow control message, which carries an available credit limit, and the available credit limit is 0. The credit-based flow control message is simply referred to as a credit message.

[0163] The available credit limit refers to the amount of data that the destination node can receive. When the available credit limit is 0, it indicates that the destination node is currently unable to receive data, and the sender can stop sending subsequent traffic of the first data stream.

[0164] Credit messages can be either standard or non-standard. The format of a standard credit message is shown in Figure 8. Referring to Figure 8, the credit message includes the operand (Op), total flow control blocks sent (FCTBS), virtual lane (VL), flow control credit limit (FCCL), and link packet cyclic redundancy check (LPCRC).

[0165] Op occupies 4 bytes. Op can be fixed to 1, indicating that this message is a flow control message.

[0166] FCTBS occupies 12 bytes. FCTBS indicates the cumulative amount of data that the data sender can send.

[0167] VL occupies 4 bytes. VL indicates a port queue among multiple port queues of a port.

[0168] FCCL occupies 12 bytes. FCCL indicates the maximum amount of data that the data sender can send cumulatively.

[0169] LPCRC occupies 16 bytes. LPCRC is used to indicate whether a credit message has encountered an error during transmission.

[0170] After receiving a credit message, the sender can continue sending data up to the limit of FCCL - FCTBS, which is the available flow control limit, or available credit limit. In other words, the available credit limit is FCCL - FCTBS. When the available credit limit is 0, FCCL and FCTBS are equal. For example, both FCTBS and FCCL are 0.

[0171] In the second implementation, the second congestion notification message is used to instruct the sender of the first data stream to send subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

[0172] In some embodiments, the second congestion notification message is a flow control message, which includes a credit-based flow control message. The credit-based flow control message carries an available credit limit, and the available credit limit is greater than 0. The credit-based flow control message is simply referred to as a credit message.

[0173] Based on the above description, the available credit limit refers to the amount of data the destination node can receive. Therefore, if the available credit limit is greater than 0, it indicates that subsequent traffic of the first data stream will not be stopped, but rather sent according to the amount of data the destination node can receive. This is equivalent to reducing the sending rate of subsequent traffic of the first data stream.

[0174] For the credit message shown in Figure 8 above, the available credit limit is FCCL - FCTBS. When the available credit limit is greater than 0, FCCL is greater than FCTBS. For example, FCTBS is 0, FCCL is the available buffer capacity divided by N, where the available buffer capacity is the remaining available buffer size of the outgoing port in the destination node used to forward the first data stream, and N is the number of data streams forwarded by that outgoing port.

[0175] In both of the above implementation methods, for the credit message, after the source node strips the header of the first congestion announcement message, it is also necessary to add the latest FCTBS value recorded locally by the source node to both FCCL and FCTBS, and then recalculate the LPCRC value to obtain the second congestion announcement message.

[0176] Based on the above description, the ports of a forwarding node comprise multiple port queues, each corresponding to a priority. The port queues used for forwarding the first data stream at each forwarding node along the forwarding path can be the same or different. When the port queues used for forwarding the first data stream are the same across all forwarding nodes, the source node can directly instruct the sender of the first data stream to control the packets in the corresponding port queue, thereby controlling the subsequent traffic of the first data stream. When the port queues used for forwarding the first data stream are different across all forwarding nodes, the first congestion-passing packet can also carry priority indication information, such as a differentiated services code point (DSCP). This priority indication information indicates the priority of the port queue in which the packets of the first data stream reside. Thus, the source node can determine the port queue used for forwarding the first data stream within the source node based on this priority indication information, and then instruct the sender of the first data stream to control the packets in the corresponding port queue, thereby controlling the subsequent traffic of the first data stream.

[0177] In some embodiments, the source node is configured with a local flow control mechanism, such as a local hop-by-hop flow control mechanism. However, the mechanism by which the second congestion notification message is sent via the first congestion notification message in this embodiment is another flow control mechanism. When the second congestion notification message is a PFC message, because the PFC message carries a pause duration, the sender of the first data stream can pause sending subsequent traffic of the first data stream according to this pause duration. Thus, the source node is unlikely to continue receiving subsequent traffic of the first data stream, and the local flow control mechanism in the source node is unlikely to be triggered. However, when the second congestion notification message is a credit message, since the available credit limit is used to indicate the amount of data the destination node can receive, if the second congestion notification message indicates that the sender of the first data stream needs to pause sending subsequent traffic of the first data stream or reduce the sending rate of subsequent traffic of the first data stream, and the source node's local flow control mechanism indicates that the downstream device can still receive a certain amount of data, then the sender of the first data stream will still continue sending subsequent traffic of the first data stream, thus rendering the second congestion notification message ineffective. Therefore, the source node also needs to control the flow control mechanism of the port to which the sending end is connected to, so that it fails within the target duration. This flow control mechanism is a local flow control mechanism for that port.

[0178] For example, the mechanism of sending a second congestion notice message via a first congestion notice message is called a remote flow control mechanism. The source node also has a hop-by-hop flow control mechanism configured locally. For a credit message, if the available credit limit carried by the second congestion notice message is 0, it indicates that the remote flow control mechanism instructs the sender to suspend sending subsequent traffic of the first data stream. However, the source node's hop-by-hop flow control mechanism indicates that downstream devices can still receive a certain amount of data. Therefore, the sender of the first data stream will continue to send subsequent traffic of the first data stream, rather than suspending it, thus rendering the second congestion notice message ineffective. Therefore, the source node also needs to control the hop-by-hop flow control mechanism of the port connected to the sender of the first data stream to become ineffective within the target duration.

[0179] The target duration can be a pre-configured fixed value, or it can be adjusted according to actual needs.

[0180] Based on the above description, the outgoing port used to forward the first data stream may also simultaneously forward a second data stream, and the source node of the second data stream is the same as the source node of the first data stream. In this case, the first congestion notification message also carries a third congestion notification message. In this situation, in addition to sending the second congestion notification message to the sender of the first data stream, the source node also sends a third congestion notification message to the sender of the second data stream. The third congestion notification message is used to instruct the sender of the second data stream to control the subsequent traffic of the second data stream. The process of sending the third congestion notification message to the sender of the second data stream is similar to the process of sending the second congestion notification message to the sender of the first data stream, and will not be described again here.

[0181] In summary, the destination node generates a first congestion notice (CHF) message, which carries a second CHF message. The first CHF message is then forwarded to the source node of the first data stream via intermediate forwarding nodes. The source node then sends the second CHF message carried by the first CHF message to the sender of the first data stream. The sender of the first data stream directly controls the subsequent traffic of the first data stream. Instead of the destination node sending the second CHF message to directly connected upstream forwarding nodes, which then buffer the data stream's packets and, if congestion occurs, regenerate hop-by-hop flow control messages and feed them back upstream until the sender of the first data stream is reached, the congestion notice from the first data stream does not propagate to the paths of other data streams. This allows for precise control of the subsequent traffic of the first data stream and does not affect other traffic sharing the forwarding nodes. Furthermore, by including a second congestion notification message in the first congestion notification message and forwarding the first congestion notification message to the source node through intermediate forwarding nodes, the time spent waiting for intermediate forwarding nodes to buffer messages, detect congestion, and generate hop-by-hop flow control messages is avoided. Moreover, after receiving the first congestion notification message, the source node can directly extract the second congestion notification message without constructing it, thus enabling faster feedback of congestion to the sender of the first data stream and improving the transmission efficiency of the congestion notification message. Additionally, this embodiment generates the first congestion notification message by determining whether the egress port used to forward the first data stream is congested. The ingress port is not directly connected to the receiver, and the messages received at the ingress port may correspond to different egress ports. Therefore, compared to triggering flow control mechanisms based on whether the ingress port is congested, determining whether the egress port is congested clearly identifies the specific data stream experiencing congestion, thereby ensuring precise control of subsequent traffic from the congested data stream.

[0182] Figure 9 is a schematic diagram of a congestion notification message sending device provided in an embodiment of this application. This device can be implemented by software, hardware, or a combination of both as part or all of a source node, which can be the forwarding node shown in Figure 5. Referring to Figure 9, the device includes: a message receiving module 901 and a message sending module 902.

[0183] The message receiving module 901 is used to receive a first congestion notification message from the destination node, the first congestion notification message carrying a second congestion notification message;

[0184] The message sending module 902 is used to send a second congestion notification message to the sender of the first data stream. The second congestion notification message is used to instruct the sender to control the subsequent flow of the first data stream.

[0185] Optionally, the device further includes:

[0186] The decapsulation module is used to decapsulate the first congestion announcement message in order to obtain the second congestion announcement message.

[0187] Optionally, the second congestion notification message is carried in the payload of the first congestion notification message; the decapsulation module is specifically used for:

[0188] The second congestion notice message is obtained by stripping the header of the first congestion notice message.

[0189] Optionally, the second congestion notification message is a flow control message.

[0190] Optionally, the second congestion notification message used to instruct the sender to control subsequent traffic of the first data stream includes: the second congestion notification message used to instruct the sender to suspend sending subsequent traffic of the first data stream.

[0191] Optionally, the flow control message includes a priority-based flow control (PFC) message, which carries a pause duration to indicate the duration for which the sender suspends sending subsequent traffic of the first data stream.

[0192] Optionally, the flow control message includes a credit-based flow control message, which carries an available credit limit and has an available credit limit of 0.

[0193] Optionally, the second congestion notification message used to instruct the sender to control the subsequent traffic of the first data stream includes: the second congestion notification message used to instruct the sender to send the subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

[0194] Optionally, the flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

[0195] Optionally, the device further includes:

[0196] The control module is used to prevent the flow control mechanism of the port connected to the sender from failing within the target duration.

[0197] In this embodiment, the destination node generates a first congestion notice message, which carries a second congestion notice message. The first congestion notice message is then forwarded to the source node of the first data stream via an intermediate forwarding node. The source node then sends the second congestion notice message carried in the first congestion notice message to the sender of the first data stream. The sender of the first data stream directly controls the subsequent traffic of the first data stream. Instead of the destination node sending the second congestion notice message to a directly connected upstream forwarding node, which then buffers the data stream's packets and, if congestion occurs, generates hop-by-hop flow control messages and feeds them upstream until the sender of the first data stream. In this way, the congestion notice of the first data stream does not propagate to the paths of other data streams, enabling precise control of the subsequent traffic of the first data stream without affecting other traffic sharing the forwarding node. Furthermore, by including a second congestion notification message in the first congestion notification message, the first congestion notification message is forwarded to the source node through intermediate forwarding nodes. This avoids the time spent waiting for intermediate forwarding nodes to perform message caching, handle congestion, and generate hop-by-hop flow control messages. Moreover, after receiving the first congestion notification message, the source node can directly extract the second congestion notification message from it without constructing it. This allows for faster feedback of congestion to the sender of the first data stream, thereby improving the transmission efficiency of the congestion notification message.

[0198] It should be noted that the congestion notification message sending device provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the congestion notification message sending device and the congestion notification message sending method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0199] Figure 10 is a schematic diagram of a congestion notification message sending device provided in an embodiment of this application. This device can be implemented by software, hardware, or a combination of both as part or all of the destination node, which can be the forwarding node shown in Figure 5. Referring to Figure 10, the device includes: a message generation module 1001 and a message sending module 1002.

[0200] The message generation module 1001 is used to generate a first congestion notification message, which carries a second congestion notification message.

[0201] The message sending module 1002 is used to send a first congestion notification message to the source node, so that the source node sends a second congestion notification message to the sender of the first data stream. The second congestion notification message is used to instruct the sender to control the subsequent flow of the first data stream.

[0202] Optionally, the device further includes:

[0203] The encapsulation module is used to generate a second congestion notification message and encapsulate the second congestion notification message to obtain a first congestion notification message.

[0204] Optionally, the second congestion notification message is a flow control message.

[0205] Optionally, the second congestion notification message used to instruct the sender to control subsequent traffic of the first data stream includes: the second congestion notification message used to instruct the sender to suspend sending subsequent traffic of the first data stream.

[0206] Optionally, the flow control message includes a priority-based flow control (PFC) message, which carries a pause duration to indicate the duration for which the sender suspends sending subsequent traffic of the first data stream.

[0207] Optionally, the flow control message includes a credit-based flow control message, which carries an available credit limit and has an available credit limit of 0.

[0208] Optionally, the second congestion notification message used to instruct the sender to control the subsequent traffic of the first data stream includes: the second congestion notification message used to instruct the sender to send the subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

[0209] Optionally, the flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

[0210] Optionally, the first congestion notification message is generated when the outgoing port of the destination node used for forwarding the first data stream becomes congested. The congestion of the outgoing port includes: the queue depth of the outgoing port is greater than or equal to a first depth threshold, wherein the time of triggering the first depth threshold is earlier than the time of triggering the second depth threshold, and the second depth threshold is the queue depth of the ingoing port of the destination node used for forwarding the first data stream that triggers the flow control mechanism.

[0211] In this embodiment, the destination node generates a first congestion notice message, which carries a second congestion notice message. The first congestion notice message is then forwarded to the source node of the first data stream via an intermediate forwarding node. The source node then sends the second congestion notice message carried in the first congestion notice message to the sender of the first data stream. The sender of the first data stream directly controls the subsequent traffic of the first data stream. Instead of the destination node sending the second congestion notice message to a directly connected upstream forwarding node, which then buffers the data stream's packets and, if congestion occurs, generates hop-by-hop flow control messages and feeds them upstream until the sender of the first data stream. In this way, the congestion notice of the first data stream does not propagate to the paths of other data streams, enabling precise control of the subsequent traffic of the first data stream without affecting other traffic sharing the forwarding node. Furthermore, by including a second congestion notification message in the first congestion notification message, the first congestion notification message is forwarded to the source node through intermediate forwarding nodes. This avoids the time spent waiting for intermediate forwarding nodes to perform message caching, handle congestion, and generate hop-by-hop flow control messages. Moreover, after receiving the first congestion notification message, the source node can directly extract the second congestion notification message from it without constructing it. This allows for faster feedback of congestion to the sender of the first data stream, thereby improving the transmission efficiency of the congestion notification message.

[0212] It should be noted that the congestion notification message sending device provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the congestion notification message sending device and the congestion notification message sending method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0213] Figure 11 is a schematic diagram of a forwarding node provided in an embodiment of this application. As shown in Figure 11, the forwarding node 1100 includes a processor 1101, a forwarding chip 1102, and at least one network interface 1103. Optionally, referring to Figure 5, the forwarding node 1100 in Figure 11 is any of the forwarding nodes shown in Figure 5.

[0214] Optionally, the processor 1101 includes a central processing unit (CPU) and / or a dedicated hardware chip. The CPU refers to a general-purpose CPU with high scalability and flexibility. A CPU can be, for example, a single-core processor or a multi-core processor. The dedicated hardware chip is a high-performance processing hardware module. The dedicated hardware chip includes at least one of an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a network processor (NP).

[0215] The forwarding chip 1102 is used to forward requests and data. For example, the forwarding chip 1102 is used to forward messages sent and received by node 1100.

[0216] At least one network interface 1103 includes, for example, network interface 1, network interface 2, network interface 3... network interface n in FIG. 11. Network interface 1103 uses any transceiver-like device for communicating with other devices or communication networks. For example, network interface 1 in FIG. 11 communicates with a control device, and network interface 2 in FIG. 11 communicates with other forwarding nodes. Optionally, network interface 1103 includes at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, an electrical interface, or a combination thereof. The wireless network interface is, for example, a wireless protected local area networks (WLAN) interface, a cellular network interface, or a combination thereof.

[0217] At least one network interface 1103 is connected to the forwarding chip 1102, and the forwarding chip 1102 is connected to the processor 1101 via an internal connection 1104. The internal connection 1104 includes a path for transmitting data between the network interface 1103, the forwarding chip 1102, and the processor 1101. Optionally, the internal connection 1104 is a board or a bus. For example, the internal connection 1104 is Ethernet, Fibre Channel, PCI-E (Peripheral Component Interconnect Express, PCI Express, a high-speed serial computer bus), RapidIO (a high-performance, low-pin-count, packet-switched interconnect architecture), InfiniBand, or XAUI bus (an interface extender characterized by connecting the Ethernet media access control (MAC) layer to the physical layer).

[0218] Optionally, the forwarding node 1100 also includes a content addressable memory (CAM) 1105. CAM 1105 is, for example, a ternary content addressable memory (TCAM). CAM 1105 is used, for example, to store the mapping between record service flow identifiers and flow control requirements. Optionally, CAM 1105 exists independently and is connected to the forwarding chip 1102 via the aforementioned internal connection 1104. Alternatively, CAM 1105 and the forwarding chip 1102 are integrated, i.e., CAM 1105 serves as the internal memory of the forwarding chip 1102.

[0219] Optionally, the forwarding node 1100 also includes a memory 1106. The memory 1106 may be, for example, a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions; a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions; an electrically erasable programmable read-only memory (EEPROM); a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital universal discs, Blu-ray discs, etc.); a magnetic disk storage medium; or any other medium capable of carrying or storing desired program code 1108 in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 1106 may exist independently and be connected to the processor 1101 via an internal connection 1104. Alternatively, the memory 1106 and the processor 1101 may be integrated together.

[0220] The memory 1106 stores an operating system 1107 and program code 1108. Optionally, the processor 1101 reads the operating system 1107 from the memory 1106 and runs the operating system 1107. The processor 1101 also reads the program code 1108 from the memory 1106 and runs the program code 1108 on the operating system 1107 to implement the actions performed by any of the forwarding nodes in the above-described methods provided in the embodiments of this application.

[0221] Optionally, the aforementioned devices are disposed on separate chips, or at least partially or entirely on the same chip. Whether the devices are disposed independently on different chips or integrated on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0222] This application also provides a chip, which includes programmable logic circuits and / or program instructions. When the chip is running, it implements the steps of the method for sending congestion notification messages by the source node or the destination node as shown in the embodiment of FIG6 above.

[0223] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the method for sending congestion notification messages by the source node or the destination node in the embodiment shown in FIG6.

[0224] This application also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the steps of the method for sending congestion notification messages by the source node or the destination node in the embodiment shown in FIG6.

[0225] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0226] It should be understood that "multiple" as mentioned herein refers to two or more. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., do not necessarily imply that they are different.

[0227] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0228] The above descriptions are embodiments provided in this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for sending a congestion notification message, characterized in that, The method includes: The source node receives a first congestion notification message from the destination node, the first congestion notification message carrying a second congestion notification message; The source node sends a second congestion notification message to the sender of the first data stream. The second congestion notification message is used to instruct the sender to control the subsequent traffic of the first data stream.

2. The method as described in claim 1, characterized in that, The method further includes: The source node decapsulates the first congestion notification message to obtain the second congestion notification message.

3. The method as described in claim 2, characterized in that, The second congestion notification message is carried in the payload of the first congestion notification message; The source node decapsulates the first congestion notification message to obtain the second congestion notification message, including: The source node strips the header of the first congestion notification message to obtain the second congestion notification message.

4. The method according to any one of claims 1-3, characterized in that, The second congestion notification message is a flow control message.

5. The method as described in claim 4, characterized in that, The second congestion notification message is used to instruct the sender to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sender to suspend the transmission of the subsequent traffic of the first data stream.

6. The method as described in claim 5, characterized in that, The flow control message includes a priority-based flow control (PFC) message, which carries a pause duration. The pause duration is used to indicate the duration for which the sender pauses sending subsequent traffic of the first data stream.

7. The method as described in claim 5, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit, and the available credit limit is 0.

8. The method as described in claim 4, characterized in that, The second congestion notification message is used to instruct the sending end to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sending end to send the subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

9. The method as described in claim 8, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

10. The method as described in claim 7 or 9, characterized in that, The method further includes: The flow control mechanism of the source node controlling the port connected to the sending end fails within the target duration.

11. A method for sending a congestion notification message, characterized in that, The method includes: The destination node generates a first congestion notification message, which carries a second congestion notification message. The destination node sends the first congestion notification message to the source node, so that the source node sends the second congestion notification message to the sender of the first data stream. The second congestion notification message is used to instruct the sender to control the subsequent traffic of the first data stream.

12. The method as described in claim 11, characterized in that, The method further includes: The destination node generates the second congestion notification message and encapsulates the second congestion notification message to obtain the first congestion notification message.

13. The method as described in claim 11 or 12, characterized in that, The second congestion notification message is a flow control message.

14. The method as described in claim 13, characterized in that, The second congestion notification message is used to instruct the sender to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sender to suspend the transmission of the subsequent traffic of the first data stream.

15. The method as described in claim 14, characterized in that, The flow control message includes a priority-based flow control (PFC) message, which carries a pause duration. The pause duration is used to indicate the duration for which the sender pauses sending subsequent traffic of the first data stream.

16. The method as described in claim 14, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit, and the available credit limit is 0.

17. The method as described in claim 13, characterized in that, The second congestion notification message is used to instruct the sending end to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sending end to send the subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

18. The method as described in claim 17, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

19. The method according to any one of claims 11-18, characterized in that, The first congestion notification message is generated when the outgoing port of the destination node used for forwarding the first data stream becomes congested. The congestion of the outgoing port includes: the queue depth of the outgoing port is greater than or equal to a first depth threshold, wherein the time of triggering the first depth threshold is earlier than the time of triggering the second depth threshold, and the second depth threshold is the queue depth of the ingoing port of the destination node used for forwarding the first data stream that triggers the flow control mechanism.

20. A system for sending congestion notification messages, characterized in that, The system includes a source node, a destination node, and a sender; The source node is used to implement the steps of the method according to any one of claims 1-10; The target node is used to implement the steps of the method according to any one of claims 11-19; The sending end is used to receive the second congestion notification message sent by the source node, and control the subsequent traffic of the first data stream based on the second congestion notification message.

21. A device for sending congestion notification messages, characterized in that, The device includes: The message receiving module is used to receive a first congestion notification message from the destination node, wherein the first congestion notification message carries a second congestion notification message; The message sending module is used to send the second congestion notification message to the sender of the first data stream, the second congestion notification message being used to instruct the sender to control the subsequent traffic of the first data stream.

22. The apparatus as claimed in claim 21, characterized in that, The device further includes: The decapsulation module is used to decapsulate the first congestion notification message to obtain the second congestion notification message.

23. The apparatus as claimed in claim 22, characterized in that, The second congestion notification message is carried in the payload of the first congestion notification message; the decapsulation module is specifically used for: The second congestion notification message is obtained by stripping the header of the first congestion notification message.

24. The apparatus according to any one of claims 21-23, characterized in that, The second congestion notification message is a flow control message.

25. The apparatus as claimed in claim 24, characterized in that, The second congestion notification message is used to instruct the sender to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sender to suspend the transmission of the subsequent traffic of the first data stream.

26. The apparatus as claimed in claim 25, characterized in that, The flow control message includes a priority-based flow control (PFC) message, which carries a pause duration. The pause duration is used to indicate the duration for which the sender pauses sending subsequent traffic of the first data stream.

27. The apparatus as claimed in claim 25, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit, and the available credit limit is 0.

28. The apparatus as claimed in claim 24, characterized in that, The second congestion notification message is used to instruct the sending end to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sending end to send the subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

29. The apparatus as claimed in claim 28, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

30. The apparatus as claimed in claim 27 or 29, characterized in that, The device further includes: A control module is used to prevent the flow control mechanism of the port connected to the sending end from failing within a target duration.

31. A device for sending congestion notification messages, characterized in that, The device includes: The message generation module is used to generate a first congestion notification message, which carries a second congestion notification message. The message sending module is used to send the first congestion notification message to the source node, so that the source node sends the second congestion notification message to the sender of the first data stream. The second congestion notification message is used to instruct the sender to control the subsequent traffic of the first data stream.

32. The apparatus as claimed in claim 31, characterized in that, The device further includes: An encapsulation module is used to generate the second congestion notification message and encapsulate the second congestion notification message to obtain the first congestion notification message.

33. The apparatus as claimed in claim 31 or 32, characterized in that, The second congestion notification message is a flow control message.

34. The apparatus as claimed in claim 33, characterized in that, The second congestion notification message is used to instruct the sender to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sender to suspend the transmission of the subsequent traffic of the first data stream.

35. The apparatus as claimed in claim 34, characterized in that, The flow control message includes a priority-based flow control (PFC) message, which carries a pause duration. The pause duration is used to indicate the duration for which the sender pauses sending subsequent traffic of the first data stream.

36. The apparatus as claimed in claim 34, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit, and the available credit limit is 0.

37. The apparatus as claimed in claim 33, characterized in that, The second congestion notification message is used to instruct the sending end to control the subsequent traffic of the first data stream, including: the second congestion notification message is used to instruct the sending end to send the subsequent traffic of the first data stream according to the amount of data that the destination node can receive.

38. The apparatus as claimed in claim 37, characterized in that, The flow control message includes a credit-based flow control message, which carries an available credit limit and the available credit limit is greater than 0.

39. The apparatus according to any one of claims 31-38, characterized in that, The first congestion notification message is generated when the outgoing port of the destination node used for forwarding the first data stream becomes congested. The congestion of the outgoing port includes: the queue depth of the outgoing port is greater than or equal to a first depth threshold, wherein the time of triggering the first depth threshold is earlier than the time of triggering the second depth threshold, and the second depth threshold is the queue depth of the ingoing port of the destination node used for forwarding the first data stream that triggers the flow control mechanism.

40. A forwarding node, characterized in that, The forwarding node includes a memory and a processor; The memory is used to store a computer program, and the processor is used to execute the computer program to implement the method for sending a congestion notification message as described in any one of claims 1-10, or to implement the method for sending a congestion notification message as described in any one of claims 11-19.

41. A chip, characterized in that, The chip includes programmable logic circuits and / or program instructions, which, when the chip is running, implement the method for sending congestion notification messages as described in any one of claims 1-10, or implement the method for sending congestion notification messages as described in any one of claims 11-19.

42. A computer-readable storage medium, characterized in that, The storage medium stores instructions that, when executed on the computer, cause the computer to perform the method for sending a congestion notification message as described in any one of claims 1-10, or the method for sending a congestion notification message as described in any one of claims 11-19.

43. A computer program product containing instructions, characterized in that, When the instruction is executed on a computer, the computer performs the method for sending a congestion notification message as described in any one of claims 1-10, or performs the method for sending a congestion notification message as described in any one of claims 11-19.

Images