Congestion control method and related device

By sensing congestion on the network device side and sending congestion control instructions to the source, the problem of congestion control mechanism failure in the existing technology is solved, achieving more accurate and real-time congestion management and improving network throughput and stability.

CN120980019APending Publication Date: 2025-11-18HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410626961.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-05-17
Publication Date
2025-11-18

AI Technical Summary

Technical Problem

Existing congestion control mechanisms rely on packet loss and latency feedback, which often leads to failure in the network, making it impossible to accurately detect the congestion level and resulting in reduced network throughput.

Method used

Congestion control is implemented on the network device side. By receiving ACK packets, port congestion indications are determined, and congestion control indications are sent to the source end based on these indications to adjust the amount of data entering the network, thereby improving the accuracy and real-time performance of congestion control.

Benefits of technology

It improves the accuracy and real-time performance of congestion control, reduces the probability of packet loss, increases network throughput, maintains high control precision in various transmission scenarios, does not affect end-side functions, and is easy to upgrade.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120980019A_ABST
    Figure CN120980019A_ABST
Patent Text Reader

Abstract

A congestion control method and a related device are applied to the technical field of communication. In the application, a network device can forward a message between a source end and a first device, locally sense a congestion degree of a network, determine a congestion indication of a port and / or a congestion indication of a TCP flow, and send a congestion control indication to the source end to instruct an end side to control a flow entering the network. The congestion control indication is related to a congestion indication determined by the network device. Accurate congestion sensing is realized at the network equipment side, the accuracy, real-time performance and effectiveness of congestion control can be improved, the probability of packet loss of the message is reduced, and the throughput of the network is improved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a congestion control method and related device. BACKGROUND

[0002] When transmitting packets through a link, multiple packets to be sent will contend for the use right of the link, and each packet participating in the contention on the link is placed in a queue to wait for transmission through the link. When too many packets contend for the same link, the queue will overflow, and the packets will have to be discarded. If packet loss often occurs, it is called network congestion. Congestion control is a mechanism for handling network congestion.

[0003] Congestion control mechanisms are widely used, and algorithms for implementing congestion control are mainly deployed on the end side. The source end (i.e., the data sender) can perceive the congestion level through packet loss and delay, trigger adjustment of the congestion window, and reduce the congestion window when the congestion level rises to reduce the packets sent by the source end. However, such a control mechanism relies on the perception of packet loss and delay, and often fails in networks that are overly sensitive to packet loss and delay feedback or have overly delayed feedback, resulting in reduced network throughput. For example, in some network devices with short buffer queues, occasional light packet loss occurs at a certain moment, at which time the network is not congested, but the congestion level is still triggered on the end side, resulting in reduced network throughput. For another example, in a long-distance transmission network, the round-trip time of data is relatively long, resulting in inaccurate determination of the congestion level. If the network is congested, the source end perceives a high delay of the congestion and cannot timely adjust the congestion level, resulting in a large number of packets being discarded. When the congestion is resolved, the source end also cannot timely reduce the congestion level, resulting in reduced network throughput.

[0004] How to improve the accuracy of the congestion control mechanism is a hot issue being studied by those skilled in the art. SUMMARY

[0005] The present application provides a congestion control method and related device, which can perceive network congestion on the network device side and instruct the end side to control the traffic entering the network based on the congestion perceived by the network device, thereby improving the accuracy, real-time performance, and effectiveness of congestion control, reducing the probability of packet loss, and improving the throughput of the network.

[0006] In a first aspect, this application provides a congestion control method, comprising: receiving a first acknowledgement (ACK) message from a first device, determining a first port based on the source address of the first ACK message, and determining a congestion indication for the first port. The first ACK message is used to provide feedback on the reception status of a first data packet, the first port is the local output port of the first data packet, and the congestion indication for the first port is used to indicate the congestion level of the first port. The congestion control method further comprises: sending a congestion control indication to the source of the first data packet, the congestion control indication being used to control the amount of data that the source can send, and the congestion control indication being related to the congestion indication of the first port.

[0007] This method can be applied to network devices, such as those implemented by hardware and / or software modules within the network device. A network device may include multiple ports (or interfaces), from which messages can be received and / or sent. For ease of description, the following explanation uses a network device as the implementing entity.

[0008] In this application, data packets and ACK packets on the endpoint are forwarded through network devices. Network devices can sense the congestion level of each local port, obtaining a congestion indication for that port. The congestion level sensed by the network device is real-time and accurate. Therefore, congestion control based on port congestion indications is timely, accurate, and effective. For example, if the queue capacity in the network device is large, the network device can sense port queuing congestion before packet loss occurs. Based on the port congestion indication, it can control the source end to reduce incoming traffic, preventing further congestion and packet loss, thus facilitating timely congestion mitigation and improving network stability. Conversely, if the queue capacity in the network device is shallow, the congestion indication may not be updated when occasional packet loss occurs, thus failing to proactively reduce incoming traffic from the source end and ensure network throughput. In summary, this application improves the accuracy, real-time performance, and effectiveness of congestion control, reduces the probability of packet loss, increases network throughput, and helps reduce flow completion time (FCT).

[0009] Moreover, this application does not rely on factors such as round-trip delay that are affected by transmission distance, which makes this application have high control accuracy in various transmission scenarios, such as long-distance transmission scenarios, short-distance transmission scenarios, or delay-sensitive scenarios.

[0010] Furthermore, the congestion control method of this application is deployed on the network side, which makes the congestion control mechanism easy to upgrade, does not affect the functionality of the terminal side, can adapt to terminal sides with different capabilities, and has good compatibility.

[0011] In this application, congestion control indications are related to congestion indicators. Since congestion indicators may indicate different levels of congestion, when port congestion occurs, rate-deceleration control is triggered, meaning the source end reduces the traffic entering the network. Conversely, when the port is not congested, rate-increase control is triggered, meaning the source end increases the traffic entering the network. Thus, based on changes in congestion indicators, the congestion control indication can adjust the amount of data the source end can send in multiple directions over a sustained period, effectively controlling network congestion while improving network throughput and reducing FCT.

[0012] In another possible implementation of the first aspect, the congestion control indicator is used to indicate a window value, which indicates the amount of data that the source can send. The window may include one or more of a congestion window, a receive window, or a send window. The indication method includes direct indication and indirect indication. A direct indication, for example, is the congestion control indicator itself, which is the window value; alternatively, the congestion control indicator may combine with other parameters (such as a window scaling factor) to indicate the window value. An indirect indication, for example, indicates which sequence number of a message (or which number of bytes of a message) the source can send, thus indirectly indicating the window value.

[0013] In some schemes, the amount of data that the source can send is determined by the sending window, the value of which can be the smaller of the congestion window and the receiving window. In the above implementation, the network device can limit the amount of data that the source can send by indicating the window value. Especially in the scheme where the congestion control indicator is used to indicate the receiving window value, it can be compatible with existing business logic on the end side without adding additional business processes.

[0014] In another possible implementation of the first aspect, the congestion control indicator is used to indicate the direction of change of the window value, such as increasing, decreasing, or maintaining. For example, when the congestion control indicator is C1, it indicates increasing the window value; when the congestion indicator is C2, it indicates decreasing the window value. Optionally, when the congestion window indicator is C3, it indicates maintaining the current window value.

[0015] For example, the congestion control indicator is used to indicate the direction of change of the receive window value, which may include, for example, increasing, decreasing, or maintaining. For instance, when the congestion control indicator is value C1, it indicates an increase in the receive window value, but note that the increase cannot exceed the receive window value reported by the destination. When the congestion indicator is value C2, it indicates a decrease in the receive window value. Optionally, when the congestion window indicator is value C3, it indicates maintaining the current receive window value.

[0016] In another possible implementation of the first aspect, the congestion control method further includes: updating the value of the window size (WIN) field in the first ACK packet, the window size field being used to carry a congestion control indication. Sending the congestion control indication to the source of the first data packet includes: sending an updated first ACK packet to the source of the first data packet. That is, the congestion control indication is carried in the first ACK packet and sent to the source.

[0017] In some schemes, the window size field is used to indicate the size of the receiving window.

[0018] In the above implementation, the congestion control indication can be carried in the window size field of the first ACK packet and sent to the source. The network device sends a modified first ACK packet to the source of the data packet to include the congestion control indication. Thus, no additional messages or signaling are needed to transmit the congestion control indication, and it is compatible with existing congestion control mechanisms. Therefore, the source does not need to respond to additional messages or signaling, improving network compatibility and stability.

[0019] In another possible implementation of the first aspect, the first ACK packet includes the address of the first device. Determining the first port based on the source address of the first ACK packet includes: performing a route lookup based on the source address of the first ACK packet to determine the first port. In some schemes, the source address of the first ACK packet is the same as the address of the first device.

[0020] In another possible implementation of the first aspect, determining the congestion indication of the first port includes: determining the congestion indication of the first port based on the identifier of the first port and a set of correspondences, wherein the set of correspondences includes the identifier of the first port and the congestion indication of the first port.

[0021] In the above implementation, the port congestion indication is stored in a mapping set and associated with the identifier of the first port. The network device can determine the congestion indication corresponding to the port in the mapping set using the port identifier. Thus, the network device only needs to update the mapping set in a timely manner to perform precise flow control on multiple TCP flows, reducing the implementation complexity of congestion control.

[0022] In some schemes, the mapping set includes congestion indicators for multiple ports. In this case, for multiple TCP flows passing through the network device, the network device can quickly obtain the congestion status of the ports corresponding to the TCP flows by querying the mapping set, and promptly instruct the end side to control the traffic entering the network device. This quick and effective control of the traffic at the end side can rapidly alleviate congestion.

[0023] In another possible implementation of the first aspect, the first ACK message further includes a first priority. The congestion indication of the first port includes a congestion indication jointly corresponding to the first port and the first priority. Determining the congestion indication of the first port includes: determining a congestion indication jointly corresponding to the first port and the first priority, wherein a congestion control indication is related to the congestion indication jointly corresponding to the first port and the first priority, and the congestion control indication is used to control the amount of data with the first priority that the source can send.

[0024] In the above implementation, based on the outgoing port and priority of the data packet corresponding to the ACK packet, the congestion level when sending a packet of a certain priority from a certain outgoing port can be queried, thereby accurately controlling the traffic of a certain priority. Congestion control at the granularity of port + priority improves the accuracy of congestion control, ensuring that traffic of priorities that are not congested is not restricted, which is beneficial to improving network throughput.

[0025] In another possible implementation of the first aspect, determining the congestion indication that both the first port and the first priority correspond to includes: determining the congestion indication that both the first port and the first priority correspond to based on the identifier of the first port and a set of correspondences, wherein the set of correspondences includes the identifier of the first port, the first priority, and the congestion indication that both the first port and the first priority correspond to.

[0026] In the above implementation, the port congestion indication is stored in a mapping set and associated with the identifier and priority of the first port. The network device can determine the congestion indication corresponding to both the port and priority in the mapping set using the port identifier and priority. Thus, the network device only needs to update the mapping set in a timely manner to perform precise flow control on multiple TCP flows, reducing the implementation complexity of congestion control.

[0027] In another possible implementation of the first aspect, the congestion control method further includes: detecting the local queue of the first port to obtain queuing information of the local queue of the first port. The congestion indication of the first port is related to the queuing information of the local queue of the first port.

[0028] For example, determining the congestion indication of the first port includes: determining the congestion indication of the first port based on queuing information of the local queue of the first port.

[0029] As another example, the congestion control method further includes: obtaining a congestion indication for the first port based on the queuing information of the local queue of the first port and saving it to a correspondence set. That is, the network device can generate a congestion indication for the first port based on the queuing information of the local queue of the first port, and update the congestion indication corresponding to the identifier of the first port in the correspondence set. Further, determining the congestion indication for the first port includes: determining the congestion indication for the first port based on the identifier of the first port and the correspondence set.

[0030] In the above implementation, the network device senses the congestion level and updates the congestion indication based on the queuing information of the local port, which can more accurately determine the network congestion level and obtain the congestion indication, so as to perform congestion control on the source end of the TCP flow passing through the first port, improve the real-time performance, accuracy and effectiveness of congestion control, reduce the probability of packet loss, and improve the network throughput.

[0031] In some solutions, if the queues in the network device are shallow, the congestion probability can be determined based on the number of packets in the queue. Occasional minor packet loss will trigger timely updates to the port congestion level during the next queue check, reducing the probability of triggering a rate reduction and improving network throughput while lowering FCT. In other solutions, if the queues in the network device are deep, the congestion probability can be determined based on the proportion of packets in the queue, enabling rate reductions to be triggered even without packet loss, thus preventing network congestion. In summary, the solution proposed in this application allows network devices to more intelligently determine the congestion probability, further improving the accuracy of congestion control.

[0032] In another possible implementation of the first aspect, the congestion control method further includes: detecting the local queues of multiple ports in the network device to obtain queuing information of the local queues of multiple ports, and obtaining congestion indications for each of the multiple ports based on the queuing information of the local queues of multiple ports.

[0033] Furthermore, the congestion control method also includes updating the congestion indications corresponding to the identifiers of multiple ports in the correspondence set.

[0034] In the above embodiments, the network device can scan the queuing information of multiple local ports to obtain congestion indications for multiple ports, thereby enabling congestion control of multiple TCP flows passing through the network device. For example, the multiple ports include a first port and a second port. Thus, the network device can also perform high-precision congestion control for the TCP flow on the second port, improving the practicality of congestion control.

[0035] In another possible implementation of the first aspect, the period for detecting the local queue is less than 1 millisecond (ms). This allows the network device to achieve high-precision real-time sampling, significantly improving the real-time performance and accuracy of congestion control. Similarly, scanning multiple local ports can be periodic, for example, performing port queue scanning at a period of less than 1 ms.

[0036] In yet another possible implementation of the first aspect, the local queue of the first port includes the port queue corresponding to the first port.

[0037] In yet another possible implementation of the first aspect, the local queue of the first port includes multiple priority queues corresponding to the first port.

[0038] In yet another possible implementation of the first aspect, the congestion control method further includes: determining a congestion control instruction based on a congestion instruction.

[0039] In another possible implementation of the first aspect, the congestion control method further includes: determining a congestion control indication based at least on a first parameter, the first parameter being determined by a congestion indication of a first port, the first parameter being used to indicate the amount of data that the source can send.

[0040] In another possible implementation of the first aspect, the congestion control method further includes: when the congestion indication of the first port meets the flow suppression condition, reducing the first parameter to a preset reference value and using the reference value as the base value of the first parameter; when the congestion indication of the first port does not meet the flow suppression condition, increasing the first parameter by a first value to obtain a new base value for the first parameter.

[0041] In this implementation, if the traffic suppression condition is met, the network device will significantly reduce the value of the first parameter; if the traffic suppression condition is not met, the value of the first parameter will be slowly increased. Since the first parameter indicates a window value, this implementation can quickly reduce the network device's traffic in the event of congestion or suspected congestion, allowing congestion to be controlled as soon as possible. When congestion has subsided or has not occurred, this implementation can control the slow increase of traffic, preventing the recurrence of congestion and improving network stability.

[0042] In another possible implementation of the first aspect, the first value is less than half the width of the range of values ​​for the first parameter, for example, less than 1 / 4, 1 / 6, or 1 / 8 of the width of the range of values ​​for the first parameter. Designing the first value to be relatively small can slow down the rate of increase in traffic and avoid new congestion caused by a sudden and large increase in traffic.

[0043] In another possible implementation of the first aspect, the first ACK message further includes a window scaling factor field. Determining the congestion control indication based at least on the first parameter includes: determining the congestion control indication based on the value of the first parameter and the window scaling factor field, the window scaling factor field being used to indicate the multiple by which the receive window value is scaled.

[0044] The above implementation takes into account the impact of the window expansion factor on the window value. By combining the window expansion factor to determine the congestion control indication, the amount of data that the source can send can be more accurately indicated, thus improving the accuracy of congestion control.

[0045] Secondly, this application provides a congestion control method, comprising: receiving a first ACK packet from a first device, determining a congestion indication of a first TCP stream, and sending a congestion control indication to the source of a first data packet. The first ACK packet includes a first source address and a first destination address; the first TCP stream is a TCP stream between the first source address and the first destination address; the congestion indication of the first TCP stream is used to indicate the congestion level of the first TCP stream; and the congestion control indication is used to control the amount of data that the source can send, and the congestion control indication is related to the congestion indication of a first port.

[0046] This method can be applied to network devices, such as those implemented by hardware and / or software modules within the network device. A network device may include multiple ports (or interfaces), from which messages can be received and sent. For ease of distinction later, the following description will focus on the first network device as the implementing entity.

[0047] In this application, the first network device can locally sense the congestion level of a TCP stream, determine the congestion indication of the TCP stream, and instruct the end-side to control the traffic entering the network device through a congestion control indication. Since the congestion control indication is related to the congestion indication, which may indicate different levels of congestion, when congestion occurs in the TCP stream, a rate-deceleration control is triggered, i.e., the source end is controlled to reduce the traffic entering the network. Conversely, when no congestion occurs in the TCP stream, a rate-increase control is triggered, i.e., the source end is controlled to increase the traffic entering the network. Thus, based on changes in the congestion indication, the congestion control indication can adjust the amount of data that the source end can send in multiple directions over a continuous period of time, effectively controlling network congestion while improving network throughput and reducing FCT.

[0048] Moreover, in this application, the network device implements congestion control based on locally determined congestion indicators, without relying on factors such as round-trip delay that are affected by transmission distance. This makes the application have high control accuracy in various transmission scenarios, such as long-distance transmission scenarios, short-distance transmission scenarios, or latency-sensitive scenarios.

[0049] Furthermore, the congestion control method of this application is deployed on the network side, which makes the congestion control mechanism easy to upgrade, does not affect the functionality of the terminal side, can adapt to terminal sides with different capabilities, and has good compatibility.

[0050] In one possible implementation of the second aspect, the congestion control indicator is used to indicate a window value, which indicates the amount of data that the source can send. The window may include one or more of a congestion window, a receive window, or a send window. The indication method includes direct indication and indirect indication.

[0051] In another possible implementation of the second aspect, the congestion control method further includes: updating the value of the window size field in the first ACK packet, the window size field being used to carry a congestion control indication. Sending the congestion control indication to the source of the first data packet includes: sending an updated first ACK packet to the source of the first data packet.

[0052] In some schemes, the window size field is used to indicate the size of the receiving window.

[0053] In yet another possible implementation of the second aspect, the congestion control method further includes: determining a first-order identifier based on a first source address, a first destination address, and a data flow table. For example, a first network device determines the first-order identifier by looking up the data flow table based on the first source address and the first destination address.

[0054] In another possible implementation of the second aspect, determining the congestion indication of the first TCP stream includes: determining the congestion indication of the first TCP stream based on the identifier of the first TCP stream and a set of correspondences, wherein the set of correspondences includes the identifier of the first TCP stream and the congestion indication corresponding to the first TCP stream.

[0055] In the above implementation, the congestion indication of a TCP stream is stored in a mapping set and associated with the stream's identifier. The network device can determine the congestion indication corresponding to a stream from the mapping set using the stream's identifier. Thus, the network device only needs to update the mapping set in a timely manner to perform precise flow control on multiple TCP streams, reducing the implementation complexity of congestion control.

[0056] Optionally, the mapping set includes the identifier of the flow passing through the forwarding device and the congestion indication of the flow. Thus, for multiple TCP flows passing through the network device, the network device can quickly obtain the congestion status of a specified TCP flow by querying the mapping set, and promptly instruct multiple endpoints to control the traffic entering the network, thereby quickly and effectively controlling the traffic flowing into the network from multiple endpoints and achieving congestion control.

[0057] In another possible implementation of the second aspect, the congestion control method further includes: determining a congestion indication for the first TCP stream based on congestion data corresponding to the first TCP stream. The congestion data corresponding to the first TCP stream includes one or more of the following: the number of packets in the first TCP stream marked as congested, the proportion of packets in the first TCP stream marked as congested, the number of packets in the first TCP stream not marked as congested, and the proportion of packets in the first TCP stream not marked as congested.

[0058] In the above implementation, packets can be marked as congested or not congested, and network devices can locally detect TCP stream congestion data based on the congestion markings of packets. By having network devices detect the congestion level of TCP streams based on congestion data, the probability of network congestion can be more accurately determined, and congestion indications can be generated.

[0059] Furthermore, the congestion indication can be saved to the corresponding relationship set (which can then be used to update the corresponding relationship set) to perform congestion control on the source end of the TCP stream, thereby improving the real-time performance, accuracy, and effectiveness of congestion control, reducing the probability of packet loss, and increasing network throughput.

[0060] Optionally, the messages in a TCP stream may include data packets and / or ACK packets. For example, by only recording the congestion flags of data packets in the TCP stream, congestion data can be obtained, thereby determining the congestion status of the source network.

[0061] In another possible implementation of the second aspect, the congestion data corresponding to the first TCP stream includes at least one of the following:

[0062] The number of packets marked as congested in the first TCP stream within the first time period, the percentage of packets marked as congested in the first TCP stream within the first time period, the number of packets not marked as congested in the first TCP stream within the second time period, and the percentage of packets not marked as congested in the first TCP stream within the second time period.

[0063] The aforementioned first and second time periods represent a certain aging design for congestion data. For example, after the first time period, packets marked as congested are no longer included in the statistical data, making the network congestion situation reflected by the congestion data more accurate and improving the accuracy of the network congestion control mechanism.

[0064] In another possible implementation of the second aspect, the congestion control method further includes: receiving a first data packet forwarded from a second network device, the first data packet including a source address, a destination address, and a congestion notification field, the congestion notification field including a marker indicating whether congestion has occurred in the network traversed by the first data packet. The congestion control method further includes: updating congestion data corresponding to the first TCP stream based on the source address, destination address, and value of the congestion notification field of the first data packet.

[0065] In the above implementation, the second network device can forward data packets from the source end, and the data packets include a congestion notification field. When a data packet passes through the second network device, if network congestion occurs, the second network device can update the value of the congestion notification field to indicate network congestion. The network device can update the congestion data of the TCP stream of the data packet based on the source address, destination address, and the value of the congestion notification field. This allows for accurate perception of the TCP stream congestion status at the source network, reducing traffic entering the network from the source when the source network is congested, and increasing traffic entering the network from the source when the source network is not congested, thus improving the accuracy of congestion control. Here, the source network refers to the network between the source end and the network device, i.e., the network through which the data packet passes before reaching the network device.

[0066] For example, if the congestion notification field of a datagram indicates that the network through which the datagram passed is congested, the number of packets marked as congested in the TCP stream is incremented by 1. Similarly, if the congestion notification field of a datagram indicates that the network through which the datagram passed is not congested, the number of packets marked as not congested in the TCP stream is incremented by 1. This numerical update can be replaced with a proportional update.

[0067] Optionally, the congestion notification field can be an explicit congestion notification (ECN) field, compatible with existing congestion notification protocols. That is, the first network device can record the number and proportion of ECN fields in TCP stream packets over a period of time (e.g., the aforementioned first or second time period) to assess the congestion situation of the source network. By sensing the congestion situation of the source network through packet ECN fields, congestion control can be implemented at the network device level, with high feasibility and lower development costs.

[0068] In another possible implementation of the second aspect, the congestion control method further includes: determining a congestion control indication based on a congestion indication.

[0069] In another possible implementation of the second aspect, the congestion control method further includes: determining a congestion control indication based at least on a first parameter, the first parameter being determined by a congestion indication of a first TCP stream, the first parameter being used to indicate the amount of data that the source can send.

[0070] In another possible implementation of the second aspect, the congestion control method further includes: when the congestion indication of the first TCP stream meets the flow suppression condition, reducing the first parameter to a preset baseline value and using the baseline value as the base value of the first parameter; when the congestion indication of the first TCP stream does not meet the flow suppression condition, increasing the first parameter by a first value to obtain a new base value for the first parameter.

[0071] In this implementation, if the traffic suppression condition is met, the network device will significantly reduce the value of the first parameter; if the traffic suppression condition is not met, the value of the first parameter will be slowly increased. Since the first parameter indicates a window value, this implementation can quickly reduce the network device's traffic in the event of congestion or suspected congestion, allowing congestion to be controlled as soon as possible. When congestion has subsided or has not occurred, this implementation can control the slow increase of traffic, preventing the recurrence of congestion and improving network stability.

[0072] In another possible implementation of the second aspect, the first value is less than half the width of the range of values ​​for the first parameter, for example, less than 1 / 4, 1 / 6, or 1 / 8 of the width of the range of values ​​for the first parameter. Designing the first value to be relatively small can slow down the rate of increase in traffic and avoid new congestion caused by a sudden and large increase in traffic.

[0073] In another possible implementation of the second aspect, the first ACK message further includes a window scaling factor field. Determining the congestion control indication based at least on the first parameter includes: determining the congestion control indication based on the value of the first parameter and the window scaling factor field, the window scaling factor field being used to indicate the multiple by which the receive window value is scaled.

[0074] The above implementation takes into account the impact of the window expansion factor on the window value. By combining the window expansion factor to determine the congestion control indication, the amount of data that the source can send can be more accurately indicated, thus improving the accuracy of congestion control.

[0075] Thirdly, this application provides a congestion control device, which includes a communication unit and a processing unit. The communication unit is used to send and / or receive data, or to input and / or output data. The processing unit is used to perform computational operations. This congestion control device is used to implement the method described in the first aspect or any possible embodiment of the first aspect.

[0076] For example, the communication unit is used to implement operations such as receiving, sending, and acquiring. The processing unit is used to implement the aforementioned operations such as information processing, data generation, determination, decision-making, judgment, or updating.

[0077] Fourthly, this application provides a congestion control device, which includes a communication unit and a processing unit. The communication unit is used to send and / or receive data, or to input and / or output data. The processing unit is used to perform computational operations. This congestion control device is used to implement the method described in the second aspect or any possible embodiment of the second aspect.

[0078] For example, the communication unit is used to implement operations such as receiving, sending, and acquiring. The processing unit is used to implement the aforementioned operations such as information processing, data generation, determination, decision-making, judgment, or updating.

[0079] Fifthly, this application provides a chip including a processor and a communication interface. The communication interface is used for outputting and / or outputting data (including instructions), and / or for receiving and / or sending data. The processor is used to execute program instructions to implement the method described in the first aspect or any possible embodiment of the first aspect, or to implement the method described in the second aspect or any possible embodiment of the second aspect.

[0080] Sixthly, this application provides a network device including multiple ports, a processor, and a memory. The multiple ports are used to send and / or receive messages. The memory is used to store program instructions, and the processor is used to execute the program instructions stored in the memory to implement the method described in the first aspect or any possible implementation of the first aspect, or to implement the method described in the second aspect or any possible implementation of the second aspect.

[0081] In a seventh aspect, this application provides a communication system including a first network device, a source end, and a first device. The first device is the destination end. The first network device is used to forward messages between the source end and the first device. The first network device includes congestion control devices as described in the third and / or fourth aspects, or the first network device includes a chip as described in the fifth aspect, or the first network device is the network device described in the sixth aspect.

[0082] Optionally, the communication system further includes a second network device, which is used to forward data packets from the source to the first network device and to forward ACK packets forwarded by the first network device to the source.

[0083] Eighthly, this application provides a computer program product, including program instructions or executable computer program code, which, when executed by at least one processor, causes a network device in which the at least one processor resides to implement the method described in the first aspect or any possible implementation of the first aspect, or to implement the method described in the second aspect or any possible implementation of the second aspect.

[0084] Ninthly, this application provides a computer-readable storage medium storing program instructions that, when executed by a processor, cause a network device in which the processor resides to implement the method described in the first aspect or any possible implementation of the first aspect. Attached Figure Description

[0085] The accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0086] Figure 1 This is a schematic diagram of the architecture of a communication system;

[0087] Figure 2 This is a schematic diagram of a hierarchical network architecture.

[0088] Figure 3 This is a schematic diagram of the architecture of another communication system;

[0089] Figure 4 This is a schematic diagram of a backbone network architecture;

[0090] Figure 5 This is a flowchart illustrating a congestion control method provided in an embodiment of this application;

[0091] Figure 6 This is a schematic diagram of the queuing situation of a local queue of a network device provided in an embodiment of this application;

[0092] Figure 7 This is a schematic diagram illustrating the operation process of a congestion control method provided in an embodiment of this application;

[0093] Figure 8 This is a schematic diagram of the timeline for updating a first parameter provided in an embodiment of this application;

[0094] Figure 9A This is a schematic diagram of a message format;

[0095] Figure 9B This is a diagram illustrating yet another message format;

[0096] Figure 10 This is a flowchart of yet another congestion control method provided in the embodiments of this application;

[0097] Figure 11 This is a schematic diagram of a congestion control mechanism provided in an embodiment of this application;

[0098] Figure 12 This is a flowchart of yet another congestion control method provided in the embodiments of this application;

[0099] Figure 13 This is a schematic diagram illustrating a method for obtaining congestion data provided in an embodiment of this application;

[0100] Figure 14 This is a schematic diagram of the structure of a congestion control device provided in an embodiment of this application;

[0101] Figure 15 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. Detailed Implementation

[0102] Before introducing the embodiments of this application, the terminology that may be used in the embodiments of this application will be introduced first.

[0103] 1. The receive window (RWND) indicates the amount of data that the receiver (i.e., the destination) of a TCP stream can receive. The destination sends the RWND value back to the source along with an ACK packet. In some schemes, it is also referred to as the receiver's sliding window.

[0104] 2. The congestion window (CWND), also known as the sending window, is a state variable maintained by the Transmission Control Protocol (TCP). The source uses the congestion window to limit the amount of data allowed to be transmitted within a given time. Therefore, the congestion window is used to limit the total number of undetermined packets that may be transmitted between end-to-end.

[0105] 3. Sending window: A state variable maintained by the sender (i.e., the source) of a TCP stream, used to limit the number of packets or data that the sender can send but whose size is uncertain. The sending window is usually the smaller of CWND and RWND.

[0106] 4. ACK message: In TCP / Internet Protocol (IP), after the source sends a data packet to the destination, if the destination successfully receives the data packet, the destination will send an ACK message to the source to indicate that the receiver of the TCP stream has received the corresponding data packet.

[0107] 5. Explicit Congestion Notification (ECN) is a congestion control mechanism defined by the Internet Engineering Task Force (IETF). Before initiating TCP stream transmission, the sender and receiver of a TCP stream need to negotiate ECN to ensure both support the ECN mechanism. Before sending a datagram to the receiver, the sender enables the ECN flag in the datagram. Network devices can update the value of the ECN field (or ECN flag) to indicate the network congestion status. For example, the source might send a datagram with an ECN flag value of 01 (binary) or 10. When the datagram is forwarded by network devices and network congestion occurs, the network devices will add an ECN flag to the datagram (e.g., changing the ECN field value to 11) to indicate network congestion.

[0108] 6. Port queues, which are the packet queues corresponding to ports. On network devices, packets are arranged in queues and forwarded from the outgoing port according to certain rules. When a network device has multiple ports, each port can have its own corresponding queue. In specific implementations, various algorithms can be used to implement packet queuing and scheduling, such as First In First Out (FIFO), Round Robin (RR), Weighted RR (WRR), Deficit RR (DRR), Urgency-based RR (URR), Priority Queue (PQ), Fair Queue (FQ), and Weighted Fair Queue (WFQ).

[0109] For example, port A of a network device can correspond to a queue Q1, which is used to arrange packets to be forwarded from port A. As another example, port B of a network device can correspond to multiple queues, all of which are used to arrange packets to be forwarded from port B. Furthermore, these multiple queues can correspond to different priorities, and / or different services, and / or different users. It should be understood that a user can have different definitions in different scenarios; for example, a user can specifically refer to a network, a group of connections, or a device. For instance, a user can be a Virtual Local Area Network (VLAN) or a Virtual Private Network (VPN), etc.

[0110] 7. Priority: Messages can be marked with priorities to distinguish different types of traffic. Network devices can determine the processing order of messages based on priority markings when forwarding them, thus achieving differentiated transmission of messages with different priorities. Three priority classification schemes are described below:

[0111] Option 1 uses 802.1p user priority to classify packets by priority. 802.1p user priority, also known as Class of Service (COS) priority, is defined in the Tag Control Information (TCI) field of the Layer 2 802.1Q tag header. It is 3 bits long and ranges from 0 to 7, with 0 being the lowest priority. An example priority (represented in the form of "priority" - "name") is as follows: 7 - Network Control; 6 - Internet Control; 5 - Voice; 4 - Video; 3 - Critical Application; 2 - Best Effort; 1 - Best Effort; 0 - Background.

[0112] Option 2 uses IP priority to classify packets by priority. IP priority is defined in the Type of Service (TOS) field (8 bits) of the Layer 3 IP header, including a high-order 3-bit priority portion, a middle 4-bit service type portion (also called TOS priority), and a low-order 1-bit unused portion. The priority portion ranges from 0 to 7, with 0 being the lowest priority and 7 the highest.

[0113] An exemplary priority (represented in the form of "priority (binary representation)" - "name (English name / Chinese name)") is as follows: 111 - Network Control; 110 - Internetwork Control; 101 - Critic; 100 - FlashOverride; 011 - Flash; 010 - Immediate; 001 - Priority; 000 - Routine. Priorities 6 and 7 are generally reserved for network control data, such as routing, while priority 5 is recommended for voice data. Priority 4 is used for video conferencing and video streaming, priority 3 is used for voice control data, priorities 1 and 2 are used for data services, and priority 0 is the default value. When labeling data, either numerical values ​​or names (English names) can be used.

[0114] Option 3 uses DSCP priority to classify messages by priority. DSCP priority is also defined in the TOS field, occupying the high 6 bits of the TOS field, with a value range of 0-63, where 0 is the lowest priority and 63 is the highest priority.

[0115] Of course, there may be more priority classification schemes in the actual implementation. This application does not strictly limit the priority classification method related to the priority queue of the port.

[0116] The explanation of the terms above may be adapted to use the examples below.

[0117] The following describes the system architecture and scenarios to which this application can be applied. It should be noted that the architecture and application scenarios of the device described in this application are for the purpose of more clearly illustrating the technical solution of this application, and do not constitute a limitation on the technical solution provided by this application. As those skilled in the art will know, with the evolution of architecture and the emergence of new business scenarios, the technical solution provided by this application is also applicable to similar technical problems.

[0118] Please see Figure 1 , Figure 1 This is a schematic diagram of a communication system architecture. The communication system 100 includes a source end 101, a destination end 102, and a first network device 103. The source end 101 is the sender of the TCP stream, i.e., the device that sends data packets. The source end 101 can be a physical device or a virtual device. Physical devices include, for example, a data center (DC), a server, or a terminal device. The server can be a single server or a server cluster. Virtual devices include, for example, virtual computing instances or cloud environments. Computing instances can include virtual machines or containers, and cloud environments can include private clouds, public clouds, or hybrid clouds.

[0119] Destination 102 is the receiver of the TCP stream, i.e., the device that receives data packets. Similarly, destination 102 can be a physical device or a virtual device; for specific implementation details, please refer to the aforementioned enumeration of physical and virtual devices.

[0120] The first network device 103 is used to implement communication between the source end 101 and the destination end 102. It can forward data packets from the source end 101 to the destination end 102, and forward ACK packets sent from the destination end 102 to the source end 101. The first network device 103 typically includes multiple ports, or interfaces, which are used to receive and / or send packets. Figure 1 Source 101 can send data packets to destination 102. These data packets are received from one port of the first network device 103 and forwarded to another port of the first network device 103, enabling destination 102 to receive the data packets. Destination 102 can then send an ACK packet, which is forwarded back to source 101 via the first network device 103. For example, the first network device 103 may include a router or a switch. It should be understood that the specific location of the first network device 103 in the network can have various possible designs; for example, the first network device may be located at the access layer, aggregation layer, or core layer of the network.

[0121] In some schemes, the source end 101 and the destination end 102 can be directly connected through the first network device 103.

[0122] In some other solutions, the connection between the source 101 and the destination 102 may involve one or more other network devices besides the first network device. As a possible example, such as... Figure 1 A second network device 104 may also be included between the source device 101 and the first network device 103. The second network device 104 can forward packets from the source device 101 to the first network device 103, and forward packets forwarded by the first network device 103 to the source device 101. In some scenarios, the second network device 104 is a device in the source network, which can refer to the network connected to the source device 101. Alternatively, the source network can also be the network close to the source from the perspective of the first network device 103, that is, the network between the first network device 103 and the source device 101.

[0123] In some schemes, the first network device 103 may be a device in a hierarchical network. The following is an example of a hierarchical network architecture. The hierarchical network architecture may include one or more of the following layers: access layer, aggregation layer, and core layer. Different layers are used to perform different functions; in other words, the network functions performed by the network devices included in different layers are also different.

[0124] In one possible implementation, a number of representative network devices are used to characterize the network devices included in each layer. See also... Figure 2 Customer edge (CE) routers are used to represent network devices in the access layer, provider edge (PE) routers are used to represent network devices in the aggregation layer, and provider backbone (P) routers are used to represent network devices in the core layer. Specifically, the CE is the user-end router connected to the service provider, used to provide service access to users. In specific implementations, the CE may include access layer switches or wireless access points (APs). The PE is the edge router of the service provider's backbone network, connecting the CE and P. In summary, some schemes use CE, PE, and P to represent the network functions of network devices in the access layer, aggregation layer, and core layer, respectively.

[0125] Combination Figure 1 and Figure 2 The source end 101 can be a DC or a client, and the destination end can be a DC or a client. The first network device 103 can be a network device in the aggregation layer, access layer, or core layer, such as CE, PE, or P, or one or more of these. It should be noted that CE, PE, and P are names used by operators for routers with specific functions in certain scenarios. In other scenarios, routers with the same function as PE (or CE, or P) may have different names. For example, a router with the same (or similar) function as PE may be called an access router (AR) or a service router (SR), and a router with the same (or similar) function as P may be called a broadband router (BR) or a core router (CR). Furthermore, in specific implementations, the access layer, aggregation layer, and core layer can each include one or more network devices. Figure 2 The number and types of equipment shown are for illustrative purposes only.

[0126] In some possible implementations, in addition to the CE, PE, P, AR, SR, BR, and CR mentioned above, the network may also include one or more of the following network devices: clients (e.g., handheld terminals, hosts, laptops, tablets, or wearable devices), data centers, route reflectors (RR), optical transport networks (OTN), content delivery networks (CDN), broadband network gateways (BNG), broadband remote access servers (BRAS), network provider edges (NPE) on the network side, user-end provider edges (UPE) on the user side, superstratum provider edges (SPE), optical line terminals (OLT), etc.

[0127] A Data Center (DC) is a central storage facility for information and data, used by networked enterprises or organizations to store, manage, and transmit data. DCs can house computer systems and related components (such as telecommunications and storage systems). A Router Receiver (RR), a special type of router, serves as the central point for storing and forwarding routing entries across the entire network, distributing routing information to other routers. The Optical Transmission Network (OTN) is a transport network based on wavelength division multiplexing (WDM) technology, organized at the optical layer. A Content Delivery Network (CDN) is a content delivery network built on top of a network. Relying on edge servers deployed in various locations, it uses load balancing, content distribution, and scheduling modules on a central platform to allow users to access content from the nearest location, reducing network congestion and improving user access response speed and hit rate. A Network Generation Service (BNG) is used to translate Dynamic Host Configuration Protocol (DHCP) messages into Remote Authentication Dial in User Service (RADIUS) authentication messages, and bills for traffic / duration passing through the device after successful authentication. A BRAS (Broadband Access Controller) is a new type of access gateway for broadband network applications. Located at the edge layer of the backbone network, the BRAS enables data access for users via Internet Protocol Address (IP) / Asynchronous Transfer Mode (ATM) networks, providing broadband internet access for commercial buildings and residential communities. An NPE (Network Provider Equipment) is a router located at the network provider's premises. A UPE (User Equipment Equipment) is a PE (Provider Edge Equipment) directly connected to the CE (Center Edge). An SPE (Service Provider Equipment) is a core device connected to the UPE and located within a fully connected Virtual Private LAN (VPLS) network. An OLT (Optical Line Terminal) is a terminal device used to connect to the fiber optic backbone.

[0128] In some solutions, the communication system may include more network devices; please refer to [link / reference]. Figure 3 , Figure 3This is a schematic diagram of another communication system architecture. Communication system 100 includes a source end 101, a first network 1041, an access layer network device 1031, an aggregation layer network device 1032, a core layer network device 1033, a second network 1042, and a third network. The first network 1041 is located near the source end 101, while the third network is located near the destination end 102. The first network 1041 and the third network may each include one or more network devices. For example, the first network 1041 may include the access layer network device 1031 or a wireless access point (AP). The second network 1042 can be a core network and may include one or more network devices, such as P and RR devices. The access layer network device 1031 connects the first network 1041 and the aggregation layer network device 1032. For example, the access layer network device 1031 may be a CE (Center Edge) device or an access layer router. Aggregation layer network device 1032 is a forwarding device connecting access layer network device 1031 and core layer network device 1033. For example, aggregation layer network device 1032 can be a PE (Preinstallation Equipment) or other aggregation layer network devices. Core layer network device 1033 can be a core layer forwarding device, such as a P (Preinstallation Equipment). Figure 1 The first network device 103 can be Figure 2 The network devices in the access layer network device 1031, aggregation layer network device 1032, core layer network device 1033, first network 1041, or second network are network devices in the network.

[0129] In some scenarios, the network comprised of the core layer, or the network comprised of the core layer and the aggregation layer, can be referred to as the backbone network. Please see [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram of a backbone network architecture. The ADC and BDC are located in cities A and B, respectively. Backbone network equipment includes P (DC-P) connected to DCs, PE (DC-PE) connected to DCs, P (WAN-P) connected to wide area networks (WAN), and PE (WAN-PE) connected to WANs. Backbone network interface routers (which can be considered CEs) are used for DC access to the backbone network. DC-PEs act as data center access routers, aggregating services from data centers and connecting other organizations within the same city. WAN-Ps are used to aggregate services from client networks in city C. RRs are used to reflect backbone network area routes. BR-PEs act as access routers for client networks, enabling client networks to access the backbone network. Backbone network interface switches are used to enable client networks to access the backbone network. Client networks may include wireless APs, clients, etc.

[0130] Combination Figure 1 and Figure 4The source end 101 can be a client in the client network, or data center A, or data center B. Similarly, the destination end 102 can be a client in the client network, or data center A, or data center B. The first network device 103 can be a PE, CE (such as a backbone network router, backbone network switch, etc.).

[0131] In some embodiments, the first network device 103 is a near-end network device, that is, a network device close to the end side. Here, "close" can be understood as the first network device 103 being relatively close to the end side. This distance can be time distance, physical distance, or network distance (such as hop count), etc.

[0132] As one possible implementation, the communication latency between the first network device 103 and the source device 101 is less than 1ms.

[0133] As another possible implementation, the physical distance between the first network device 103 and the source device 101 is less than 100km.

[0134] As another possible implementation, the first network device 103 is an access layer network device or an aggregation layer network device.

[0135] It should be noted that the number of network devices in the aforementioned network is for illustrative purposes only, and this application does not limit the number of network devices or the connection method in the communication system.

[0136] The foregoing Figure 1 to Figure 4 Most communication systems can transmit TCP streams. As the number of devices in a network increases, TCP streams may encounter network congestion during transmission, requiring corresponding congestion control mechanisms to improve network stability. Currently, network congestion control mechanisms are mainly implemented at the endpoint, such as the source end sensing network congestion through packet loss and latency. Such congestion control mechanisms often fail in networks that are overly sensitive to packet loss and latency feedback or have excessively delayed feedback, easily leading to reduced network throughput. For example, in long-distance networks, end-to-end packets may need to traverse multiple complex networks, resulting in long round-trip times, affecting the endpoint's perception of packet loss and latency, leading to inaccurate determination of the congestion level. If network congestion occurs, the endpoint may struggle to promptly escalate the congestion level, causing a large number of packets to be dropped; conversely, when congestion subsides, the endpoint may also struggle to promptly de-escalate the congestion level, resulting in reduced network throughput.

[0137] In view of this, this application provides a congestion control method and related apparatus, which can achieve local congestion awareness at the network device side. Specifically, since data packets and ACK packets at the endpoint are forwarded through the network device, the network device can locally perceive the degree of congestion and instruct the endpoint to control the traffic entering the network based on the congestion situation perceived by the network device. This improves the real-time performance, accuracy, and effectiveness of congestion control, reduces the probability of packet loss, and increases network throughput. In some further schemes, the network device can maintain a set of correspondences to record the locally perceived degree of congestion. The set of correspondences can instantly and quickly query the congestion level of a specified port or a specified TCP stream, significantly improving the real-time performance, accuracy, and effectiveness of congestion control.

[0138] The structure and background of this application have been explained above. The method of this application will be introduced below.

[0139] Please see Figure 5 , Figure 5 This is a flowchart illustrating a congestion control method provided in an embodiment of this application. Optionally, this method is applied to the aforementioned communication system, such as... Figure 1 , Figure 2 , Figure 3 or Figure 4 The communication system shown. (As shown) Figure 5 The congestion control method shown may include one or more steps from S501 to S504. It should be understood that, for ease of description, the method is described in the order of steps S501 to S504, but this embodiment does not limit the order of execution, the execution time, or the number of executions of the above one or more steps. Steps S501 to S504 are as follows:

[0140] Step S501: The network device receives the first ACK packet.

[0141] Network devices are devices capable of forwarding packets, such as switches or routers. For example, a network device can be... Figure 1 The first network device 103 is shown. Further, the network device is a near-end network device; for an explanation of "near-end," please refer to the foregoing.

[0142] ACK messages are used to indicate the reception status of data packets. During data communication, the sender of a TCP stream sends data to the receiver of the TCP stream, and the receiver, after confirming that the data has been received correctly, sends an ACK message back to the sender of the TCP stream, indicating that the data has been received correctly.

[0143] like Figure 5As shown, the source sends a first datagram to the first device (the receiver of the TCP stream). The first datagram is forwarded to the first device via the network device. In other words, the source is the sender of the TCP stream, and the first device (the destination) is the receiver of the TCP stream. After receiving the first datagram, the first device sends a first ACK packet back to the source to indicate the reception status. This first ACK packet passes through the network device, so the network device can receive it. In some schemes, the ACK packet includes indication information of the received data, indicating the sequence number or serial number of the currently received data.

[0144] In this embodiment of the application, the first ACK packet carries information indicating the sender of the first ACK packet, such as the address of the source of the first ACK packet, referred to simply as the source address. Combined with... Figure 5 If the first ACK packet originates from the first device, then the first ACK packet carries the address of the first device. In some schemes, this source address can be an Internet Protocol (IP) address, i.e., source IP (SIP). This article uses an IP address as the source address as an example for explanation, and the same applies to other methods of identifying the source address.

[0145] Furthermore, the first ACK packet may also carry information indicating the receiving end of the first ACK packet, such as the destination address. Similarly, the destination address in the first ACK packet can be an Internet Protocol address, simply referred to as the destination IP (DIP). Figure 5 The first ACK message is used to report the reception status of the first data packet to the source end. The first ACK message also includes the address of the source end.

[0146] In some possible implementations, the first ACK packet also carries priority information, such as a priority flag. This priority information indicates the priority of the first ACK packet, facilitating the description of the first ACK packet's priority as the highest priority. The priority information can be COS priority, TOS priority, DSCP priority, etc., as explained in the terminology section. Optionally, the priority information of the first ACK packet is the same as or related to the priority information of the first data packet. That is, the priority information of the first data packet can be obtained based on the priority information of the first ACK packet.

[0147] Step S502: The network device determines the first port based on the source address of the first ACK packet.

[0148] Here, the first port is the local outgoing port of the first data packet. Understandably, the first data packet typically carries information indicating the destination, such as the destination IP address. After receiving the first data packet from a certain port, the network device forwards it from an appropriate port (i.e., the first port) based on the destination information carried in the first data packet. Since the first port is the local port of the network device, and the first data packet is forwarded from this first port, the first port is the local outgoing port of the first data packet.

[0149] In some solutions, network devices establish routing tables (including forwarding tables) that record the correct output port for data packets. These routing tables also include destination information, allowing the network device to determine the local output port of a data packet based on this destination information.

[0150] In this embodiment, the first ACK packet carries the source address of the first ACK packet (i.e., the address of the first device). Since the source of the first ACK packet is the destination of the first data packet, the network device can determine the local output port (i.e., the first port) of the first data packet based on the source address of the first ACK packet.

[0151] In one possible implementation, the network device performs a route lookup based on the SIP of the first ACK packet to determine the local outgoing port of the data packet. The method of determining the outgoing port based on IP address routing can be found in existing technologies. For ease of understanding, an exemplary routing process is described below, as shown in Table 1. The routing table includes the destination address and the address of the next-hop node. The destination is the final address or network, such as D1, D2, D3, etc., as shown in the table. The next hop indicates the next point. If network device N1 is not directly connected to the destination, network device N1 can forward the packet to the next hop, such as N2, N3, N4, etc. For example, when the SIP of the first ACK packet indicates D1, the first port is the port connecting to the next hop N2. Similarly, when the SIP of the first ACK packet indicates D2, the first port is the port connecting to the next hop N3.

[0152] Table 1 Routing table for network device N1

[0153] Objectives Next hop D1 N2 D2 N3 D3 N4 …… ……

[0154] In another possible implementation, the network device uses the SIP and DIP included in the first ACK packet to look up the flow table and determine the local egress port of the data packet. Specifically, the network device maintains a flow table, such as a session table, which records the status of communication connections associated with the device. When forwarding packets, the network device can query the flow table to determine the connection to which the packet belongs. This communication connection includes TCP connections. For ease of understanding, an exemplary flow table is described below, as shown in Table 2. The flow table may include a flow number (such as the flow ID), source address, destination address, and local egress port. Optionally, some flow tables may also include one or more of the following: aging time, source port, destination port, security policy, next-hop address, etc. For example, when the SIP of the first ACK packet is SIP1 and the DIP is DIP1, the first port is Port1.

[0155] Table 2 Flow table for network device N1

[0156] Flow number Source address Destination address Local egress port Next hop F1 SIP1 DIP1 Port1 N5 F2 SIP2 DIP2 Port2 N6 F3 SIP3 DIP3 Port3 N7 …… ……

[0157] It should be understood that the routing table shown in Table 1 and the flow table shown in Table 2 are merely examples. In specific implementations, the routing table and flow table may be stored (or transmitted) in tabular form or in other forms. This application does not limit the specific format of the routing table and flow table.

[0158] As another possible implementation, determining the first port includes obtaining the identifier of the first port. The port identifier is used to distinguish different ports; for example, it can be a port ID, a port number, or a port sequence number, etc., without strict limitations here.

[0159] Step S503: The network device determines the congestion indication of the first port.

[0160] Congestion indicators are used to indicate the degree of congestion at a port, and in some scenarios, they may also be referred to as congestion signals. In some schemes, congestion indicators are metrics used to describe the congestion state, capable of characterizing different levels of congestion. For example, congestion indicators can indicate the degree of congestion in the form of percentages, levels, numbers, status flags (such as flags, field values, etc.).

[0161] The following example illustrates the process of generating congestion indicators.

[0162] In one possible implementation, the network device obtains queuing information from the local queue of a first port. The congestion indication of this first port is related to this queuing information. Specifically, packets to be sent by the network device are arranged in the queue corresponding to the port. The network device sends packets sequentially according to the queue order. The state of the queue corresponding to the port reflects whether packet transmission on that port is smooth. Therefore, the queuing information of the port's queue reflects the congestion status of the network corresponding to the port, and the network device can determine the congestion indication based on this information. It should be noted that the port here refers to the network device's local port; therefore, the queue corresponding to the port can also be called the local queue, i.e., the queuing information of the network device's own port.

[0163] Optionally, the packets queued in the queue are cached in the network device's storage unit, so the local cache state of the network device can also serve as the port's queue queuing information. In other words, in some schemes, the network device can obtain the local cache state and determine the port's congestion indication based on the local cache state.

[0164] In some possible schemes, the queuing information for the port includes one or more of the following: the number of queued packets, the data size of the packets, the proportion of the number of queued packets to the maximum capacity of the queue, or the proportion of the data size of the queued packets to the maximum data size of the queue. For ease of understanding, three possible scenarios are described below:

[0165] In scenario 1, network devices can directly use port queuing information as a port congestion indicator. For example, if the number of queued packets is 100, the port congestion indicator is 100. In this case, the port congestion indicator is positively correlated with the degree of port congestion.

[0166] Scenario 2: Network devices can generate a port congestion indicator based on the queuing information of the port's queues. The port congestion indicator can differ from the port's queuing information. For example, taking the queuing information of the port's queue as the number of queued packets, when the number of queued packets falls within range R1 (e.g., greater than a first threshold), the congestion indicator is valued as d1; when the number of queued packets falls within range R2 (e.g., less than a second threshold), the congestion indicator is also valued as d1. Ranges R1 and R2 are different and do not overlap, and the first data threshold and the second threshold can be the same or different.

[0167] Scenario 3: Network devices can determine the congestion probability based on the queuing information of the port queues, and determine a congestion indication based on the congestion probability. The congestion probability represents the likelihood of network congestion. In some schemes, the congestion probability is positively correlated with the number of queued packets, or the proportion of queued packets, or the data volume of queued packets, or the proportion of queued packets to their data volume.

[0168] For example, a network device can obtain the number of packets in the port's queue (i.e., the number of queued packets) and calculate the congestion probability based on the number of packets in the queue and the maximum capacity of the queue. Referring to Table 3, the congestion probability k indicates the proportion of queued packets to the maximum capacity of the queue. When k falls within a first range (e.g., k ≤ x1), the congestion indication value is d1; when k falls within a second range (e.g., k > x1), the congestion indication value is d2. The first and second ranges typically do not overlap, and x1 represents a threshold value. This threshold can be predefined in the network device (e.g., defined at the factory), pre-configured for the network device (e.g., configured by other devices or users), or calculated and determined by the network device itself based on network conditions.

[0169] Table 3. Rules for determining congestion indications in messages 1

[0170] Range of values of k Congestion indication k≤x1 Value d1 k>x1 Value d2

[0171] For another example, referring to Table 4, when the congestion probability k falls into the third range (e.g., k ≤ x2), the congestion indicator value is d1; when k falls into the fourth range (e.g., k ≥ x3), the congestion indicator value is d2; and when k falls into the fifth range (e.g., x2 < k < x3), the congestion indicator value is calculated using a predefined algorithm, for example, determined to be either d1 or d2 with a certain probability. This probability can be predefined or user-defined. In other words, when k falls into the fifth range, the congestion indicator value is not fixed. Since the fourth range is between the third and fifth ranges, congestion may not have occurred yet but may occur within this range. Therefore, in this intermediate zone, the congestion indicator is flexibly determined, thereby triggering flow control with a certain probability and reducing the probability of congestion.

[0172] Table 4. Rules for determining congestion indications in messages (2)

[0173] Range of values of k Congestion indication k≤x2 Value d1 x2 Probability determined as value d1 or value d2 k≥x3 Value d2

[0174] It should be understood that the boundaries of the ranges shown in Tables 3 and 4 may have other designs. For example, k≤x1 can be replaced with k<x1, and k>x1 can be replaced with k≥x1. That is, for the case of k=x1, the threshold can follow the range it is closest to. The cases shown in Tables 3 and 4 are only examples.

[0175] In some possible implementations, the aforementioned value range is configurable. That is, x1, x2, or x3 can be customized.

[0176] In other possible implementations, the aforementioned probabilities may be predefined, configured, or calculated. As one possible implementation, for the case x2 < k < x3, the congestion indication is determined as d1 with probability p1, correspondingly with probability (1-p1). Exemplarily, the values ​​of p1 and p2 may be, for example, 50% and 50%, 75% and 25%, 60% or 40%, etc.

[0177] Alternatively, in the congestion indication rules in Tables 3 and 4, the congestion probability k is related to the proportion of the number of queued messages to the maximum capacity of the queue. In practice, the congestion probability k may also indicate other information, such as one or more of the following: the number of messages, the amount of data in the messages, or the proportion of the amount of data in the queue to the maximum capacity of the queue.

[0178] It should be understood that the congestion indication rules shown in Tables 3 and 4 are merely examples, and other rules may exist in specific implementations. In some designs, the congestion probability k may only be an intermediate parameter in the internal processing and is not explicitly input or output. That is, the network device can determine the congestion indication of the first port based on the number of packets in the queue, and the calculation of the congestion probability k in conjunction with the maximum capacity of the queue and the obtaining of the congestion indication based on the range in which the congestion probability k falls are both just intermediate calculation processes in the algorithm. This design also applies to other definitions of k.

[0179] As mentioned in the terminology section, a port may correspond to one queue or multiple queues.

[0180] In some possible implementations, there is only one queue corresponding to a port; this queue can also be called a port queue. In this case, the network device can determine the congestion indication of the port based on the queuing information of a local queue corresponding to that port.

[0181] In other possible implementations, there may be multiple queues corresponding to a port. For example, these queues may differ in other attributes, such as priority or the user they correspond to. In this case, the network device can determine the congestion indication for the port based on the queuing information of the multiple queues corresponding to the port. The following example illustrates this implementation:

[0182] In one implementation example, the network device calculates a congestion probability k based on the total number of packets currently queued in multiple queues on the first port and the total number of packets that the multiple queues can hold, and determines a congestion indication for the first port. See also Figure 6Port 1 corresponds to three queues: queue Q1-1, queue Q1-2, and queue Q1-3. The total number of packets in these three queues is (60 + 120 + 160 =) 340, while the total number of packets that the three queues can hold is (100 + 150 + 200 =) 450. The congestion probability k can be the ratio of the total number of queued packets to the maximum capacity of the queues. For example, when the ratio of the number of queued packets to the maximum capacity of the queues is less than or equal to 40%, the congestion indicator takes the value d1; otherwise, it takes the value d2. Figure 6 In the scenario shown, the congestion indicator is valued as d2, indicating that network congestion has occurred. For example, the proportion of the total number of packets queued in multiple queues to the maximum capacity of each queue can be represented as k. The congestion indicator obtained based on this proportion k can be found in Tables 3 and 4. In this implementation example, although a port can correspond to multiple queues, the resulting congestion indicator is still calculated at the port level; the correspondence between ports and congestion indicators is one-to-one.

[0183] In some scenarios, a port comprises multiple queues, each corresponding to at least one other attribute, such as priority or user. As a possible example, each of the multiple queues corresponding to a port may also correspond to a priority level; in this case, the multiple queues corresponding to the port can be called priority queues (or port + priority queues), where the priority can be COS priority, IP priority, or DSCP priority. See also Figure 6 The local queues corresponding to port 1 include queues Q1-1, Q1-2, and Q1-3, etc. Queue Q1-1 may correspond to COS priority level 7, meaning that packets with COS priority level 7 can be queued in queue Q1-1 to await transmission. Alternatively, priority can be replaced by a priority set, which includes multiple priorities. Generally, multiple priorities within the same priority set are similar or adjacent. For example, one of the queues Q2-1 on port 2 may correspond to priorities 6 and 7. Of course, Figure 6 The number of queues, queue capacity, and current number of packets mentioned are merely examples, and the correspondence between each queue and priority described here is also for the purpose of understanding the priority queue situation.

[0184] In one implementation example, the network device can determine the congestion indication corresponding to the first port and the first priority based on the queuing information of the queues corresponding to the first port and the first priority. For example, the network device determines the congestion indication jointly corresponding to port 1 and priority 7 based on the number of packets in queue Q1-1 and the total number of packets that queue Q1-1 can hold, combined with... Figure 6The data indicates a congestion rate of 60% for both port 1 and priority 7. Similarly, the congestion rate for both port 1 and priority 6 is 50%. For other queues and levels, please refer to [link / reference]. Figure 6 .

[0185] Furthermore, network devices can determine the congestion indication that corresponds to multiple ports and priorities based on the priority queues corresponding to each port.

[0186] In some schemes, the first ACK packet carries the source IP and priority information, such as the priority information indicating the first priority. The network device can determine the first port based on the source IP and the first priority based on the priority information, thereby obtaining the congestion indication corresponding to the first port and the first priority.

[0187] The process of generating congestion indicators has been described above. The following section introduces two methods for determining congestion indicators.

[0188] As one possible method for determining congestion indication, after receiving the first ACK packet, the network device determines the first port based on the source address of the first ACK packet and detects the queuing information of the queue corresponding to the first port, thereby determining the congestion indication of the first port. Furthermore, the network device can also detect the queuing information of the queue corresponding to the first port and the first priority based on the first priority indication information carried in the first ACK packet, thus determining the congestion indication jointly corresponding to the first port and the first priority. In this implementation, the port congestion indication is generated after receiving the first ACK packet, triggered by the information carried in the first ACK packet and based on the detected information.

[0189] As another possible method for determining congestion indication, network devices can periodically or non-periodically detect queuing information in their local port queues, obtain congestion indications based on the queuing information, and store these port congestion indications in a mapping set, associating each port congestion indication with a port identifier. In subsequent processes, the network device can look up the congestion indication corresponding to a specific port in the mapping set using the port identifier. In this way, the network device can accurately represent the congestion level of multiple ports using the mapping set and perform precise flow control on TCP flows passing through multiple ports, reducing the complexity of congestion control implementation.

[0190] The following describes some possible implementations of the correspondence set in the embodiments of this application.

[0191] In summary, the correspondence set may include the identifier of the first port and the congestion indication of the first port. There is a correspondence between the identifier of the first port and the congestion indication of the first port. This correspondence can be one-to-one or one-to-many (e.g., a port plus its priority jointly corresponds to a single congestion indication). In some implementations, this correspondence set is also called a port status table. Further, the correspondence set may include the identifiers of multiple ports of the network device and their respective corresponding congestion indications, with the first port being one of these multiple ports.

[0192] The following section introduces several possible implementations of the correspondence set, and also provides examples of several possible implementations of the congestion indicator.

[0193] In one implementation, the congestion indicator uses different values ​​to indicate the degree of congestion. Please refer to Table 5, which is a schematic table of a correspondence set provided in an embodiment of this application. This correspondence set is used to describe multiple ports of a network device and their corresponding congestion indicators. Examples of the values ​​for each field are shown in Table 6. Combining Tables 5 and 6, a congestion indicator of 0 for port 1 indicates that port 1 is not congested; similarly, port 2 is congested. It should be understood that the field names and explanations in the first correspondence are only for ease of understanding the solution of this application. These field descriptions may not be stored on the network device, or the values ​​of the congestion indicator field may occupy a longer value length and have more possible value designs.

[0194] Table 5 shows the congestion indicators for ports.

[0195] Identification of port Congestion indication Port 1 0 Port 2 1 Port 3 0 Port 4 1 …… ……

[0196] Table 6: Field Descriptions of Correspondence Sets

[0197]

[0198] In some scenarios, this congestion indication is referred to as the suppression state, denoted by `suppress`. Referring to Table 5, when `suppress` is 1, it indicates network congestion, requiring traffic suppression; conversely, when `suppress` is 0, it indicates no network congestion, and no traffic suppression is needed. It should be noted that the naming of devices, parameters, and packets in this application is merely illustrative; in different scenarios, the names of devices, parameters, and packets may be replaced.

[0199] In some implementations, the congestion indicator expresses the degree of congestion as a percentage; the higher the percentage, the more severe the congestion. Please refer to Table 7, which is a schematic table of another set of correspondences provided in this application embodiment. This set of correspondences describes multiple ports of a network device and their respective congestion indicators. For example, if the congestion indicator for port 1 is 40% and the congestion indicator for port 2 is 10%, it indicates that the network connected to port 1 is more congested than the network connected to port 2.

[0200] Table 7 Port Congestion Indication

[0201] Identification of port Congestion indication Port 1 40% Port 2 10% Port 3 80% Port 4 90% …… ……

[0202] In some implementations, port congestion can also be indicated by a level. As shown in Table 8, a higher congestion level indicates a more severe degree of congestion. For example, if port 1 has a congestion level of 2 and port 2 has a congestion level of 1, it means that the network connected to port 1 is more congested than the network connected to port 2.

[0203] Table 8 shows the congestion indications for ports.

[0204] Identification of port Congestion indication Port 1 2nd level Port 2 1st level Port 3 3rd level Port 4 4th level …… ……

[0205] In some implementations, port congestion indicators can also be numerical. In one example, the congestion indicator is used to indicate the amount of data (e.g., bytes) that the source can send, and this amount is negatively correlated with the degree of congestion. As shown in Table 9, the smaller the congestion indicator value, the more severe the congestion. Specifically, the congestion indicator for port 1 is 1600, indicating that the source of a TCP stream using port 1 as its local egress port can send 1600 bytes of data. The congestion indicator for port 2 is 1200, indicating that the source of a TCP stream using port 2 as its local egress port can send 1200 bytes of data. It can be seen that the network connected to port 2 has a smaller capacity to handle traffic compared to the network connected to port 1, and the network connected to port 2 is more congested than the network connected to port 1.

[0206] Table 9 shows the congestion indications for ports.

[0207]

[0208]

[0209] It should be understood that the correspondence sets shown in Tables 5, 7, 8 and 9, as well as in the embodiments below, are merely examples. In actual implementation, the correspondence sets may be stored in the form of tables, database tables, linked lists, strings, or queues. This application does not limit the storage format of the correspondence sets.

[0210] In some schemes, the congestion indicator is associated with additional attributes besides the port, which are called the first attribute for easy distinction. The congestion indicator corresponds to the port and this first attribute. For example, the first attribute may be one or more attributes such as priority or user. Taking priority as an example, in the correspondence set, the port identifier and priority jointly correspond to the congestion indicator, as shown in Table 10. That is, the relationship between port and congestion indicator is one-to-many; one port may correspond to multiple congestion indicators, and the specific congestion indicator needs to be determined by combining the port and the first attribute. It should be understood that the format of the correspondence, the specific name of the attribute, and the value of the attribute shown in this application are only examples, and other implementation methods may exist in specific implementations.

[0211] Table 10: Port Congestion Indicators (with Priority)

[0212] Identification of port Priority or set of priorities Congestion indication Port 1 7 60% Port 1 6 50% Port 1 5 50.5% Port 1 4 70% …… …… …… Port 2 6 and 7 40% Port 2 5 10% Port 2 4 80% …… …… ……

[0213] As one possible implementation, the first ACK packet may carry information related to the first attribute, which is easily distinguishable and referred to as the first indication. For example, when the first attribute is priority, the first indication may be the first priority (i.e., priority information). The network device determines the first port and the first priority based on the information carried in the first ACK packet, and determines the congestion indication that the first port and the first priority jointly correspond to from several possible correspondences. For example, referring to Table 10, if the first port is port 1 and the first priority is 5, then the congestion indication that the first port and the first priority jointly correspond to is 60%. In this case, the determined congestion control can be specifically used to control the amount of data with a first priority that the source can send. Thus, based on the outgoing port and priority of the data packet corresponding to the ACK packet, the congestion level of a packet sent from a certain outgoing port and with a certain priority can be queried, thereby accurately controlling the traffic of a certain priority. Congestion control at the granularity of port + priority improves the accuracy of congestion control, ensuring that traffic of priorities that are not congested is not restricted, which is beneficial to improving network throughput.

[0214] Optionally, in the aforementioned example, the priority in the first ACK packet is the same as the priority of its corresponding data packet. However, in cases where priorities differ, the network device can determine the corresponding data packet priority based on the priority of the first ACK packet. Based on the first port and the data packet priority, it can determine a congestion indication corresponding to the port and data packet priority, thereby limiting the number of data packets of the specified priority sent by the source.

[0215] The above describes some possible implementations of recording port congestion indications using a set of correspondence relationships. In some scenarios, as transmission progresses, packets continuously enter the local port queue of the network device and are continuously forwarded from the port, while the queuing information of the port queue is constantly changing. Therefore, network devices need a mechanism to detect the queuing information of the local port queue in a timely manner in order to accurately determine the congestion indication corresponding to the port.

[0216] The following describes a mechanism for periodic checks. In one possible implementation, the network device periodically checks the local queue of a port, obtains the queuing information of the port's local queue, determines the port's congestion indication, and saves it to the corresponding relationship set (i.e., updates the correspondence set). For example, combined with... Figure 6 The network device checks the queuing information of multiple queues on port 1 every first time interval. Based on the queuing information of multiple queues on port 1, it updates the congestion indicator corresponding to port 1 in the corresponding relationship set. In this way, the queuing information of local queues can be monitored and the congestion indicator can be updated periodically, so that the congestion status of local ports can be collected and recorded with high accuracy and timeliness, making congestion control more precise.

[0217] Furthermore, when a network device includes multiple ports, the network device can simultaneously scan the queuing information of the local queues of multiple ports and centrally update the congestion indicators corresponding to each port in the correspondence set. As one possible implementation, the network device can periodically detect the local queues of the multiple ports to obtain the queuing information of the local queues of the multiple ports, for example... Figure 6 The diagram shows multiple queues corresponding to ports such as port 1 and port 2. The network device updates the corresponding relationship set based on the queuing information of the local queues of multiple ports.

[0218] Optionally, the duration of the period for detecting the local queue (such as the first duration) is relatively short, for example, less than 1ms, so as to achieve high-precision detection of the queuing status and improve the accuracy of congestion control.

[0219] To facilitate understanding, the following will be combined with... Figure 7This document presents a schematic diagram illustrating the operation of a congestion control method provided in an embodiment of this application. It can be seen that a thread is pre-configured in the network device. This thread is periodically triggered to perform the following operations: monitoring the queuing information of the port queue (e.g., port + COS priority queue), calculating a congestion indication based on the queue queuing information, and saving the congestion indication to a corresponding relationship set. When the next cycle arrives, for example, after 1ms, the thread repeats the above operations.

[0220] The foregoing described a mechanism for periodically checking and updating port congestion indicators. In some schemes, network devices can also update congestion indicators through condition-triggered (event-triggered) updates.

[0221] As an implementation example, by adding a timer to the target packet, if the packet has not been sent from the corresponding local outgoing port (referred to as the second port) after the timer expires, a check of the queue on the second port is triggered to obtain the queuing information of the second port, and the corresponding relationship set is updated based on the queuing information of the port. By adding a timer to the target packet, a port check can be triggered after the packet is blocked for a certain period of time, so as to accurately detect ports that may be congested and improve the accuracy of congestion control.

[0222] Furthermore, if a port does not trigger a detection within the second time period, it indicates that packet transmission is smooth. In this case, the corresponding relationship set can be updated to update the congestion indicator for that port, thereby reducing the congestion level for that port. Alternatively, if a port does not trigger a detection within the second time period, it can be detected to avoid inaccurate congestion indicators caused by timer flag failure, thus improving the accuracy of the congestion control mechanism.

[0223] Optionally, the target message can be randomly selected, or selected according to a preset number interval (e.g., selecting one message and adding a timer every 99 messages) or time interval, or the target message can be a marked message (e.g., marked by importance, priority, or urgency).

[0224] The foregoing has described the form of the first set of relations, the congestion indication, and the method for updating the set of corresponding relations. The following is an example of the process of establishing the first set of corresponding relations.

[0225] In some possible implementations, the mapping set can be pre-established in the network device, for example, pre-programmed into the network device, or established during the initialization process after the network device starts up. In other possible implementations, the mapping set may be triggered to establish under pre-designed conditions, for example, after the first connection with another second network device or terminal device is triggered, the establishment of the first mapping is triggered.

[0226] Step S504: The network device sends a congestion control instruction to the source.

[0227] Among them, the congestion control indicator is used to control the amount of data that the source can send, such as one or more of the following: the number of bytes or the number of data packets.

[0228] The following describes two possible implementations of congestion control indicators:

[0229] Implementation Method 1: Congestion control indicators are used to indicate the amount of data the source can send. These indicators include direct and indirect indications. Direct indications include, for example, indicating the amount of data the source can send, or combining the congestion control indicator with other parameters (such as the window scaling factor) to indicate the amount of data the source can send. Indirect indications include, for example, indicating which sequence number (or which number of bytes) of a message the source can send, thus indirectly indicating the amount of data the source can send.

[0230] For example, in a TCP network, the amount of data that can be sent can be controlled based on a window value. In this case, a congestion control indicator can be used to indicate the window value, which may include one or more of the following: a congestion window, a receive window, or a send window. For instance, the congestion control indicator may be the receive window value, or it may be the congestion window value (the number of packets), thus indirectly indicating the window value.

[0231] For another example, the congestion control indicator is used to indicate the amount of data in a data service unit that a data link layer entity can receive. The maximum transmission unit (MTU) is used to represent the maximum length (e.g., maximum number of bytes) of the data payload portion agreed upon by the data link layer. For example, the congestion control indicator can be the size of K1 MTUs, where K1 is an integer and K > 0. For another example, the congestion control indicator can be a value between (min1 and max1), where the minimum value min1 is, for example, 1 MTU, and the maximum value max1 is, for example, 0xFF.

[0232] For another example, the congestion control indicator is used to indicate the amount of data in a data service unit that a transport layer entity can receive. The maximum segment size (MSS) is used to represent the maximum length of the data payload portion of the transport layer, i.e., the data portion of a TCP segment. For another example, the congestion control indicator can be K2 MSS, where K2 is an integer and K > 0. For yet another example, the congestion control indicator can be a value from (min1, max2), where the minimum value max1 is, for example, 1 MSS, and the maximum value max2 is, for example, 0xFF.

[0233] Alternatively, the congestion control indicator is used to indicate the number of data packets that the data link layer can send, for example, a value between 1 and K1, or a value between 1 and K2. K1 is used to indicate the number of MTUs, and K2 is used to indicate the number of MSSs.

[0234] In implementation method 2, the congestion control indicator is used to indicate the direction of change in the amount of data (or window value) that the source can send. The direction of change includes, for example, increasing, decreasing, or maintaining. For instance, when the congestion control indicator is value C1, it indicates an increase in the amount of data that the source can send; when the congestion indicator is value C2, it indicates a decrease in the amount of data that the source can send. Optionally, when the congestion window indicator is value C3, it indicates maintaining the current amount of data that the source can send.

[0235] Alternatively, the aforementioned amount of data that the source can send can be replaced by a receive window, a congestion window, etc. Both the receive window and the congestion window can be used to limit the amount of data that the source can send. For example, in some possible embodiments, the network device sends a first device's receive window value to the source, which represents the amount of data the receiver can receive (i.e., the receive window size). The source can then select the smaller value from the receive window value and the congestion window value as the send window size, thereby achieving flow control.

[0236] The congestion control indication is related to the congestion indication of the first port. Since the congestion indication characterizes the degree of congestion at the port, the amount of data that the source can send can be controlled based on the congestion indication, suppressing or increasing the traffic that the source can send to network devices. Because the congestion indication may indicate different degrees of congestion, the congestion control indication can also adjust the amount of data that the source can send in multiple directions based on changes in the congestion indication. That is, the control in this application can include multi-directional adjustment mechanisms, such as downward and upward rate adjustments. When the network is congested, this application can reduce the amount of data that the source can send; when congestion is alleviated or the network is smooth, this application can increase the amount of data that the source can send; or, when the network conditions do not change significantly, it can instruct the source to maintain the amount of data that can be sent.

[0237] As one possible implementation, the network device determines whether a traffic suppression condition is met based on a congestion indication. If the traffic suppression condition is met, the device reduces the amount of data that the source can send via congestion control. Conversely, if the traffic suppression condition is not met, the device either does not suppress the amount of data that the source can send or increases the amount of data that the source can send. The traffic suppression condition can be predefined or pre-calculated, and it uses the congestion indication as an indicator. For example, referring to Table 5, the traffic suppression condition includes a congestion indication of 1. Therefore, if the congestion indication of the first port is 1, the traffic suppression condition is met. If the congestion indication of the first port is 0, the traffic suppression condition is not met.

[0238] The following describes two methods for determining congestion control indicators:

[0239] Method 1: The congestion control indicator is determined by the congestion indicator of the first port. For example, in conjunction with the aforementioned implementation 2, the congestion control indicator is used to indicate the direction of change in the congestion window value. For instance, referring to Table 5, when the port's congestion indicator is 1 (i.e., the flow suppression condition is met), the congestion control indicator takes the value C2 to indicate a decrease in the congestion window value; when the port's congestion indicator is 0, the congestion control indicator takes the value C2 to indicate an increase in the congestion window value.

[0240] As another example, combining the aforementioned implementation method 1 and Table 9, in the implementation shown in Table 9, the congestion indicator is used to indicate the amount of data that the source can send. Since the congestion control indicator is also used to indicate the amount of data that the source can send, the two can be the same, or different but related. If they are the same, and the congestion indicator is 50, then the congestion control indicator can also be 50. Consider a possible scenario where the congestion indicator is used to indicate the window value of the congestion window (which can be replaced by the receive window), while the congestion control indicator needs to be combined with the window scaling factor to jointly determine the window value of the source's congestion window. If the congestion indicator is 50 and the window scaling factor is 5, then the congestion control indicator is 10.

[0241] Method 2: The network device maintains a first parameter, which indicates the amount of data that the source end of a data packet with the data output port being the first port can send. This indication can be direct or indirect. The network device can determine the congestion control indication based at least on the first parameter. As one possible implementation, the congestion control indication and the first parameter can be the same, or different but related. If they are the same, and the first parameter is 50, then the congestion control indication can be 50. Consider a possible case where the first parameter is the receive window value, and the congestion control indication needs to be combined with the window scaling factor to determine the receive window value of the source end. If the first parameter is 50 and the window scaling factor is 5, then the congestion control indication is 10.

[0242] In method 2, the value of the first parameter is updated using a congestion indicator. For example, referring to Table 5, the value of the first parameter is decreased when the congestion indicator is 1, and increased when the congestion indicator is 2. This example uses the first parameter to indicate the amount of data the source can send in a positive direction; that is, the larger the value of the first parameter, the larger the amount of data the source can send. This application also applies to the case of a negative indication.

[0243] In one possible implementation, during congestion control, the network device applies greater force to slowing down than to accelerating. Similar to the intermittent braking and gradual release of the accelerator in a vehicle, when congestion or suspected congestion occurs, the network device significantly reduces the amount of data that the source can send, rapidly reducing network traffic and controlling congestion as quickly as possible. Conversely, when congestion has subsided or has not occurred, the network device slightly increases the amount of data that the source can send, controlling traffic growth slowly to prevent recurrence and improve network stability. Furthermore, the congestion indicators corresponding to ports in this application are updatable, allowing traffic acceleration and deceleration to adapt to changes in network congestion conditions, thus improving the accuracy of congestion control.

[0244] The following section uses Method 2 as an example to introduce acceleration and deceleration control.

[0245] As one possible implementation, when the congestion indication at the first port meets the traffic suppression condition, the first parameter is reduced to its minimum value, and this minimum value is used as the new base value for the first parameter. Conversely, when the congestion indication at the first port does not meet the traffic suppression condition, the first parameter is increased by a first value based on its base value to obtain a new base value for the first parameter. In this implementation, when traffic suppression is needed, the receive window value is reduced to its minimum to achieve rapid traffic suppression. When traffic suppression is not needed, the value of the first parameter is increased slowly (by the first value) to control the slow growth of traffic.

[0246] Optionally, the first value is less than half the width of the range of values ​​for the first parameter, such as less than 1 / 4, 1 / 6, or 1 / 8 of the width of the range of values ​​for the first parameter. Setting the first value to be relatively small can slow down the rate of increase in traffic and avoid new congestion caused by a sudden increase in traffic in a short period of time.

[0247] In some possible implementations, the minimum value of the first parameter is w0, and optionally, the upper limit of the first parameter is W_max. When the congestion indication of the first port meets the traffic suppression condition, the first parameter is directly reduced to w0. When the congestion indication of the first port does not meet the traffic suppression condition, the value of the first parameter is increased. For example, if the base value is w0, the first parameter is increased by a first value (e.g., Δw), that is, the value of the first parameter is updated to w0 + Δw. Similarly, if the current base value is w1, the value of the first parameter after being increased by the first value is w1 + Δw. Optionally, if the current base value of the first parameter has already reached the upper limit W_max, the upper limit W_max is maintained. In this implementation, if the traffic suppression condition is met, the value of the first parameter is significantly reduced; if the traffic suppression condition is not met, the value of the first parameter is slowly increased. Since the first parameter indicates the receive window value, this implementation can quickly reduce the traffic of the network device in the event of congestion or suspected congestion, so that congestion can be controlled as soon as possible. When congestion is alleviated or not occurring, this implementation method can control the slow growth of traffic, prevent the recurrence of congestion, and improve network stability.

[0248] As mentioned earlier, the first parameter is maintained locally on the network device. In some possible implementations, the first parameter may be updated periodically and / or non-periodically. Two examples are described below:

[0249] As an example, referring to Table 5, after detecting that the congestion indicator corresponding to the first port is updated to 1 (i.e., conditional triggering), the network device decreases the value of the first parameter. If the congestion indicator of the first port is updated to 0, or if the congestion indicator of the first port is 0 and the first parameter has maintained its current value for a second duration (conditional triggering plus time periodic triggering), the network device increases the value of the first parameter. Please refer to [link to relevant documentation]. Figure 8 , Figure 8 This is a timeline diagram illustrating the first parameter update provided in this application. Taking the congestion indication shown in Table 5 as an example, at time t0, the congestion indication (i.e., suppression state) of the first port is 1, so the network device updates the congestion value of the first parameter to the minimum value w0. At time t1, the congestion indication of the first port is 0, and the network device increases the first parameter by a first value Δw, meaning the current value of the first parameter is w0 + Δw. After a second time interval Δt, i.e., at time t2, the congestion indication of the first port is 0, and the first parameter has maintained its current value (w0 + Δw) for a second time interval. At this time, the first parameter is increased by the first value Δw again, reaching w0 + 2Δw. Similarly, as... Figure 8For a subsequent period, the congestion indication of the first port remains unchanged. Therefore, every second time interval Δt, the value of the first parameter increases by a first value Δw until it reaches the upper limit W_max. For example, at times t3, t4, and t5, the value of the first parameter increases, reaching the upper limit at time t5. After reaching the upper limit W_max, the value of the first parameter no longer increases. If the congestion indication of the first port is subsequently updated to 1, for example at time t6, the network device reduces the value of the first parameter to the minimum value w0.

[0250] As another example, the network device checks the value of the congestion indicator corresponding to the first port every third time interval. If the value of the congestion indicator is 1, the value of the first parameter is decreased. If the congestion indicator of the first port is 0, the network device increases the value of the first parameter. Optionally, this third time interval can correspond to the update period of the corresponding relationship set (i.e., the first time interval), for example, the first time interval equals the third time interval.

[0251] As mentioned earlier, the congestion control indication is determined at least by a first parameter. One possible implementation is that the congestion control indication can be determined by the first parameter and a window scaling factor, where the window scaling factor indicates the multiplier by which the receive window value is scaled. For example, if the network device expects the receive window value sent by the source to be 20, the first parameter could be 20. However, due to the window scaling factor, the source will scale the value of its received window by a specified multiplier and use the scaled value to limit the amount of data that can be sent. Therefore, when generating the congestion control indication, the effect of the window scaling factor is considered. The first parameter is divided by the window scaling factor to obtain the congestion control indication. For example, if the first parameter is 20, it can be understood that the network device expects the receive window value of the source to be 20, and if the window scaling factor is 10, then the congestion control indication is 2.

[0252] The following describes how network devices send congestion control instructions to the source.

[0253] In some possible implementations, the network device may forward the congestion control indication to the source by including it in the first ACK packet; that is, the first ACK packet carries the congestion control indication. For example, the first ACK packet may include a field (referred to as the first field for easy distinction), and the congestion control indication may be included in the first field and sent to the source.

[0254] In some scenarios, the first ACK packet includes a window (WIN) field, also known as the RWND field. In some solutions, this WIN field indicates the size of the receiving window at the destination. Network devices can update the value of the WIN field in the first ACK packet based on congestion control indications to implement congestion control. For example, if the WIN field in the first ACK packet originally has a value of W2, and the congestion indication meets the flow suppression condition, the first parameter is reduced to the minimum value w0, and the network device can update the WIN field value of the first ACK packet to w0.

[0255] As one possible implementation, the value of the WIN field in the ACK packet, after being updated, typically cannot exceed the original value of the WIN field. For example, if the original value of the WIN field is W2, and the current value of the first parameter is w2, then if w2 is less than W2, the network device will update w2 to the new value of the WIN field; otherwise, the WIN field will retain its original value. In this implementation, the first parameter can also be understood as the upper limit of the WIN field. If the original value of the WIN field exceeds the first parameter, the original value of the WIN field is retained; or if the original value of the WIN field exceeds the first parameter, it is modified to the first parameter.

[0256] For ease of understanding, Figure 9A and Figure 9B The diagram illustrates two possible data packet formats. The content within parentheses indicates the number of bits occupied by each field. The format of the ACK packet is the same as that of the data packet. Figure 9A and Figure 9B The datagram includes the source and destination addresses. The data portion of the IP packet is a TCP packet, and the TCP header includes a window size field, which can be used to carry congestion control instructions. Optionally, some schemes also include a window scaling factor, which can be carried in the options field of the TCP packet.

[0257] The following are examples of... Figure 9A and Figure 9B The other fields will be described below. A data packet includes an IP header and the data portion of the IP packet. The IP header contains control information related to ensuring reliable transmission at this layer, while the data portion comes from higher layers.

[0258] exist Figure 9AIn IP, the header includes version, internet header length (HL), type of service (TOS), total length, identification, flags, fragment offset, time to live, protocol, header checksum, source address, destination address, options, and padding. Figure 9B In the IP header, the following information is provided: version, traffic classes (also known as traffic levels, used to indicate priority), flow label, payload length, next header, hop limit, source address, destination address, and options header. Further, the data portion of the IP packet includes the TCP header and data portion. The header includes the source port number, destination port number, sequence number, acknowledgment number (used in ACK), header length (data offset), reserved fields (number of bits used is shown as an example), flags, window, checksum, urgent pointer, and options (optional). The number of bits or bytes used for each field is only an example. The flags further include one or more of the following fields: NS, CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN, with relevant descriptions available in existing technologies. The options portion may include one or more of the following: window scaling factor, maximum segment length, sackOK, timestamp, etc., which can be selected according to actual needs.

[0259] In some scenarios, the WIN field in the ACK packet, along with another field, jointly controls the amount of data the source end of the datagram can send. For example, the ACK packet also carries a window scaling factor field, used to scale the value of the WIN field by a specified multiple to determine the receive window size. In this case, the network device will also consider the value of the window scaling factor field when updating the WIN field. For instance, if the original value of the WIN field is W2, the current value of the first parameter is w2, and the window scaling factor is wcale, the network device can update the new value of the WIN field to w2 / wcale. For example, if the first parameter is 1600, indicating the amount of data (e.g., bytes) that the sender can send, and wcale is 16, the network device will fill in a value of 100 for the WIN field. Optionally, in this scenario, the updated value of the WIN field in the ACK packet usually cannot exceed the original value of the WIN field. For example, if the original value of the WIN field is W2, the current value of the first parameter is w2, and the window scaling factor is wcale, the network device will update w2 / wcale to the new value of the WIN field if w2 / wcale is less than W2. Otherwise, the WIN field will retain its original value.

[0260] When a congestion control indication is carried in the first ACK packet, the network device sends a modified first ACK packet to the source of the data packet to convey the congestion control indication. This eliminates the need for additional messages or signaling to transmit the congestion control indication and maintains compatibility with existing congestion control mechanisms. Therefore, the source does not need to respond to additional messages or signaling, improving network compatibility and stability.

[0261] Of course, this application also applies to cases where the congestion control indication is not carried in the first ACK message.

[0262] In some other possible implementations, the network device may send a message or signaling to the source end, carrying a congestion control indication in the message or signaling. This message or signaling is different from the first ACK packet and is additionally generated information. This allows for decoupling of ACK packet transmission and congestion control without modifying the first ACK packet, improving the forwarding efficiency of the first ACK packet. In this implementation, this application does not need to issue a congestion indication after receiving the first ACK packet; that is, step S501 is an optional step. For example, the network device may periodically or non-periodically instruct the source end to control traffic. Exemplarily, after receiving a data packet from the source end, the network device determines the congestion indication corresponding to the local egress port (optionally including priority) of the data packet based on the data packet and sends a congestion control indication to the source end of the data packet.

[0263] exist Figure 5In the illustrated embodiment, data packets and ACK packets on the endpoint are forwarded by the network device. Therefore, the network device can locally perceive the network congestion level and maintain a corresponding relationship set. Based on the relationship set, the network device can quickly query the congestion status of a specified port and instruct the endpoint to control the traffic entering the network device, improving the real-time performance and accuracy of congestion control, reducing the probability of packet loss, increasing network throughput, and reducing FCT.

[0264] As can be seen from the preceding text, the correspondence set includes the congestion status of multiple ports. For multiple TCP flows passing through the network device, the network device can quickly obtain the congestion status by querying the correspondence set, and promptly instruct multiple endpoints to control the traffic entering the network. This allows for rapid and effective control of the traffic flowing into the network from multiple endpoints, thereby achieving congestion control.

[0265] Moreover, the adjustment mechanism of this application is multi-directional, possessing both acceleration and deceleration capabilities. This application can effectively control network congestion while reducing the impact of network jitter and bursts, further improving network throughput and reducing FCT.

[0266] Furthermore, this application can determine the network congestion status based on the local status of the network-side device, without relying on factors such as round-trip delay that are affected by transmission distance. This makes the congestion control mechanism provided by this application highly accurate in various transmission scenarios, such as long-distance transmission scenarios, short-distance transmission scenarios, and latency-sensitive scenarios.

[0267] Figure 5 The embodiments shown include a variety of possible implementations, which are described below in conjunction with... Figure 10 One possible implementation method is described. It should be understood that... Figure 10 Unless otherwise specified, the terminology, logic, and information content involved in the embodiments shown can be referred to... Figure 5 The example shown.

[0268] Please see Figure 10 , Figure 10 This is a flowchart of another congestion control method provided in an embodiment of this application. Optionally, this method is applied to the aforementioned communication system, such as... Figure 1 , Figure 2 , Figure 3 or Figure 4 The communication system shown. Figure 10 In the congestion control method, the source end can communicate with the first device, generating communication traffic, which includes TCP data traffic and ACK packets. Several second network devices exist between the source end and the first device, and the second network devices on the near end ( Figure 10 Implemented in network devices (represented in the middle) Figure 10The congestion control method shown.

[0269] like Figure 10 The congestion control method shown may include one or more steps from S1001 to S1006. It should be understood that, for ease of description, steps S1001 to S1006 are described in this way, but this embodiment does not limit the order of execution, the execution time, or the number of executions of the above one or more steps. Steps S1004 to S1006 are as follows:

[0270] Step S1001: The network device receives the first ACK packet.

[0271] The first ACK packet carries the source IP address, which is the IP address of the first device.

[0272] Step S1002: The network device determines the first port based on the source address of the first ACK packet.

[0273] For example, the network device uses the source IP address of the first ACK packet to find the reverse egress port of the first ACK packet, i.e., the first port. The reverse egress port of the first ACK packet is the local egress port of the data packet corresponding to the first ACK packet.

[0274] Step S1003: The network device determines the congestion indication of the first port.

[0275] Among them, background threads run within network devices, such as Figure 7 As shown. A background thread scans the network device's local queues to obtain queuing information, such as the local cache status. Based on this queuing information, the network device obtains the congestion indication for the corresponding port. This congestion indication can be saved to a port status table, which is a set of corresponding relationships. Optionally, the aforementioned background thread can be executed periodically, for example, collecting the network device's local queue queuing information every 1ms. Correspondingly, the port status table is also updated periodically, thereby achieving high-precision congestion awareness.

[0276] In one possible implementation, the network device looks up the corresponding set of relationships by the port identifier to obtain the congestion indication of the first port. For example, the network device can determine that the congestion indication of port 1 is "0" by looking up the corresponding set of relationships shown in Table 5 based on the identifier of the first port "port 1".

[0277] Optionally, the port queue can be specifically a queue corresponding to both the port and its priority. In this case, the congestion indicator can be specifically a priority corresponding to both the port and its priority, as shown in Table 11. Related descriptions can be found above. Figure 5 Detailed description of the illustrated embodiments.

[0278] Table 11: Port Congestion Indicators (with Priority)

[0279] Identification of port Priority or set of priorities Congestion indication Port 1 7 1 Port 1 6 0 Port 1 5 1 Port 1 4 1 …… …… …… Port 2 7 0 Port 2 6 0 Port 2 8 1 …… …… ……

[0280] In another possible implementation, the network device looks up the corresponding set of relationships by using the port identifier and priority information (indicator priority or priority set) to obtain the congestion indication that the first port and the first priority both correspond to. For example, the network device can determine that the congestion indication that port 1 and priority "7" both correspond to is "1" by looking up the corresponding set of relationships shown in Table 11 based on the identifier "port 1" and priority "7" of the first port.

[0281] The correspondence set includes the correspondence between the first port and its congestion indication. Further, it may include multiple ports in the network device and their respective congestion indications. The form of the correspondence set can be found in step S503. For example, the port's congestion indication may be in a suppression state. When the suppression state is value d1 (e.g., 1), it indicates that the network is not congested and traffic needs to be increased. When the suppression state is value d2 (e.g., 0), traffic needs to be suppressed. The determination method for values ​​d1 and d2 can be found in the rules shown in Tables 3 and 4 above.

[0282] As a possible example, see Figure 11 (a) The network device periodically samples the queuing information of the local queue and calculates the congestion probability k based on the queuing information. This congestion probability k is related to the following information: the number of queued packets, the proportion of the number of queued packets to the maximum capacity of the queue, the data volume of the queued packets, and the proportion of the data volume of the queued packets to the maximum capacity of the queue. For related descriptions, please refer to the above. Figure 5 The embodiments shown describe k. The network device further determines the suppression state based on the congestion probability. For example, the network device can obtain the suppression state based on the range in which k falls, as shown in the implementations in Tables 3 and 4.

[0283] It should be understood that the example provided here uses the values ​​0 and 1 for the suppression state. In actual implementations, the suppression state can include more values. For example, a suppression state of 00 indicates no congestion, 01 indicates possible mild congestion, 10 indicates moderate congestion, and 11 indicates severe congestion. The rate at which network devices slow down or speed up traffic varies depending on the level of congestion. The following description uses the values ​​0 and 1 for the suppression state as examples, and this application also uses the same method for indicating the suppression state.

[0284] Step S1004: The network device adjusts the first parameter according to the congestion indication.

[0285] like Figure 11 (a) and Figure 11 (b) When the congestion indication (i.e., the suppression state) is 1, a rate-deceleration control is triggered, and the network device adjusts the first parameter to its minimum value. When the congestion indication is 0, a rate-increase control is triggered, and the network device controls the first parameter to increase slowly.

[0286] The first parameter is used to indicate the amount of data that can be sent from the source. Since flow control can be achieved by modifying the value of the WIN field (i.e., RWND), the first parameter is also referred to as RWND in some schemes.

[0287] It should be noted that step S1003 may be executed periodically. The first parameter can be associated with the first port, or optionally with the first port and the first priority. The first priority is the priority of the first ACK packet or the priority of the data packet. For example, the first parameter is used to indicate that the local outgoing port of the data packet is the first port, and the priority is the traffic (i.e., the amount of data sent) of the source end with the first priority.

[0288] In some scenarios, step S1003 is not limited to being triggered upon receiving the first ACK. That is, steps S1003 and S1004 may be executed periodically or aperiodically within the network device.

[0289] As one possible implementation, after the network device receives the first ACK, it can determine the current value of the first parameter corresponding to the first port (optionally including the first priority) based on the first ACK, and update the RWND value of the first ACK packet based on the current value of the first parameter.

[0290] Step S1005: The network device modifies the RWND value of the first ACK packet.

[0291] Wherein, the RWND value, for example, is Figure 9A and Figure 9B The window size shown indicates the receive window size of the sender (i.e., the first device) of the first ACK packet, and is used to limit the amount of data that the source can send. The network device can adjust the amount of data that the source can send by modifying the RWND value of the first ACK packet.

[0292] As one possible implementation, the first parameter is used as the upper limit of the RWND value of the first ACK packet. If the RWND value of the first ACK packet is greater than the value of the first parameter, the network device modifies the RWND value of the first ACK packet to the value of the first parameter. If the RWND value of the first ACK packet is less than the value of the first parameter, the network device maintains the original value.

[0293] As another possible implementation, in the first ACK message, the RWND value and other fields are used together to limit the amount of data the source can send. For example, combined with... Figure 9A and Figure 9B The window size and window scaling factor fields together indicate the amount of data the source can send. Therefore, modifications to the RWND value of the first ACK packet should also take into account the value of the window scaling factor field.

[0294] For example, if the first parameter indicates that the source can send 1600 data points, and the window scaling factor wcale is 16, then the network device modifies the RWND value of the first ACK packet to 100. The RWND field and the window scaling factor are used to indicate that the source can send (100 * 16 =) 1600 data points.

[0295] Step S1006: The network device sends the updated first ACK packet to the source.

[0296] Accordingly, the source end can receive the updated first ACK packet, and thus determine the amount of data that can be sent based on the RWND value in the first ACK packet. Optionally, if the first ACK packet also carries a window scaling factor, the source end determines the amount of data that can be sent based on the RWND value and the window scaling factor.

[0297] exist Figure 10 In the illustrated embodiment, the network device can obtain queuing information of the queue corresponding to the port to calculate a congestion indication, and save the port's congestion indication to a port status table (i.e., a set of correspondences). The congestion indication corresponding to the port is used to indicate the port's congestion status. Further, the congestion indication corresponding to the first port can be used to adjust a first parameter, which controls the traffic at the source end of packets originating from the first port. After the network device receives the first ACK packet, it can modify the RWND value of the first ACK packet according to the first parameter, thereby controlling the amount of data that the source end can send.

[0298] First, network devices update their port status tables based on queuing information from local queues. Using this port status table, network devices quickly query the congestion status of a specified port and instruct the corresponding endpoints to control incoming traffic, improving the real-time performance and accuracy of congestion control, reducing packet loss probability, increasing network throughput, and reducing FCT (Fulfilled Cross-Count).

[0299] Secondly, the port's congestion status is used to adjust the value of the first parameter, enabling multi-directional adjustment of congestion control. While effectively controlling network congestion, it can reduce the impact of network jitter and bursts, further improving network throughput.

[0300] Finally, the amount of data that the source can send is controlled by modifying the RWND value of the first ACK packet. This method does not require the use of additional messages or signaling to transmit congestion control instructions and is compatible with existing congestion control mechanisms. Therefore, the source does not need to respond to additional messages or signaling, which improves the compatibility and stability of the network.

[0301] above Figure 5 and Figure 10 Some congestion control methods have been introduced. The following section will combine... Figure 12 This application introduces yet another congestion control method provided by an embodiment. Optionally, Figure 12 The congestion control method shown can be applied to the aforementioned communication systems, such as... Figure 1 , Figure 2 , Figure 3 or Figure 4 The communication system shown. (As shown) Figure 12 The congestion control method shown may include one or more steps from S1201 to S1203. It should be understood that, for ease of description, the steps S1201 to S1203 are described in sequence, but this embodiment does not limit the order of execution, the execution time, or the number of executions of the above one or more steps. Steps S1201 to S1203 are as follows:

[0302] Step S1201: The first network device receives the first ACK packet.

[0303] The first network device is a device with packet forwarding capabilities, such as a switch or router. For example, a network device could be... Figure 1 The first network device 103 is shown. Further, the first network device is a near-end network device, such as an access layer network device, an aggregation layer network device, or a core layer network device, such as a CE, BE, access layer switch, aggregation layer switch, etc. Optionally, the first network device is a near-end device.

[0304] The first ACK packet carries the address of the sender of the first ACK packet (referred to as the first source address for easy distinction) and the address of the receiver of the first ACK packet (i.e., the source of the first data packet) (referred to as the first destination address for easy distinction). The first source address is, for example, SIP, and the first destination address is, for example, DIP.

[0305] The first ACK message is used to report the reception status of the first data packet. See the description of step S501 for a related description.

[0306] Step S1202: The first network device determines the first-level congestion indication.

[0307] In this context, a stream refers to a TCP stream, which is a data flow transmitted between a source and a destination. In the TCP protocol, data transmission is reliable, full-duplex, and connection-oriented. TCP streams ensure reliable data delivery through specific mechanisms such as three-way handshakes, positivity, and retransmission. In some schemes, a TCP stream is uniquely identified by five elements: transport protocol type, source IP address, source port, destination IP address, and destination port; these elements are often referred to as a 5-tuple. However, in some cases, a TCP stream can also be associated with a 2-tuple or a 4-tuple. A 2-tuple includes the source and destination IP addresses, while a 4-tuple includes the source, source, and destination IP addresses and ports. See Table 12; the first network device can identify a TCP stream based on the source and destination IP addresses. Of course, other information, such as the transport protocol type and source or destination port, may also be used in determining the stream's identifier.

[0308] Table 12 Information about TCP streams

[0309] Source IP Destination IP …… Identification of flow SIP1 DIP1 …… Flow 1 SIP2 DIP2 …… Flow 2 SIP3 DIP3 …… Flow 3 SIP1 DIP1 …… Flow 4 …… …… …… ……

[0310] The first flow is the data flow (i.e., TCP flow) between the first source address and the first destination address. See Table 12. For example, if the source IP address is SIP1 and the first device IP address is DIP1, then the first flow is the TCP flow identified as flow 1.

[0311] A flow congestion indicator is used to indicate the degree of congestion in a flow. For example, a congestion indicator can be expressed as a percentage, level, number, or status flag (e.g., flag, field value, etc.). For details regarding the specific content of congestion indicators, please refer to the relevant descriptions in Tables 5 to 9 above.

[0312] The following describes the process of generating flow congestion indicators.

[0313] As one possible implementation, the first network device determines a congestion indication for the first TCP stream based on congestion data corresponding to the first TCP stream. The congestion data corresponding to the first TCP stream includes one or more of the following: the number of packets in the first TCP stream marked as congested, the proportion of packets in the first TCP stream marked as congested, the number of packets in the first TCP stream not marked as congested, and the proportion of packets in the first TCP stream not marked as congested.

[0314] In some schemes, when a packet is forwarded in the network, a network device (referred to as the second network device for easy distinction) can include a congestion notification field in the packet based on network conditions. This congestion notification field is used to indicate whether the network through which the packet passes is congested. When the first network device receives the packet, it can obtain congestion data based on the value of the congestion notification field, and this congestion data can reflect the degree of network congestion.

[0315] Please refer to Table 13, which is a congestion data illustration table provided in an embodiment of this application. The congestion data indicates the number of packets marked as congested and / or the number and / or proportion of packets marked as non-congested in the flow. Based on this congestion data, the congestion indication of the flow can be determined. For example, using the congestion probability as k, when k falls into the third range (e.g., k ≤ x2), the congestion indication value is d1; when k falls into the fourth range (e.g., k ≥ x3), the congestion indication value is d2; and when k falls into the fifth range (e.g., x2 < k < x3), the congestion indication value is calculated using a predefined algorithm, for example, determined to be either d1 or d2 with a certain probability. This probability can be predefined or user-defined. Related explanations can be found in the description of Table 4. Of course, this application also uses the implementation methods such as those in Table 3.

[0316] Table 13 Stream congestion data

[0317]

[0318] Optionally, in the above embodiments, the TCP stream packets may include data packets and / or ACK packets. For example, the first network device obtains the congestion flags of the data packets in the first TCP stream to obtain the congestion data of the first TCP stream, thereby determining the congestion status of the source network.

[0319] Combination Figure 1 and Figure 13The data packet sent by the source device 101 includes an ECN (Electronic Congestion Notification) field. This data packet is forwarded by the second network device 104. When the second network device 104 detects network congestion, it can set the value of the ECN field in the data packet to a certain value (referred to as the second value for easy distinction), indicating that the network through which the data packet passed is congested. Similarly, if the ECN field of a data packet forwarded by the second network device is a third value, it indicates that the network through which the data packet passed is not congested. The first network device 103 can update the congestion data of the TCP stream based on the congestion notification field in the data packet. This TCP stream congestion data can be used to determine the congestion indication of the TCP stream. For example, if a large number of data packets in a TCP stream are marked as congested by the second network device 104 in the preceding segment, the first network device 103 can determine that the TCP stream is severely congested. Conversely, if a small number or no data packets in a TCP stream are marked as not congested by the second network device 104 in the preceding segment, the first network device 103 can determine that the congestion level of the TCP stream is not severe.

[0320] As a possible example, combining Figure 13 The first network device 103 can receive a data packet (e.g., referred to as a second data packet) and determine the TCP flow to which the second data packet belongs, at least based on the SIP and DIP values ​​in the second data packet. For example, it can look up the identifier of the flow corresponding to the second data packet based on the SIP and DIP values. The first network device 103 updates the congestion data corresponding to the flow corresponding to the second data packet based on the value of the congestion notification field of the second data packet, and then determines the congestion indication of the flow based on the congestion data corresponding to the flow.

[0321] In some possible implementations, congestion data is time-sensitive, allowing congestion indicators to more accurately reflect the current network congestion status. For example, the congestion indicator becomes invalid for data packets that have exceeded a certain duration; that is, the data corresponding to data packets that have exceeded a certain duration undergoes aging processing. In specific implementations, this can be manifested as follows: if a data packet reaches the aging condition, the congestion data is updated accordingly, which may further trigger an update to the congestion indicator.

[0322] As a possible example, the congestion data corresponding to the first TCP stream includes at least one of the following: the number of packets in the first TCP stream marked as congested within a first time period, the percentage of packets in the first TCP stream marked as congested within the first time period, the number of packets in the first TCP stream not marked as congested within a second time period, and the percentage of packets in the first TCP stream not marked as congested within the second time period.

[0323] The content and generation process of congestion indicators have been introduced above. The following describes two methods for determining congestion indicators.

[0324] As one possible method for determining congestion indication, after receiving the first ACK packet, the network device determines the first TCP flow based on the source and destination addresses of the first ACK packet, and then determines the congestion indication of the first TCP flow based on the congestion data of the first TCP flow. In this implementation, the congestion indication of the first TCP flow is generated after receiving the first ACK packet.

[0325] As another possible method for determining congestion indications, network devices can maintain a state table for TCP flows. Based on the congestion data of TCP flows, congestion indications can be obtained periodically or aperiodically and stored in a mapping set. These congestion indications are then associated with the identifiers of the TCP flows. In subsequent processes, the network device can determine the corresponding congestion indication for a TCP flow from the mapping set using its identifier. In this way, the network device only needs to update the mapping set in a timely manner to accurately represent the congestion levels of multiple TCP flows and perform precise flow control on multiple TCP flows, reducing the complexity of congestion control implementation.

[0326] The following describes the content of the correspondence set in the embodiments of this application, as well as some possible implementations.

[0327] In summary, the first set of correspondences includes the identifier of a flow and the congestion indication corresponding to that flow, and there is a correspondence between the flow identifier and the congestion indication corresponding to that flow. For ease of understanding, the following lists one possible implementation of the set of correspondences in conjunction with Table 14. Other possible implementations can be found in the relevant descriptions in Tables 5, 6, and 7 above.

[0328] Table 14 Flows and Corresponding Congestion Indicators

[0329]

[0330]

[0331] As transmission continues, packets constantly pass through network devices, causing the congestion data of the TCP stream to change continuously. Network devices need a mechanism to promptly determine the congestion indication for the corresponding port based on the congestion data of the TCP stream and update the corresponding relationship set.

[0332] In one possible implementation, the network device periodically updates the mapping set based on congestion data of the flow. Optionally, the duration of the update period for the mapping set (such as a first duration) is relatively short, for example, less than 1 ms.

[0333] In another possible implementation, the network device can set a certain threshold for congested data. For example, when the number of packets marked as congested in the first TCP stream within a first time period is greater than or equal to a first quantity threshold, the corresponding relationship set is updated.

[0334] Step S1203: The first network device sends a congestion control instruction to the source.

[0335] Among them, the congestion control indicator is used to control the amount of data that the source can send, such as one or more of the following: the number of bytes or the number of data packets.

[0336] As one possible implementation, congestion control indicators are used to indicate the size (e.g., maximum number of bytes) of data service units that a data link layer entity can receive.

[0337] As another possible implementation, congestion control indicators are used to indicate the maximum length of the data payload portion of the transport layer.

[0338] In some scenarios, congestion control indicators are used to indicate the amount of data that the source can send. These indicators include direct and indirect indications. For example, congestion control indicators can be used to indicate window values, which may include one or more of the following: a congestion window, a receive window, or a send window. In other scenarios, congestion control indicators are used to indicate the direction of change in the amount of data that the source can send, which may include one or more of the following: increasing, decreasing, or maintaining.

[0339] The congestion control indication is related to the congestion indication of the first port. For example, the first network device can directly determine the congestion control indication based on the congestion indication, or the first network device can determine the congestion control indication based at least on a first parameter, but the first parameter is updated through the congestion indication. Optionally, the method for updating the first parameter can be found in [reference needed]. Figure 5 , Figure 10 The embodiments shown are described below.

[0340] In one possible implementation, the first network device applies a greater force to rate reduction control than rate increase control during congestion control. For example, taking the congestion control indication as determined at least by a first parameter, when the congestion indication at the first port meets the traffic suppression condition, the first parameter is reduced to its minimum value, and this minimum value is used as the new base value for the first parameter. Conversely, when the congestion indication at the first port does not meet the traffic suppression condition, the first parameter is increased by a first value based on its base value to obtain a new base value for the first parameter. In this implementation, when traffic suppression is required, the receive window value is reduced to its minimum to achieve rapid traffic suppression. When traffic suppression is not required, the value of the first parameter is increased slowly (by the first value) to control the slow increase of traffic. Optionally, the first value is less than half the width of the range of values ​​for the first parameter, for example, less than 1 / 4, 1 / 6, or 1 / 8 of the width of the range of values ​​for the first parameter.

[0341] In some possible implementations, the first network device may forward a congestion control indication to the source by including it in a first ACK packet. In yet other possible implementations, the first network device may send a message or signaling to the source, carrying the congestion control indication in the message or signaling.

[0342] For a detailed description of step S1203, please refer to the description of step S504.

[0343] exist Figure 12 In the illustrated embodiment, the first network device can locally sense the congestion level of the TCP flow, determine the congestion indication of the TCP flow, and instruct the end-side to control the traffic entering the network device through a congestion control indication. Since the congestion control indication is related to the congestion indication, and the congestion indication may indicate different levels of congestion, when the TCP flow is congested, a rate-reduction control is triggered, i.e., the source end is controlled to reduce the traffic entering the network. Conversely, when the TCP flow is not congested, a rate-increase control is triggered, i.e., the source end is controlled to increase the traffic entering the network.

[0344] Moreover, in this application, the network device implements congestion control based on locally determined congestion indicators, without relying on factors such as round-trip delay that are affected by transmission distance. This makes the application have high control accuracy in various transmission scenarios, such as long-distance transmission scenarios, short-distance transmission scenarios, or latency-sensitive scenarios.

[0345] Furthermore, the congestion control method of this application is deployed on the network side, which makes the congestion control mechanism easy to upgrade, does not affect the functionality of the terminal side, can adapt to terminal sides with different capabilities, and has good compatibility.

[0346] In some possible designs, multiple embodiments of this application may be combined without mutual exclusion.

[0347] As one possible implementation, the first network device comprehensively evaluates the congestion indication of the first TCP stream based on the queuing information of the local port queue and the congestion data of the first TCP stream, and determines the control indication.

[0348] As another possible implementation, the first network device can determine the congestion control indication based on port congestion indications and flow congestion indications, and possibly even in combination with other congestion signals (such as signals provided to the first network device by other network devices). For example, the first network device can maintain multiple sets of correspondences. Taking a first set of correspondences and a second set of correspondences as examples, the first set includes port identifiers and port congestion indications, and the second set includes flow identifiers and flow congestion indications. The congestion control indication can be determined based on the port congestion indications and flow congestion indications.

[0349] For example, among the congestion indication and the flow congestion indication, the congestion indication with a more severe congestion level can generate a congestion control indication. For instance, combining Tables 5 and 8, if the local outgoing port of the first data packet is port 1 and the first TCP flow to which the first data packet belongs is flow 1, since the congestion indication of port 1 is 0 (i.e., the network connected to port 1 is not congested) but the congestion indication of the first TCP flow is 1 (i.e., the network through which the first TCP flow passes is congested), then network congestion is still determined, and rate reduction control is triggered.

[0350] The methods of the embodiments of this application have been described in detail above. The apparatus of the embodiments of this application is provided below.

[0351] It should be understood that the division of units in the apparatus provided in the embodiments of this application is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Whether a certain function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0352] For example, the units in the device can be implemented by a processor calling software. For example, the device includes a processor connected to a memory that stores instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of the units in the device. The processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is either internal or external to the device.

[0353] Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all of the units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the above units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all of the above units.

[0354] In some solutions, the functional modules of the device can be divided according to the aforementioned methods. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used.

[0355] When dividing each function into modules according to its corresponding function. Figure 14 A schematic diagram of a congestion control device provided in this application is shown. The congestion control device 140 can be a standalone device, such as a network device, or a component included in a standalone device, such as a chip, software module, or integrated circuit in the network device. This congestion control device 140 is used to implement the aforementioned congestion control method, for example... Figure 5 , Figure 10 ,or Figure 12 The congestion control method shown in the embodiments.

[0356] For example, the congestion control device 140 includes a processing unit 1401 and a communication unit 1402. The processing unit 1401 is used to perform calculations and / or data processing. The communication unit 1402 is used to send and / or receive data, or to input and / or output data.

[0357] For example, the processing unit 1401 is used to perform the aforementioned information processing, data generation, determination, decision-making, and judgment operations. The communication unit 1402 is used to perform receiving, sending, and acquiring operations.

[0358] In one possible design, the congestion control device 140 is used to perform... Figure 5 , Figure 10 The congestion control method described in the embodiments is a method executed by a network device.

[0359] In one possible implementation, communication unit 1402 is configured to receive a first ACK packet from a first device. Processing unit 1401 is configured to: determine a first port based on the source address of the first ACK packet and determine a congestion indication for the first port. Communication unit 1402 is further configured to send a congestion control indication to the source of the first data packet. For detailed descriptions of the specific content and steps of each piece of information, please refer to the foregoing method embodiments.

[0360] In another possible implementation, the processing unit 1401 is further configured to update the value of the window size (WIN) field in the first ACK message, the window size field being used to carry congestion control indications.

[0361] In another possible implementation, the processing unit 1401 is further configured to perform a route lookup based on the source address of the first ACK packet to determine the first port.

[0362] In another possible implementation, the processing unit 1401 is further configured to determine the congestion indication of the first port based on the identifier and the correspondence set of the first port, the correspondence set including the identifier of the first port and the congestion indication of the first port.

[0363] In another possible implementation, the first ACK message further includes a first priority. The congestion indication of the first port includes a congestion indication that corresponds to both the first port and the first priority. The processing unit 1401 is further configured to determine the congestion indication that corresponds to both the first port and the first priority. The congestion control indication is related to the congestion indication that corresponds to both the first port and the first priority, and the congestion control indication is used to control the amount of data with a first priority that the source can send.

[0364] In another possible implementation, the processing unit 1401 is further configured to determine a congestion indication that is jointly corresponding to the first port and the first priority based on the identifier and the correspondence set of the first port, wherein the correspondence set includes the identifier of the first port, the first priority and the congestion indication that is jointly corresponding to the first port and the first priority.

[0365] In another possible implementation, the processing unit 1401 is further configured to: detect the local queue of the first port to obtain queuing information of the local queue of the first port. The congestion indication of the first port is related to the queuing information of the local queue of the first port.

[0366] In another possible implementation, the processing unit 1401 is further configured to: obtain a congestion indication for the first port based on the queuing information of the local queue of the first port and save it to a correspondence set. Further, the processing unit 1401 is further configured to: determine the congestion indication for the first port based on the identifier of the first port and the correspondence set.

[0367] In another possible implementation, the processing unit 1401 is further configured to: detect the local queues of multiple ports in the network device to obtain queuing information of the local queues of multiple ports, and obtain congestion indications for multiple ports respectively based on the queuing information of the local queues of multiple ports.

[0368] Processing unit 1401 is also used to update the congestion indications corresponding to the identifiers of multiple ports in the correspondence set.

[0369] In another possible implementation, the processing unit 1401 is further configured to: determine a congestion control instruction based on the congestion indication.

[0370] In another possible implementation, the processing unit 1401 is further configured to: determine a congestion control indication based at least on a first parameter, the first parameter being determined by a congestion indication of a first port, the first parameter being used to indicate the amount of data that the source end can send.

[0371] In another possible implementation, the processing unit 1401 is further configured to: reduce the first parameter to a preset reference value and use the reference value as the base value of the first parameter when the congestion indication of the first port meets the flow suppression condition; and, when the congestion indication of the first port does not meet the flow suppression condition, increase the first parameter by a first value based on the base value to obtain a new base value for the first parameter.

[0372] In another possible implementation, the first ACK message also includes a window scaling factor field. Processing unit 1401 is further configured to: determine a congestion control indication based on the first parameter and the value of the window scaling factor field, the window scaling factor field indicating the multiple by which the receive window value is scaled.

[0373] For related descriptions, please refer to the descriptions in the foregoing embodiments, which will not be repeated here.

[0374] In another possible design, the congestion control device 140 is used to perform... Figure 12 The congestion control method described in the illustrated embodiment is a method performed by a first network device.

[0375] In one possible implementation, communication unit 1402 is used to receive a first ACK packet from the first device. Processing unit 1401 is used to determine a congestion indication of the first TCP stream. Communication unit 1402 is also used to send a congestion control indication to the source of the first data packet. For a detailed description of the specific content and steps of each piece of information, please refer to the foregoing method embodiments.

[0376] In another possible implementation, processing unit 1401 is further configured to update the value of the window size field in the first ACK packet, the window size field being used to carry a congestion control indication. Communication unit 1402 is further configured to send the updated first ACK packet to the source of the first data packet.

[0377] In another possible implementation, the processing unit 1401 is further configured to determine the identifier of the first first class based on the first source address, the first destination address, and the data flow table.

[0378] In another possible implementation, the processing unit 1401 is further configured to determine the congestion indication of the first TCP stream based on the identifier and the corresponding set of the first TCP stream, wherein the corresponding set includes the identifier of the first TCP stream and the congestion indication corresponding to the first TCP stream.

[0379] In another possible implementation, the processing unit 1401 is further configured to determine the congestion indication of the first TCP stream based on the congestion data corresponding to the first TCP stream.

[0380] In another possible implementation, the communication unit 1402 is further configured to receive a first data packet forwarded from the second network device. The first data packet includes a source address, a destination address, and a congestion notification field. The congestion notification field includes information indicating whether congestion has occurred in the network traversed by the first data packet. The processing unit 1401 is further configured to update the congestion data corresponding to the first TCP stream based on the source address, destination address, and congestion notification field value of the first data packet.

[0381] In another possible implementation, the processing unit 1401 is further configured to determine a congestion control instruction based on the congestion indication.

[0382] In another possible implementation, the processing unit 1401 is further configured to determine a congestion control indication based at least on a first parameter, the first parameter being determined by a congestion indication of the first TCP stream, the first parameter being used to indicate the amount of data that the source can send.

[0383] In another possible implementation, the processing unit 1401 is further configured to reduce the first parameter to a preset baseline value and use the baseline value as the base value of the first parameter when the congestion indication of the first TCP stream meets the traffic suppression condition, and to increase the first parameter by a first value based on the base value to obtain a new base value of the first parameter when the congestion indication of the first TCP stream does not meet the traffic suppression condition.

[0384] In another possible implementation, the first ACK message also includes a window scaling factor field. Processing unit 1401 is further configured to determine a congestion control indication based on the first parameter and the value of the window scaling factor field, the window scaling factor field indicating the multiplier by which the receive window value is scaled.

[0385] For related descriptions, please refer to the descriptions in the foregoing embodiments, which will not be repeated here.

[0386] Please see Figure 15 , Figure 15 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. The network device 150 may include at least one processor 1501 and a memory 1503. Optionally, it may also include a communication interface 1502. Further optionally, it may also include a connection line 1504, wherein the processor 1501, the communication interface 1502 and / or the memory 1503 are connected through the connection line 1504, and / or communicate with each other through the connection line 1504 to transmit control signals and / or data signals.

[0387] in:

[0388] Processor 1501 is a module that performs arithmetic and / or logical operations, and may specifically include one or more of the following modules: filter, modem, power amplifier, low noise amplifier (LNA), baseband processor, radio frequency processor, radio frequency circuit, central processing unit (CPU), application processor (AP), microcontroller unit (MCU), electronic control unit (ECU), graphics processing unit (GPU), microprocessor unit (MPU), application specific integrated circuit (ASIC), image signal processor (ISP), digital signal processor (DSP), field programmable gate array (FPGA), complex programmable logic device (CPLD), or coprocessor, etc.

[0389] The communication interface 1502 can be used to provide information input or output to at least one processor, or to receive and / or transmit signals to externally transmitted signals. For example, the communication interface 1502 may include interface circuitry. For instance, the communication interface 1502 may include a wired link interface such as an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission, vehicular short-range communication technology, and other short-range wireless communication technologies, etc.). Optionally, the communication interface 1502 may also include a radio frequency transmitter, an antenna, etc. If the communication interface 1502 includes an antenna, the number of antennas can be one or more.

[0390] As one possible design, if the network device 150 is a standalone device, the communication interface 1502 may include a receiver and a transmitter. The receiver and transmitter may be the same component or different components. When the receiver and transmitter are the same component, this component may be referred to as a transceiver.

[0391] As another possible design, if the network device 150 is a chip or circuit, the communication interface 1502 may include an input interface and an output interface, which may be the same interface or different interfaces.

[0392] Alternatively, the functionality of the communication interface 1502 can be implemented via a transceiver circuit or a dedicated transceiver chip.

[0393] The memory 1503 provides storage space, in which data such as the operating system and computer programs can be stored. The memory 1503 can be one or a combination of several of the following: random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0394] The functions and actions of each module or unit in the network device 150 listed above are merely illustrative examples.

[0395] The functional units in network device 150 can be used to implement the aforementioned congestion control method, for example... Figure 5 , Figure 10 ,or Figure 12 The congestion control methods shown are, for example, methods performed by network devices.

[0396] Optionally, the processor 1501 may be a processor specifically designed to perform the aforementioned methods (for ease of distinction, referred to as a dedicated processor), or a processor that performs the aforementioned methods by calling a computer program (for ease of distinction, referred to as a dedicated processor). Optionally, at least one processor may include both dedicated processors and general-purpose processors.

[0397] Optionally, if the network device 150 includes at least one memory 1503, and the processor 1501 implements the aforementioned congestion control method by calling a computer program, the computer program can be stored in the memory 1503.

[0398] This application also provides a chip, which includes logic circuitry and a communication interface. The communication interface is used to receive or transmit signals; the logic circuitry is used to receive or transmit signals through the communication interface. The chip is used to implement the aforementioned congestion control method, for example... Figure 5 , Figure 10 ,or Figure 12The congestion control methods shown are as follows.

[0399] This application also provides a computer-readable storage medium storing instructions that, when executed on at least one processor (or network device), implement the aforementioned congestion control method, for example... Figure 5 , Figure 10 ,or Figure 12 The congestion control methods shown are as follows.

[0400] This application also provides a computer program product, which includes computer instructions for implementing the aforementioned congestion control method, for example... Figure 5 , Figure 10 ,or Figure 12 The congestion control methods shown are as follows.

[0401] It should be noted that, in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0402] In this embodiment, the names of information and devices are exemplarily chosen for ease of understanding of the content of this solution. In specific implementations, their names may be designed differently. Furthermore, the names of the same thing may also be designed differently in different scenarios (e.g., different communication layers).

[0403] In the embodiments of this application, "at least one" refers to one or more items, and "more than one" refers to two or more items. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items.

[0404] For example, at least one of a, b, or c can be represented as: a, b, c, (a and b), (a and c), (b and c), or (a and b and c), where a, b, and c can be single or multiple. "AND / OR" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "OR" relationship.

[0405] Furthermore, unless otherwise stated, the ordinal numbers such as "first," "second," "M1," "M2," "M3," "M4," "M5," "S1," "S2," and "S3" used in the embodiments of this application are for distinguishing multiple objects and are not used to limit the order, sequence, priority, or importance of multiple objects. Similarly, terms like "first node" and "second node" are merely for the convenience of describing new parameters in different implementations and do not indicate differences in their execution operations, importance, structure, etc.

[0406] In the above embodiments, the term "when..." can be interpreted, depending on the context, as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". The above descriptions are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the concept and principles of this application should be included within the protection scope of this application.

[0407] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

Claims

1. A congestion control method, characterized in that, Applied to network devices, the method includes: Receive a first acknowledgment (ACK) message from the first device. The first ACK message is used to provide feedback on the reception status of the first data message. The first ACK message includes the source address of the first ACK message. The first port is determined based on the source address of the first ACK packet, and the first port is the local output port of the first data packet; Determine the congestion indication of the first port, which is used to indicate the degree of congestion of the first port; A congestion control indication is sent to the source of the first data packet. The congestion control indication is used to control the amount of data that the source can send. The congestion control indication is related to the congestion indication of the first port.

2. The method according to claim 1, characterized in that, The congestion control indicator is used to indicate a window value, which in turn indicates the amount of data that the source can send.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Update the value of the window size field in the first ACK packet, the window size field being used to carry the congestion control indication; Sending a congestion control indication to the source of the first data packet includes sending an updated first ACK packet to the source of the first data packet.

4. The method according to any one of claims 1-3, characterized in that, The determination of the congestion indication of the first port includes: Based on the identifier and the set of correspondences of the first port, the congestion indication of the first port is determined, wherein the set of correspondences includes at least the identifier of the first port and the congestion indication of the first port.

5. The method according to any one of claims 1-3, characterized in that, The first ACK packet also includes a first priority; the congestion indication of the first port includes a congestion indication that corresponds to both the first port and the first priority. The determination of the congestion indication of the first port includes: Determine the congestion indication that corresponds to both the first port and the first priority; The congestion control indication is related to the congestion indication that corresponds to the first port and the first priority. The congestion control indication is used to control the amount of data that the source end can send with the first priority.

6. The method according to claim 5, characterized in that, The step of determining the congestion indication corresponding to the first port and the first priority includes: Based on the identifier and correspondence set of the first port, a congestion indication corresponding to both the first port and the first priority is determined. The set of correspondences includes the identifier of the first port, the first priority, and the congestion indication that corresponds to both the first port and the first priority.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: The local queue of the first port is detected to obtain the queuing information of the local queue of the first port. The congestion indication of the first port is related to the queuing information of the local queue of the first port.

8. The method according to claim 7, characterized in that, The operation of detecting the local queue of the first port is performed periodically with a period of less than 1 millisecond.

9. The method according to any one of claims 1-8, characterized in that, The method also includes: The congestion control indication is determined based on at least a first parameter, which is determined by the congestion indication of the first port. The first parameter is used to indicate the amount of data that the source can send.

10. The method according to claim 9, characterized in that, The method further includes: When the congestion indication of the first port meets the flow suppression condition, the first parameter is reduced to a preset reference value and the reference value is used as the base value of the first parameter; When the congestion indication of the first port does not meet the traffic suppression condition, the first parameter is increased by a first value based on the base value to obtain a new base value for the first parameter.

11. The method according to claim 10, characterized in that, The first value is less than half the width of the range of values ​​for the first parameter.

12. The method according to any one of claims 9-11, characterized in that, The first ACK packet also includes a window expansion factor field; the determination of the congestion control indication based at least on the first parameter includes: The congestion control indication is determined based on the value of the first parameter and the window scaling factor field, wherein the window scaling factor field is used to indicate the multiplier by which the window value is scaled.

13. A congestion control method, characterized in that, Applied to a first network device, the method includes: Receive a first acknowledgment (ACK) message from the first device, the first ACK message including a first source address and a first destination address; Determine the congestion indication of the first TCP stream, where the first TCP stream is the TCP stream between the first source address and the first destination address, and the congestion indication of the first TCP stream is used to indicate the degree of congestion of the first stream; A congestion control indication is sent to the source of the first data packet. The congestion control indication is used to control the amount of data that the source can send. The congestion control indication is related to the congestion indication of the first port.

14. The method according to claim 13, characterized in that, The congestion control indicator is used to indicate a window value, which in turn indicates the amount of data that the source can send.

15. The method according to any one of claim 13 or 14, characterized in that, The method further includes: Update the value of the window size field in the first ACK packet, where the first field is used to carry the congestion control indication; Sending a congestion control indication to the source of the first data packet includes sending an updated first ACK packet to the source of the first data packet.

16. The method according to any one of claims 13-15, characterized in that, The determination of the congestion indication of the first TCP stream includes: Based on the identifier and the corresponding set of the first TCP stream, the congestion indication of the first TCP stream is determined, wherein the corresponding set includes the identifier of the first TCP stream and the congestion indication corresponding to the first TCP stream.

17. The method according to any one of claims 13-16, characterized in that, The method further includes: Based on the congestion data corresponding to the first TCP stream, determine the congestion indication of the first TCP stream. The congestion data corresponding to the first TCP stream includes one or more of the following: the number of packets marked as congested in the first TCP stream, the proportion of packets marked as congested in the first TCP stream, the number of packets not marked as congested in the first TCP stream, and the proportion of packets not marked as congested in the first TCP stream.

18. The method according to claim 17, characterized in that, The method further includes: The system receives the first data packet forwarded from the second network device. The first data packet includes the source address of the first data packet, the destination address of the first data packet, and a congestion notification field. The congestion notification field includes a marker indicating whether the network through which the first data packet passes is congested. Update the congestion data corresponding to the first TCP stream based on the source address, destination address, and congestion notification field value of the first data packet.

19. The congestion control method according to any one of claims 13-18, characterized in that, The method also includes: The congestion control indication is determined based at least on a first parameter, which is updated by the congestion indication of the first TCP stream. The first parameter is used to indicate the amount of data that the source can send.

20. The congestion control method according to claim 19, characterized in that, Before sending a congestion control indication to the source of the first data packet, the method further includes: When the congestion indication of the first port meets the flow suppression condition, the first parameter is reduced to a preset reference value and the reference value is used as the base value of the first parameter; When the congestion indication of the first port does not meet the traffic suppression condition, the first parameter is increased by a first value based on the base value to obtain a new base value for the first parameter.

21. The method according to claim 20, characterized in that, The first value is less than half the width of the range of values ​​for the first parameter.

22. The method according to any one of claims 19-21, characterized in that, The first ACK packet also includes a window expansion factor field; the determination of the congestion control indication based at least on the first parameter includes: The congestion control indication is determined based on the value of the first parameter and the window scaling factor field, wherein the window scaling factor field is used to indicate the multiplier by which the window value is scaled.

23. A congestion control device, characterized in that, The congestion control device includes a communication unit and a processing unit, wherein the communication unit is used to send and / or receive data. The processing unit is used to perform calculation operations. The congestion control device is used to implement the congestion control method according to any one of claims 1-12, or the congestion control device is used to implement the congestion control method according to any one of claims 13-22.

24. A network device, characterized in that, The network device includes multiple ports, a processor, and a memory. The multiple ports are used to send and / or receive messages; The memory is used to store computer instructions. The processor is used to read computer program instructions stored in the memory to implement the method according to any one of claims 1-22.

25. A communication system, characterized in that, The communication system includes a first network device, a source end, and a first device. The first network device is used to forward packets between the source and the first device. The first network device includes the congestion control device as described in claim 23, or the first network device is the second network device as described in claim 24.

26. The communication system according to claim 25, characterized in that, The communication system also includes a second network device. The second network device is used to forward data packets from the source end to the first network device, and to forward ACK packets forwarded by the first network device to the source end.

27. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a processor, cause the network device in which the processor resides to implement the method described in any one of claims 1-22.

28. A computer storage medium, characterized in that, The computer storage medium includes instructions that, when executed by a processor, cause the network device in which the processor resides to implement the method described in any one of claims 1-22.