Congestion control methods and splitter systems for lossless networks

Abstract

This application relates to a congestion control method and a traffic splitter system for lossless networks. The method includes: collecting the queue depth of each output port; comparing the queue depth with a congestion threshold to determine the congestion state, where the congestion state includes multiple congestion levels corresponding to a set of linked response parameters; obtaining cache depth configuration parameters and traffic splitting weights from the linked response parameter set based on the current congestion level, with the two jointly generated within the same decision cycle and inversely correlated for the same output port; performing cache depth adjustment, scheduling priority adjustment, and traffic allocation based on the linked response parameter set; statistically analyzing the packet loss rate change within the evaluation window after the adjustment action, and upgrading the congestion level and re-jointly deciding when the adjustment is ineffective. This application couples the decisions of caching, scheduling, and traffic splitting into an inseparable joint generation process through the linked response parameter set, and drives inter-stage jumps with closed-loop feedback, reducing packet loss caused by micro-burst traffic in high convergence ratio scenarios.

Description

Technical Field

[0001] This application relates to the field of network engineering, and in particular to a congestion control method and a diverter system for lossless networks. Background Technology

[0002] In scenarios such as data centers and network security auditing, network splitters are responsible for aggregating traffic from multiple input ports and distributing it to multiple output ports. When the total bandwidth of the input ports is higher than the total bandwidth of the output ports, a forwarding architecture with a high convergence ratio is formed. Under this architecture, even if the peak rate of the output port, measured in seconds, is much lower than its rated bandwidth, transient traffic bursts on the microsecond to millisecond scale can still cause a brief backlog in the forwarding queue of the output port, resulting in packet loss. This packet loss phenomenon caused by transient bursts rather than continuous overload is particularly prominent in lossless networks that require zero packet loss.

[0003] Existing network traffic splitters typically configure and operate cache management, priority scheduling, and traffic distribution as independent functional modules when addressing the aforementioned congestion issues. The cache management module allocates cache space according to a preset static threshold, the priority scheduling module maintains a fixed scheduling weight, and the traffic splitting module distributes traffic evenly to each output port according to fixed strategies such as round-robin. Each module makes decisions based on its own independent criteria, and there are no data-level constraints or linkages between the decision results.

[0004] This decentralized, independent decision-making approach suffers from a core flaw that runs through all stages: the response directions of different modules to the same congestion event may contradict each other. When a micro-burst occurs, the cache management module may have already expanded the cache on the congested port to absorb more packets, but the traffic distribution module, lacking linkage constraints with the cache state, continues to evenly distribute traffic to that port. The expanded cache not only fails to alleviate the backlog but is also quickly filled up due to attracting more traffic, creating a positive feedback loop of "cache expansion → traffic influx → cache overflow again." Simultaneously, the priority scheduling module, not being updated synchronously with cache expansion actions and changes in traffic distribution weights, may have scheduling behavior that conflicts with the cache allocation direction, such as scheduling high-priority traffic to a port with a full cache. The asynchronous execution of decisions by each module in time and the lack of directional constraints mean that the optimization effect of any single module can be offset by the lagging or conflicting responses of other modules.

[0005] Furthermore, existing solutions lack mechanisms for evaluating effectiveness and providing feedback for correction after adjustments are implemented. If cache expansion or scheduling adjustments fail to reduce packet loss, the system cannot automatically identify the adjustment failure and switch to a stronger response strategy, relying solely on operations personnel to manually reconfigure parameters. In scenarios where micro-bursts last only milliseconds, the response speed of manual intervention cannot match the changing rhythm of congestion events, causing packet loss to continue to occur across multiple adjustment cycles. Summary of the Invention

[0006] To address the problem of collaborative failure caused by the independent operation of each congestion control module and the lack of unified criteria in existing network splitters, this application provides a congestion control method and splitter system for lossless networks.

[0007] Firstly, this application provides a congestion control method for lossless networks, employing the following technical solution: A congestion control method for lossless networks, applied to a network splitter with multiple input ports and multiple output ports, includes the following steps: S1. Collect the queue depth of each output port; S2. Compare the queue depth with the congestion threshold to determine the congestion status of each output port; the congestion status includes multiple congestion levels arranged from low to high according to the severity of congestion, and each congestion level corresponds to a set of predefined linkage response parameters, the linkage response parameter set includes cache depth configuration parameters, traffic scheduling priority weight and traffic splitting weight; S3. Based on the current congestion level, obtain the corresponding cache depth configuration parameters and traffic splitting weights from the linkage response parameter set; the cache depth configuration parameters and the traffic splitting weights are jointly generated based on the same queue depth vector within the same decision period, and the cache depth configuration parameters and the traffic splitting weights are inversely correlated for the same output port; S4. Adjust the cache depth of the corresponding output port according to the cache depth configuration parameters in the linkage response parameter set, and adjust the scheduling priority of each output port according to the traffic scheduling priority weight in the linkage response parameter set. S5. Based on the traffic distribution weights in the linkage response parameter set, the traffic to be forwarded is distributed to each output port for output; S6. Within the evaluation window after the adjustment actions of S4 and S5 are executed, the change in packet loss rate is statistically analyzed; in response to the change in packet loss rate indicating that the adjustment action is invalid, the congestion state is upgraded to a higher congestion level and S3 to S5 are re-executed.

[0008] By adopting the above technical solution, cache depth configuration parameters, traffic scheduling priority weights, and traffic splitting weights are bound to a set of linked response parameters under the same congestion level. Within the same decision-making cycle, cache depth configuration parameters and traffic splitting weights are jointly generated based on the same queue depth vector. This allows congested ports to obtain larger cache capacity while receiving lower traffic splitting weights, with the two being inversely correlated for the same port. This inverse correlation structurally eliminates the positive feedback oscillations in decentralized independent decision-making, because ports with deeper caches have lower traffic splitting weights within the same decision-making cycle, and subsequent traffic is automatically guided to ports with less cache pressure. The change in packet loss rate is statistically analyzed within the evaluation window after the adjustment action. If the adjustment is ineffective, the congestion state is automatically upgraded to a higher level and the joint generation is re-executed. This allows the system to progressively strengthen the response without manual intervention when a single adjustment fails, forming a complete closed loop from congestion detection to joint decision-making, effect evaluation, and level correction. Compared to open-loop static configuration schemes, the closed-loop structure allows the adjustment strategy to automatically evolve based on actual packet loss improvement, avoiding the problem of inconsistent performance of the same set of static parameters under different traffic patterns.

[0009] Optionally, in S2, the lowest level among the plurality of congestion levels is the normal state; An upgrade threshold and a downgrade threshold are configured for each congestion level, wherein the upgrade threshold is higher than the downgrade threshold, forming a hysteresis interval; In response to a single sample value of the queue depth exceeding the upgrade threshold corresponding to the current congestion level, the congestion state is upgraded to the corresponding higher congestion level; In response to the queue depth being lower than the downgrade threshold corresponding to the current congestion level for M consecutive sampling periods, the congestion state is downgraded to the corresponding lower congestion level.

[0010] By adopting the above technical solution, the lowest level among multiple congestion levels is defined as the normal state, and upgrade and downgrade thresholds are configured for each level. An upgrade threshold higher than the downgrade threshold forms a hysteresis interval, preventing frequent switching of congestion levels due to minor fluctuations in queue depth near the threshold. Upgrade determination uses a single-sample value comparison, enabling the system to complete the level jump within a single sampling period when a micro-burst occurs. Downgrade determination requires the level to be below the downgrade threshold for M consecutive sampling periods, preventing premature regression to a lower level due to instantaneous queue emptying. This asymmetric response strategy of fast upgrade and slow downgrade matches the temporal characteristics of network micro-bursts, i.e., the rate of traffic arrival is much faster than the rate of queue emptying.

[0011] Optionally, in S4, the buffer for each output port includes a shallow buffer and a deep buffer; In response to the congestion state being in the normal state, the deep cache is in the off state, and the traffic to be forwarded is forwarded only through the shallow cache; In response to the congestion state escalating to a congestion level higher than the normal state, the open capacity of the deep cache is set to a preset capacity value corresponding to the current congestion level, and the open capacity increases progressively as the congestion level increases.

[0012] By adopting the above technical solution, the cache of each output port is divided into two levels: shallow cache and deep cache. Under normal conditions, the deep cache is closed, and all packets are forwarded only through the shallow cache path. This ensures that the queuing latency of each packet is determined by the fixed capacity of the shallow cache, making the latency predictable and constant. When congestion escalates, the open capacity of the deep cache increases incrementally with the congestion level rather than being fully opened all at once, matching the consumption of cache resources with the actual severity of congestion. For minor bursts that can be absorbed with only a small amount of additional cache, the system only opens a portion of the deep cache capacity, avoiding the increase in queuing latency and waste of on-chip storage resources caused by full opening.

[0013] Optionally, in S5: In response to the congestion level reaching a preset activation level, the traffic splitting weight is inversely proportional to the queue depth of the corresponding output port, and the traffic to be forwarded is weighted and distributed to each output port according to the traffic splitting weight; In response to the congestion state being in the normal state, the traffic to be forwarded is distributed to each output port according to the polling strategy.

[0014] By adopting the above technical solution, the traffic splitting weight is switched to a weighted allocation mode inversely proportional to the queue depth only when the congestion level reaches the preset activation level; under normal conditions, the polling strategy is maintained. This conditional triggering mechanism allows the system to operate with minimal computational overhead and minimal risk of out-of-order packets when there is no congestion, and only activates the weighted traffic splitting logic, which requires reading the queue depth of all ports and calculating weights, after congestion occurs. The inverse mapping relationship between the traffic splitting weight and the queue depth causes traffic to naturally shift from high-load ports to low-load ports, which is opposite to and works in conjunction with the cache depth configuration parameter in S3, further strengthening the directional consistency of the parameters within the linkage response parameter set.

[0015] Optionally, step S5 further includes the following sub-steps: S51. Establish flow tables at each output port and perform flow segmentation and statistics on the traffic passing through each output port according to the five-tuple hash. S52. In response to the instantaneous rate of a single stream exceeding a preset proportion of the bandwidth of the corresponding output port, the single stream is marked as an image stream; S53. Migrate the image stream to the output port with the highest splitting weight.

[0016] By adopting the above technical solution, flow tables are established at each output port, and flow distribution statistics are performed according to five-tuple hashing. When the instantaneous rate of a single flow exceeds a preset proportion of the bandwidth of the corresponding port, it is marked as a pixel flow and migrated to the port with the highest flow weight. In network traffic, a few pixel flows often occupy most of the bandwidth. The weighted flow distribution strategy balances the total traffic volume at the port level but cannot perceive the rate distribution of individual flows, which may result in multiple pixel flows being concentrated on the same port. By identifying and migrating pixel flows, the traffic between ports is not only balanced in terms of total volume but also achieves load distribution at the individual flow granularity, reducing the situation where a single high-volume flow monopolizes the port bandwidth, leading to increased queuing delays for other flows on the same port.

[0017] Optionally, the following steps may also be included: S7. In response to the congestion state reaching the highest congestion level and the open capacity of the deep cache reaching the maximum configuration value, a backpressure signal is sent to the upstream device to notify the upstream device to suspend sending data to the corresponding output port; In S7, the backpressure signal has a duration limit; in response to the duration of the backpressure signal reaching the duration limit, the backpressure signal is released, and the traffic splitting strategy is switched to selectively discard low-priority traffic according to the traffic scheduling priority weight.

[0018] By adopting the above technical solution, when the congestion level reaches its highest level and the deep cache open capacity has reached its maximum configuration value, a backpressure signal is sent to the upstream device to suspend data transmission. After exhausting the internal adjustment methods of the splitter, external flow control is introduced as a fallback. The backpressure signal has a time limit, and after the timeout, the backpressure is automatically released and the system switches to selectively discarding low-priority traffic according to the traffic scheduling priority weight. That is, it smoothly degrades from lossless mode to lossy high-priority preservation mode. This timeout degradation path prevents the risk of upstream cascading congestion caused by the backpressure signal blocking the upstream device for a long time, while still ensuring the transmission continuity of high-priority traffic after degradation.

[0019] Optionally, in step S1, a queue depth comparator is configured in the switching chip. When the queue depth of any output port crosses the congestion threshold, a congestion event interrupt is generated through the queue depth comparator, triggering the execution of step S2.

[0020] By adopting the above technical solution, a queue depth comparator is configured in the switching chip. When the queue depth crosses the congestion threshold, a congestion event interrupt is generated by hardware to trigger subsequent congestion determination. Compared with the software periodic polling method, the hardware interrupt does not occupy the management plane's computing resources and bus bandwidth when there is no congestion. It only generates an interrupt signal at the moment when the queue depth actually crosses the threshold, shortening the response delay of congestion detection from the polling interval to the interrupt response time.

[0021] Optionally, in S1, the queue depth is periodically collected at low-frequency sampling intervals; In response to the monotonically increasing sampled value of the queue depth over P consecutive sampling periods, the sampling interval is switched from the low-frequency sampling interval to the high-frequency sampling interval, wherein the span between the low-frequency sampling interval and the high-frequency sampling interval is at least two orders of magnitude. In response to the fact that the sampled value of the queue depth is lower than the congestion threshold for Q consecutive sampling periods under the high-frequency sampling interval, the sampling interval is restored to the low-frequency sampling interval.

[0022] By employing the above technical solution, queue depth is periodically collected at low-frequency sampling intervals. When a monotonically increasing sample value is detected over P consecutive sampling periods, the sampling interval is switched to high-frequency, with a span of at least two orders of magnitude between low and high frequencies. The low-frequency sampling interval covers congestion-free periods to reduce monitoring overhead, while the high-frequency sampling interval is activated upon detecting an increasing trend to match the microsecond to millisecond timescale of micro-bursts. The monotonically increasing trend serves as a trigger condition, utilizing the physical characteristics of micro-bursts—that is, when a micro-burst arrives, the queue depth increases in a step-like or continuous manner, unlike the random fluctuations during normal operation, thus reducing the probability of false triggering compared to schemes based on a single threshold. In high-frequency sampling mode, after Q consecutive periods of sample values ​​are below the congestion threshold, the frequency is restored to low frequency, avoiding the long-term continuous consumption of high-frequency sampling.

[0023] Optionally, in S6, in response to the change in packet loss rate indicating that the adjustment action has been effective for K consecutive times, the upgrade threshold is lowered and the downgrade threshold is raised to narrow the hysteresis interval.

[0024] By adopting the above technical solution, when the change in packet loss rate indicates that K consecutive adjustment actions are effective, the upgrade threshold is lowered and the downgrade threshold is raised to narrow the hysteresis range. Continuous effectiveness means that the current traffic pattern has stabilized and the congestion control strategy is fully covered. At this point, tightening the thresholds allows the system to trigger an upgrade response at a lower queue depth, while allowing downgrade rollback only at a higher queue depth, shifting towards a more conservative approach overall. This self-correcting mechanism allows the threshold parameters to automatically tend towards the optimal range matching the current traffic pattern over time, reducing premature or delayed responses caused by improper initial threshold settings.

[0025] Optionally, the timestamp, duration, involved output port number, and peak queue depth of each congestion state upgrade event are recorded to form a congestion event history record; periodic traffic burst patterns are extracted based on the congestion event history record; in response to the current moment, a prediction window matching the extracted periodic traffic burst patterns is entered, and before the micro-burst arrives, the cache depth configuration parameter is pre-expanded from the value corresponding to the current congestion level to the value corresponding to a higher congestion level, and the traffic scheduling priority weight corresponding to the higher congestion level is preloaded.

[0026] By adopting the above technical solution, historical data on congestion escalation events are recorded and periodic traffic burst patterns are extracted. Before the prediction window arrives, cache depth configuration parameters are expanded in advance, and higher-level traffic scheduling priority weights are preloaded. For network scenarios with periodic business peaks, pre-allocation ensures that caching and scheduling strategies are in place before the actual arrival of micro-bursts, eliminating the response delay from congestion detection to joint decision-making and parameter activation.

[0027] Optionally, after the prediction window ends, if no congestion state upgrade event occurs within the prediction window, the cache depth configuration parameters and traffic scheduling priority weights are restored to their original values ​​in the linkage response parameter set corresponding to the current congestion level.

[0028] By adopting the above technical solution, if no congestion escalation event occurs within the prediction window after its end, the cache depth configuration parameters and traffic scheduling priority weights are restored to their original values ​​in the linkage response parameter set corresponding to the current congestion level. This restoration mechanism prevents long-term excessive resource occupation caused by inaccurate predictions, ensuring that the pre-allocated additional cache and scheduling weights are only temporarily effective within the prediction window, and the system automatically returns to its normal configuration state outside the window.

[0029] Secondly, this application provides a congestion control splitter system for lossless networks, which adopts the following technical solution: A traffic divider system for congestion control in lossless networks, comprising: The queue depth monitoring module is configured to collect the queue depth of each output port; The congestion determination module is configured to compare the queue depth with the congestion threshold to determine the congestion status of each output port. The congestion status includes multiple congestion levels arranged from low to high congestion severity. Each congestion level corresponds to a set of predefined linkage response parameters, which include cache depth configuration parameters, traffic scheduling priority weights, and traffic splitting weights. The joint decision-making module is configured to obtain the corresponding cache depth configuration parameters and traffic splitting weights from the linkage response parameter set according to the current congestion level. The cache depth configuration parameters and the traffic splitting weights are jointly generated based on the same queue depth vector within the same decision period. The cache depth configuration parameters and the traffic splitting weights are inversely correlated with the same output port. A cache configuration module is configured to adjust the cache depth of the corresponding output port according to the cache depth configuration parameter; A priority scheduling module is configured to adjust the scheduling priority of each output port according to the traffic scheduling priority weight; The traffic splitting module is configured to distribute the traffic to be forwarded to each output port for output according to the traffic splitting weight; The effect evaluation module is configured to count the change in packet loss rate within the evaluation window after the adjustment actions of the cache configuration module and the traffic splitting module are executed. In response to the change in packet loss rate indicating that the adjustment action is invalid, the congestion state is upgraded to a higher congestion level and the joint decision module is triggered to re-execute the joint generation. The cache configuration module, the priority scheduling module and the traffic splitting module perform corresponding adjustments according to the regenerated linkage response parameter set.

[0030] In summary, this application includes at least one of the following beneficial technical effects: 1. The cache depth configuration parameters and traffic distribution weights are jointly generated based on the same queue depth vector within the same decision cycle, and the two are inversely correlated with the same output port. This allows congested ports to obtain a larger cache capacity while obtaining a lower traffic distribution weight, structurally eliminating the positive feedback oscillations caused by independent decision-making between cache management and traffic distribution.

[0031] 2. Within the evaluation window after the adjustment action is executed, the change in packet loss rate is statistically analyzed. If the adjustment is ineffective, the congestion status is automatically upgraded to a higher level and joint generation is re-executed, forming a complete closed loop from congestion detection to joint decision-making to effect evaluation and level correction. This allows the system to gradually strengthen its response without manual intervention when a single adjustment fails to reduce the packet loss rate.

[0032] 3. Each congestion level corresponds to a set of predefined linkage response parameters. The cache depth configuration parameters, traffic scheduling priority weight, and traffic splitting weight are obtained from the same parameter set, so that the three adjustment dimensions switch synchronously when the congestion level jumps, avoiding scheduling direction conflicts caused by asynchronous responses of various modules. Attached Figure Description

[0033] Figure 1 This is a flowchart of a congestion control method for lossless networks according to an embodiment of the present invention.

[0034] Figure 2 This is a schematic diagram illustrating the correspondence between congestion levels and linkage response parameter sets in one embodiment of the present invention.

[0035] Figure 3 This is a schematic diagram of joint decision-making and reverse correlation in one embodiment of the present invention.

[0036] Figure 4 This is a block diagram of a congestion control splitter system for lossless networks according to an embodiment of the present invention. Detailed Implementation

[0037] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0038] This application provides a congestion control method and a diverter system for lossless networks. (Refer to...) Figure 1 This method, comprising S1-S6, binds three adjustment mechanisms—cache depth configuration, traffic scheduling priority adjustment, and traffic splitting weight allocation—into a set of linked response parameters under the same congestion level. Within the same decision cycle, cache depth configuration parameters and traffic splitting weights are jointly generated based on the same queue depth vector, making them inversely correlated with the same output port. After the adjustment is executed, closed-loop control is formed through packet loss rate assessment and automatic escalation of congestion level. Each step is described in detail below.

[0039] A network packet broker is a traffic distribution device deployed at a network aggregation node. It connects to multiple input ports on one end to receive traffic from network mirroring ports or splitters, and to multiple output ports on the other end to distribute the aggregated traffic to downstream tools such as security auditing devices, intrusion detection systems, or traffic analysis platforms. A high convergence ratio forwarding architecture is formed when the total bandwidth of the input ports is higher than the total bandwidth of the output ports. The convergence ratio is defined as the ratio of the total bandwidth of the input ports to the total bandwidth of the output ports.

[0040] Lossless networking refers to a network architecture that requires zero packet loss during data transmission. In security auditing and compliance testing scenarios, the loss of any packet can lead to incomplete audit logs or the omission of threat events. Therefore, the output side of the traffic splitter needs to produce no packet loss under any traffic mode.

[0041] Microbursts refer to transient traffic peaks lasting from microseconds to milliseconds. Microbursts are characterized by an average rate, measured in seconds, that is far below the port's rated bandwidth, but an instantaneous rate within a microsecond time window that can reach or exceed the port's bandwidth, causing the output port's forwarding queue to accumulate rapidly in a short period.

[0042] In this embodiment, a traffic splitter with 10 10GE input ports and 4 10GE output ports is used as an example. The convergence ratio of this traffic splitter is 100Gbps / 40Gbps, or 2.5:1, and it carries mirrored traffic in a network security audit scenario, requiring zero packet loss. First, it is necessary to collect the queue depth of each output port to perceive the current congestion status.

[0043] S1. Collect the queue depth of each output port.

[0044] Queue depth refers to the number of packets currently waiting to be forwarded in the output port's transmit queue. The switching chip maintains one or more transmit queues at each output port. Incoming packets, after being looked up and classified, enter the corresponding output port's transmit queue to wait for forwarding. The number of packets currently in the queue is the queue depth. A larger queue depth indicates higher forwarding pressure on the port and a greater risk of packet loss.

[0045] Taking four output ports as an example, the queue depths collected at a certain moment were as follows: Port 1 had 1200 packets, Port 2 had 300 packets, Port 3 had 4500 packets, and Port 4 had 800 packets. The queue depth of Port 3 was much higher than that of the other ports, indicating that Port 3 was experiencing traffic accumulation.

[0046] There are two implementation paths for queue depth acquisition: one is event-driven acquisition driven by hardware interrupts, and the other is periodic acquisition driven by software polling. These two paths are suitable for different switching chip hardware capabilities, and will be explained below.

[0047] In switching chips that support hardware interrupts, a queue depth comparator can be configured internally for each output port. The queue depth comparator continuously monitors the queue depth value of the corresponding port and compares it with a pre-written congestion threshold. When the queue depth value jumps from below the congestion threshold to above it, the comparator generates a congestion event interrupt signal to the central processing unit (CPU) on the management plane. Upon receiving the interrupt signal, the CPU reads the port number that generated the interrupt and the current queue depth value, triggering the execution of S2.

[0048] Continuing with the 4-port scenario described above, a congestion threshold of 2000 packets is set. The queue depth for port 3 is 4500 packets, exceeding the congestion threshold, causing the queue depth comparator to interrupt. The 1200 packets for port 1, 300 packets for port 2, and 800 packets for port 4 are all below the 2000-packet threshold, so the comparator does not interrupt. During periods when ports 1, 2, and 4 are not congested, the comparator remains silent, not consuming management plane computing resources or bus bandwidth, and only generates an interrupt signal the instant the queue depth actually crosses the threshold.

[0049] In switching chips that do not support hardware interrupts, a software polling method is used to collect queue depth, and an adaptive sampling frequency adjustment mechanism is used to reduce monitoring overhead.

[0050] Initially, the queue depth of each output port is periodically acquired at low-frequency sampling intervals. The low-frequency sampling interval is set to 1 second, and the high-frequency sampling interval is set to 1 millisecond, with a span of three orders of magnitude between them. The number of consecutive incrementing cycles P that triggers high-frequency switching is set to 3, and the number of consecutive cycles Q below the threshold that restores low frequency is set to 5.

[0051] Taking port 3 as an example, the adaptive handover process is illustrated. In low-frequency sampling mode, the queue depth collected in the first second is 800 packets, in the second second it is 1200 packets, and in the third second it is 1600 packets. The queue depth sample value monotonically increases over three consecutive sampling periods, satisfying the trigger condition P=3, and the sampling interval is switched from 1 second to 1 millisecond. After switching to high-frequency sampling, the queue depth of port 3 is continuously collected at 1 millisecond intervals, enabling subsequent congestion determination to track the evolution of micro-burst events with millisecond-level time resolution.

[0052] Monotonically increasing as the trigger condition utilizes the physical characteristics of micro-bursts. When a micro-burst occurs, multiple input flows simultaneously into the same output port, causing the queue depth to increase in a step-like or continuous manner. Random fluctuations during normal operation manifest as the queue depth fluctuating between sampling intervals rather than continuously increasing unidirectionally. For example, if the sampled values ​​in three sampling periods are 800, 1200, and 1100, and the third value is lower than the second, the monotonically increasing condition is not met, and high-frequency switching is not triggered, thus avoiding erroneous responses to random fluctuations.

[0053] In high-frequency sampling mode, if the queue depth sample value is lower than the congestion threshold of 2000 packets for five consecutive millisecond-level sampling periods, the sampling interval is restored to 1 second, and the high-frequency mode is exited. In low-frequency mode, sampling is performed once per second, and in high-frequency mode, sampling is performed 1000 times per second. The adaptive strategy limits high-frequency sampling to a short window before and after micro-bursts, avoiding long-term continuous consumption of high-frequency sampling.

[0054] S2. Compare the queue depth with the congestion threshold to determine the congestion status of each output port.

[0055] The congestion state includes multiple congestion levels arranged from low to high according to the severity of congestion. Taking 4 congestion levels as an example, they are defined as follows: Level 0 is the normal state, corresponding to the scenario where the queue depth is less than 2000 packets; Level 1 is the warning state, corresponding to the scenario where the queue depth is between 2000 and 4000 packets; Level 2 is the mild congestion state, corresponding to the scenario where the queue depth is between 4000 and 6000 packets; Level 3 is the severe congestion state, corresponding to the scenario where the queue depth exceeds 6000 packets.

[0056] Each congestion level corresponds to a set of predefined linkage response parameter sets. The linkage response parameter set includes three parameter dimensions: cache depth configuration parameter, traffic scheduling priority weight, and traffic splitting weight. As Figure 2 shown, the comparison table of the linkage response parameter sets for 4 levels is as follows.

[0057] Under Level 0, the cache depth configuration parameter is the default value of 512KB, the traffic scheduling priority weight is equal for each port, and the traffic splitting weight is equal for each port, that is, the polling mode. Under Level 1, the cache depth configuration parameter is extended to 1.5MB, the weight of high-priority traffic in the traffic scheduling priority weight is increased to 2 times that of low-priority traffic, and the traffic splitting weight is calculated inversely proportional to the queue depth. Under Level 2, the cache depth configuration parameter is extended to 3MB, the high-priority weight is increased to 4 times that of low-priority, and the traffic splitting weight is still calculated inversely proportional to the queue depth. Under Level 3, the cache depth configuration parameter is extended to the maximum value of 4.5MB, the high-priority weight is increased to 8 times that of low-priority, and the traffic splitting weight is calculated inversely proportional to the queue depth.

[0058] The output of S2 is the congestion level of each current output port. This congestion level is used as an index for S3 to retrieve the corresponding triple parameter group from the linkage response parameter set.

[0059] In some embodiments, to further refine the jump mechanism of the congestion level, an upgrade threshold and a downgrade threshold are respectively configured for each congestion level. The upgrade threshold is higher than the downgrade threshold, and the difference between the two forms a hysteresis interval. The lowest level Level 0 in multiple congestion levels is the normal state.

[0060] Taking the aforementioned four-level system as an example, the upgrade and downgrade thresholds for each level are set as follows: The upgrade threshold from Level 0 to Level 1 is 2000 packets; the downgrade threshold from Level 1 back to Level 0 is 1500 packets, with a hysteresis interval of 500 packets. The upgrade threshold from Level 1 to Level 2 is 4000 packets; the downgrade threshold from Level 2 back to Level 1 is 3200 packets, with a hysteresis interval of 800 packets. The upgrade threshold from Level 2 to Level 3 is 6000 packets; the downgrade threshold from Level 3 back to Level 2 is 5000 packets, with a hysteresis interval of 1000 packets.

[0061] Upgrade determination is based on a single sample value comparison. If a single sample value of the queue depth exceeds the upgrade threshold corresponding to the current congestion level, the congestion state is immediately upgraded to the corresponding higher congestion level. For example, if the current level is Level 0 and a sampled queue depth of 2100 packets exceeds the upgrade threshold of 2000 packets from Level 0 to Level 1, the congestion state will upgrade to Level 1 within the current sampling period. This single-sample-triggered upgrade allows the system to complete the level transition within one sampling period when micro-bursts occur.

[0062] Degradation determination uses continuous multi-cycle confirmation. The number of sampling cycles M for continuous confirmation is set to 5. The congestion state is downgraded to the corresponding lower congestion level only if the queue depth is lower than the degradation threshold corresponding to the current congestion level for 5 consecutive sampling cycles. For example, if the current level is Level 1 and the degradation threshold is 1500 packets, and the queue depths for 5 consecutive sampling cycles are 1400, 1300, 1450, 1200, and 1350 respectively (all 5 values ​​are below 1500), then the congestion state is downgraded to Level 0. If the values ​​for 5 sampling cycles are 1400, 1300, 1600, 1200, and 1350, and the third value of 1600 exceeds the degradation threshold of 1500, the condition of continuously being below this threshold is not met, the counter is reset to zero, and the congestion state remains at Level 1.

[0063] The asymmetric design, characterized by rapid upgrades and slow downgrades, is well-suited to the time-dependent nature of network micro-bursts. When a micro-burst occurs, multiple input traffic streams surge simultaneously within a microsecond time window, causing the queue depth to rapidly increase. Upgrades must be completed within a single sampling period to initiate a stronger response strategy. After the micro-burst subsides, the queue depth is emptied slowly due to limitations in output port bandwidth. If downgrades also rely on single-sampling decisions, brief fluctuations in queue depth during emptying could cause congestion levels to repeatedly switch between levels, leading to frequent switching of the linked response parameter set, which in turn increases scheduling overhead and the risk of out-of-order packets. The M-period acknowledgment requirement provides a time buffer for downgrades, ensuring that downgrades are only executed after the queue depth has indeed stabilized and fallen back to normal.

[0064] S3. Based on the current congestion level, obtain the corresponding cache depth configuration parameters and traffic splitting weight from the linkage response parameter set.

[0065] The queue depth vector is a one-dimensional array consisting of the queue depth values ​​of all output ports. Taking four output ports as an example, the queue depth vector collected at a certain moment is [1200, 300, 4500, 800], corresponding to the queue depths of ports 1 to 4, respectively. The decision period refers to the complete time window from reading the queue depth vector to outputting the buffer depth configuration parameters and traffic splitting weights in a single joint generation process. Within the same decision period, the buffer depth configuration parameters and traffic splitting weights are calculated based on the same queue depth vector, and the input data used in the two calculations is consistent, eliminating data deviations caused by different sampling times.

[0066] like Figure 3 As shown, the cache depth configuration parameter and the traffic splitting weight are inversely related for the same output port. Taking the current congestion level as Level 2 as an example, the joint generation process is as follows: Port 3 has a queue depth of 4500 packets, the highest among the four ports. Its cache depth configuration parameter is set to the maximum value of 3MB in the Level 2 linkage response parameter set, while its traffic splitting weight is set to the lowest value among the four ports. Port 2 has a queue depth of 300 packets, the lowest among the four ports. Its cache depth configuration parameter is set to the minimum value in the Level 2 linkage response parameter set, while its traffic splitting weight is set to the highest value among the four ports. The cache depth configuration parameters and traffic splitting weights of ports 1 and 4 are determined by interpolation between ports 2 and 3 according to their respective queue depths.

[0067] The mechanism of reverse correlation is as follows: After a congested port obtains a larger cache depth configuration parameter, its sending queue can accommodate more packets without triggering drop, providing buffer space for packets already in the queue. Within the same decision cycle, the traffic splitting weight of this port is synchronously reduced, and new packets arriving at the traffic splitting module are allocated to this port with a lower weight, with most new traffic being guided to ports with lower queue depths. The two directions of cache expansion absorbing existing backlog and traffic splitting weight reduction reducing new traffic take effect synchronously within the same decision cycle, causing the queue depth of the congested port to tend to decrease under the dual effects of buffering and traffic reduction, avoiding the situation where the expanded cache is quickly filled due to a continuous influx of new traffic after cache expansion.

[0068] S4. Adjust the cache depth of the corresponding output port according to the cache depth configuration parameters in the linkage response parameter set, and adjust the scheduling priority of each output port according to the traffic scheduling priority weight in the linkage response parameter set.

[0069] The cache depth configuration parameters take effect by being written to the QoS queue configuration register of the switching chip. Each output port corresponds to a set of register addresses, and the value stored in the register determines the maximum cache capacity of the port's transmit queue. After the joint decision module writes the cache depth configuration parameters generated by S3 into the register of the corresponding port, the switching chip begins to use the new cache capacity limit in the next forwarding cycle.

[0070] Traffic scheduling priority weights take effect by being written to the scheduler's weight register. The scheduler allocates egress bandwidth to queues of different priorities according to the weight values. Continuing with the Level 2 scenario above, the scheduling weight of high-priority traffic on port 3 is set to 4 times that of low-priority traffic. This ensures that when there is severe queue congestion on port 3, high-priority packets receive 4 times the egress bandwidth share of low-priority packets and are forwarded with priority.

[0071] In some embodiments, the cache for each output port is further divided into two levels: a shallow cache and a deep cache. The shallow cache corresponds to the on-chip high-speed static memory inside the switching chip, with low access latency but limited capacity. The deep cache corresponds to the external extended dynamic memory, with larger capacity but higher access latency than the shallow cache. An example is given with a shallow cache capacity of 512KB per port and a total deep cache capacity of 4MB.

[0072] In response to a normal congestion state (Level 0), the deep buffer is disabled and does not participate in queuing. All packets awaiting forwarding enter the 512KB space of the shallow buffer and wait for forwarding. Since the shallow buffer has a fixed and small capacity, the queuing time from when a packet enters the queue to when it is scheduled for forwarding is determined by the 512KB capacity limit, resulting in constant and predictable latency.

[0073] In response to congestion escalating to a level higher than normal, the deep cache gradually releases a portion of its capacity according to the congestion level. At Level 1, the deep cache releases 1MB, totaling 1.5MB when combined with the 512KB shallow cache, corresponding to the cache depth configuration parameters for Level 1 in the linkage response parameter set. At Level 2, the deep cache releases 2.5MB, totaling 3MB. At Level 3, the deep cache releases its full capacity of 4MB, totaling 4.5MB. The released capacity increases progressively with the congestion level, ensuring that cache resource consumption matches the actual severity of congestion. For minor bursts that can be absorbed with only a small amount of additional caching, the system releases only an additional 1MB of deep cache at Level 1, avoiding the increased queuing latency and wasted off-chip storage resources that would result from releasing the entire 4MB at once.

[0074] In real-world network operation and maintenance scenarios, some network environments experience periodic traffic spikes. For example, a security audit network experiences a surge in traffic between 09:00 and 09:15 every workday due to concentrated employee logins, causing the traffic splitter to frequently enter Level 1 or Level 2 congestion during this period. In some embodiments, the system records the timestamp, duration, involved output port number, and peak queue depth of each congestion escalation event, forming a congestion event history record. After accumulating data over multiple workdays, the system extracts the periodic traffic burst pattern of "Level 1 or higher congestion occurring between 09:00 and 09:15 every workday" from the congestion event history record.

[0075] In response to entering a prediction window that matches the extracted periodic traffic burst pattern at the current time, for example, if the current time is 08:58 and there are still 2 minutes until the prediction window starts at 09:00, the system pre-expands the cache depth configuration parameter from 512KB corresponding to Level 0 to 1.5MB corresponding to Level 1 before the micro-burst arrives. It also preloads the traffic scheduling priority weight from equal weight in Level 0 to twice the weight of the high priority in Level 1. When the traffic surge at 09:00 actually arrives, the caching and scheduling policies are already in place, eliminating the response delay from congestion detection to joint decision-making and parameter activation.

[0076] If no congestion escalation event occurs within the prediction window after the prediction window ends, it indicates that the prediction does not match the actual traffic pattern. The system will restore the cache depth configuration parameters and traffic scheduling priority weights to their original values ​​in the linkage response parameter set corresponding to the current congestion level, and release the pre-allocated additional cache resources.

[0077] S5. Based on the traffic distribution weights in the linkage response parameter set, the traffic to be forwarded is allocated to each output port for output.

[0078] Continuing from the jointly generated traffic splitting weights in Level 2 scenario S3, port 2 has the highest splitting weight, port 3 has the lowest, and ports 1 and 4 have intermediate splitting weights. The traffic splitting process is illustrated using a weighted round-robin algorithm as an example. Using the queue depth values ​​[1200, 300, 4500, 800] collected in S1, calculated using inverse normalization, the splitting weights for the four ports are: port 1 15%, port 2 59%, port 3 4%, and port 4 22%. When 100 packets to be forwarded arrive at the traffic splitting module, after weight allocation, port 1 receives 15 packets, port 2 receives 59 packets, port 3 receives 4 packets, and port 4 receives 22 packets. Port 3, with the highest queue depth, receives only 4% of the new traffic. This aligns with the adjustment direction of the maximum cache depth configuration parameter for port 3: cache expansion provides buffer space for packets already in the queue, while the reduced traffic splitting weight decreases the number of new packets that subsequently flood in. Together, these two factors cause the queue depth of port 3 to tend to decrease.

[0079] The implementation of traffic splitting weights on the data plane is as follows: When each packet to be forwarded arrives at the traffic splitting module, the module reads the current traffic splitting weight values ​​of each port and selects the target output port for this forwarding according to a weighted round-robin algorithm. The weighted round-robin algorithm maintains a loop counter and the remaining weight quota of each port. Each time a packet is allocated, the remaining quota of the target port is decremented by one. When the remaining quota of a port reaches zero, that port is skipped. This process continues until the quotas of all ports reach zero, at which point the weight values ​​are reloaded and the next round of looping begins.

[0080] In some embodiments, the calculation mode of traffic splitting weights is dynamically switched according to the congestion level. In response to the congestion level reaching a preset activation level, the traffic splitting weights are switched to a weighted allocation mode inversely proportional to the queue depth of the corresponding output port. In response to the congestion state being normal, the traffic to be forwarded is evenly distributed to each output port according to a round-robin strategy.

[0081] The default activation level is set to Level 1. When the congestion state is at Level 0 (normal state), each of the four output ports is allocated 25% of the traffic. The traffic distribution module distributes packets to ports 1, 2, 3, and 4 in a fixed order. The polling strategy does not require reading the queue depth vector or calculating weights. The traffic distribution decision for each packet only involves one counter increment and modulo operation, resulting in minimal computational overhead. Furthermore, the order in which packets arrive at each port is consistent with the input order, without introducing additional out-of-order risks.

[0082] When the congestion level escalates to Level 1 or higher, the traffic distribution weight switches to an inverse queue depth mode. Continuing from the queue depth values ​​of 1200, 300, 4500, and 800 collected in S1 for the four ports, the reciprocals of the queue depth for each port are 1 / 1200, 1 / 300, 1 / 4500, and 1 / 800, respectively. Normalizing these four reciprocals yields the traffic distribution weight percentage for each port. Port 2 has the lowest queue depth and the largest reciprocal, resulting in the highest traffic distribution weight; Port 3 has the highest queue depth and the smallest reciprocal, resulting in the lowest traffic distribution weight. This inverse mapping relationship naturally shifts traffic from high-load ports to low-load ports, working in conjunction with and opposite to the direction of the cache depth configuration parameter in S3.

[0083] The condition-triggered mechanism limits the computational overhead of weighted traffic allocation to the actual period when congestion occurs. During normal operation periods when network load is stable and the queue depths of all ports are well below the congestion threshold, the system operates using a round-robin strategy, without introducing additional overhead for weight calculation and queue depth reading. The weighted traffic allocation logic, which requires reading the queue depths of all ports and calculating inverse weights every decision cycle, is only activated when the congestion level reaches a preset activation level.

[0084] In some embodiments, S5 further includes sub-steps S51-S53 for identifying and processing single streams that occupy a large proportion of the port bandwidth.

[0085] S51. Establish flow tables on each output port and perform flow segmentation and statistics on the traffic passing through each output port according to the 5-tuple hash. The flow table is a hash table with 5-tuples as keys, where the 5-tuple includes the source IP address, destination IP address, source port number, destination port number, and protocol number. Each flow table record maintains the cumulative number of bytes for the flow in the most recent statistical window and the instantaneous rate obtained by dividing the cumulative number of bytes by the duration of the statistical window.

[0086] S52. In response to a single flow's instantaneous rate exceeding a preset proportion of the corresponding output port bandwidth, the single flow is marked as an image flow. An image flow refers to a single flow that occupies a large share of the output port bandwidth. Network traffic often exhibits an uneven distribution where a few flows occupy most of the bandwidth. Weighted traffic distribution strategies balance the total traffic at the port level, but they cannot detect the rate distribution of individual flows within a port. When multiple image flows are concentrated on the same port, the queue depth of that port may remain consistently high due to the superposition of these image flows.

[0087] The preset ratio is set to 30%, meaning that when the instantaneous rate of a single flow exceeds 30% of the 10GE port bandwidth, corresponding to 3Gbps, the flow is marked as an image flow. For example, if there is a flow on port 3 with a source IP address of 10.0.0.1, a destination IP address of 192.168.1.100, a source port number of 443, a destination port number of 52000, and a protocol number of 6, and the cumulative number of bytes in the statistics window is 500MB, the statistics window duration is 1 second, and the instantaneous rate is 4Gbps, exceeding the 3Gbps image flow threshold, then the flow is marked as an image flow.

[0088] S53. Migrate the image stream to the output port with the highest traffic splitting weight. Continuing from the above scenario, the port with the highest traffic splitting weight is currently port 2. Migrate the image stream from port 3 to port 2. The migration operation is achieved by adding an exact match entry for this 5-tuple in the forwarding rules of the traffic splitting module. Subsequent packets matching this 5-tuple are directly forwarded to port 2 and no longer enter the weighted round-robin general traffic splitting path.

[0089] After the migration was completed, port 3 offloaded 4Gbps of image stream load, and its queue depth decreased in subsequent decision cycles. After port 2 received the migration traffic, its queue depth increased, and its traffic allocation weight decreased accordingly in the next round of joint decision-making. The system automatically rebalanced through the reverse correlation of joint decision-making to avoid overloading the migration target port due to receiving image streams.

[0090] S6. Within the evaluation window following the execution of the adjustments in S4 and S5, calculate the change in packet loss rate.

[0091] The evaluation window is an observation period after the adjustment action takes effect, used to collect packet loss rate data before and after the adjustment to determine the adjustment effect. The evaluation window starts at the moment when the adjustment actions of S4 and S5 are written into the switching chip register and take effect. The window length is set according to the statistical stability of network traffic, for example, set to 10 sampling periods. The change in packet loss rate is defined as the difference between the packet loss rate counted within the evaluation window and the packet loss rate counted before the adjustment action takes effect. When the change in packet loss rate is greater than or equal to zero, that is, when the packet loss rate within the evaluation window is not lower than the packet loss rate before the adjustment, the adjustment action is considered invalid.

[0092] The closed-loop execution process is illustrated by the following scenario. At a certain moment, the congestion status of port 3 is upgraded from Level 0 to Level 1. The system executes S3 to jointly generate the cache depth configuration parameter and shunt weight corresponding to Level 1. S4 expands the cache depth of port 3 from 512KB to 1.5MB and adjusts the scheduling priority weight. S5 reduces the shunt weight of port 3. After the adjustment action takes effect, it enters the evaluation window. The packet loss rate statistically obtained within the window is 0.3%, and the packet loss rate before adjustment is 0.5%. The change in the packet loss rate is -0.2 percentage points, indicating that the adjustment action is effective. The system maintains the linkage response parameter set of Level 1 and continues to run.

[0093] During subsequent operation, a stronger microburst arrives. The queue depth of port 3 climbs again, and the linkage response parameter set of Level 1 takes effect again. The packet loss rate statistically obtained within the evaluation window is 0.5%, and the packet loss rate before adjustment is also 0.5%. The change in the packet loss rate is zero, determining that the adjustment action is ineffective. The system automatically upgrades the congestion status of port 3 from Level 1 to Level 2 and re-executes S3 to S5: obtains a larger cache depth configuration parameter of 3MB and a lower shunt weight from the linkage response parameter set of Level 2, writes them into the register, and then enters the evaluation window again to observe the effect.

[0094] When the congestion reaches the highest level of Level 3 and the adjustment action is still determined to be ineffective, the congestion status cannot be upgraded further, and the internal linkage response parameter set of the system has exhausted the adjustment space. At this time, external flow control needs to be introduced as a fallback measure, and the specific mechanism will be described in subsequent S7.

[0095] In some embodiments, in addition to upgrading the congestion level when the adjustment is ineffective, the closed-loop evaluation mechanism also automatically tightens the threshold parameters when the adjustment is continuously effective. The set number K of consecutive effective determinations is 3.

[0096] Following the upgrade threshold of 2000 packets and the downgrade threshold of 1500 packets from Level 0 to Level 1 in S2, the hysteresis interval is 500 packets. When the system is running at Level 1 and the change in the packet loss rate is negative after entering the evaluation window three consecutive times, that is, the adjustment action is effective three consecutive times, the system automatically reduces the upgrade threshold from Level 0 to Level 1 to 1800 packets, simultaneously increases the downgrade threshold to 1600 packets, and reduces the hysteresis interval from 500 packets to 200 packets.

[0097] The lowered upgrade threshold means the system triggers an upgrade from Level 0 to Level 1 when the port queue depth reaches 1800 packets, responding earlier than the previous 2000 packets. The increased downgrade threshold means the queue depth needs to fall below 1600 packets and remain below it for M cycles before downgrading from Level 1 back to Level 0, making it more difficult to downgrade than the previous 1500 packets. The overall direction is shifting towards a more conservative approach.

[0098] Continuous validity indicates that the current traffic pattern is fully covered by the Level 1 response parameter set, and the congestion control strategy is operating effectively. Tightening the threshold at this point makes the system more sensitive to congestion, initiating preventative responses at lower queue depths. This self-correcting mechanism allows the threshold parameters to automatically tend towards a range that matches the current traffic pattern over time, reducing response lag caused by mismatches between initial threshold settings and actual traffic characteristics.

[0099] In some embodiments, when the set of linkage response parameters inside the splitter has exhausted the adjustment space, external flow control is introduced as a fallback.

[0100] S7. In response to the congestion level reaching the highest level of 3 and the open capacity of the deep buffer reaching the maximum of 4MB, a backpressure signal is sent to the upstream device. The physical form of the backpressure signal is a priority-based flow control pause frame conforming to the IEEE 802.1Qbb standard, or a control message customized by the splitter. Upon receiving the backpressure signal, the upstream device suspends data transmission to the corresponding output port, allowing the queue depth of the congested port to gradually empty as no new traffic inflow occurs.

[0101] The backpressure signal has a duration limit to prevent upstream devices from being blocked for extended periods, which could lead to cascading congestion on the upstream side. The duration limit is set to 500 milliseconds. Within 500 milliseconds after the backpressure signal is issued, if the queue depth of port 3 has dropped below the Level 2 degradation threshold of 5000 packets for M sampling periods, the congestion state is downgraded from Level 3 to Level 2 through the S6 closed-loop mechanism. The system then actively withdraws the backpressure signal, and the upstream devices resume transmission.

[0102] In response to the backpressure signal duration reaching the 500ms upper limit while the queue depth on port 3 has not sufficiently decreased, the system automatically releases the backpressure signal, ceasing to block upstream devices. Simultaneously, the traffic distribution strategy is switched to selectively discarding low-priority traffic based on traffic scheduling priority weights. In selective discard mode, high-priority packets continue to be forwarded normally, while low-priority packets are discarded when the queue depth exceeds the set discard threshold. The system smoothly degrades from a lossless mode with zero packet loss to a lossy-priority-preserving mode that discards low-priority packets while ensuring the continuity of high-priority packet transmission.

[0103] Subsequently, as the external traffic pressure eases, the queue depth of port 3 gradually decreases. When the queue depth continuously drops below the degradation thresholds at all levels and meets the confirmation condition for M consecutive cycles, the congestion state gradually reverts to the normal state of Level 0 through the closed-loop mechanism of S2 and S6. The system automatically exits the selective discard mode, resumes the polling-based traffic splitting strategy, and re-enters the lossless operation state.

[0104] As Figure 4 shown, the embodiment of the present application also provides a congestion control splitter system for a lossless network.

[0105] The queue depth monitoring module is configured to collect the queue depths of each output port and transmit the collected queue depth values to the congestion determination module. The implementation of the queue depth monitoring module includes a hardware queue depth comparator configured in the switching chip or a software polling collection program running on the management plane processor.

[0106] The congestion determination module is configured to receive the queue depth values transmitted by the queue depth monitoring module, compare the queue depth values with the congestion thresholds, and determine the congestion states of each output port. The congestion states include multiple congestion levels arranged from low to high according to the severity of congestion. Each congestion level corresponds to a set of predefined linkage response parameter sets. The linkage response parameter sets include cache depth configuration parameters, traffic scheduling priority weights, and splitting weights. The congestion determination module outputs the determined congestion levels to the joint decision-making module.

[0107] The joint decision-making module is configured to obtain the corresponding cache depth configuration parameters and splitting weights from the linkage response parameter sets according to the current congestion level output by the congestion determination module. The cache depth configuration parameters and splitting weights are jointly generated based on the same queue depth vector within the same decision cycle. The cache depth configuration parameters and the splitting weights are inversely correlated for the same output port. The joint decision-making module outputs the generated cache depth configuration parameters to the cache configuration module, outputs the traffic scheduling priority weights to the priority scheduling module, and outputs the splitting weights to the splitting module.

[0108] The cache configuration module is configured to receive the cache depth configuration parameters output by the joint decision-making module, write the cache depth configuration parameters into the QoS queue configuration register of the corresponding output port, and adjust the cache depth of the corresponding output port.

[0109] The priority scheduling module is configured to receive the traffic scheduling priority weights output by the joint decision-making module, write the traffic scheduling priority weights into the weight register of the scheduler, and adjust the scheduling priorities of each output port.

[0110] The traffic splitting module is configured to receive the splitting weights output by the joint decision-making module, and distribute the traffic to be forwarded to each output port for output according to the splitting weights. The traffic splitting module implements the mapping of splitting weights to forwarding paths on the data plane using a weighted round-robin algorithm.

[0111] The effect evaluation module is configured to count the change in packet loss rate at each output port within the evaluation window following the adjustment actions of the cache configuration module and the traffic splitting module. If the change in packet loss rate indicates that the adjustment action was ineffective, the effect evaluation module sends a level upgrade command to the congestion determination module, which then upgrades the congestion status to a higher congestion level. The upgraded congestion level triggers the joint decision-making module to re-execute the joint generation process. The cache configuration module, priority scheduling module, and traffic splitting module then perform corresponding adjustments based on the regenerated set of linkage response parameters. The data flow from the effect evaluation module → congestion determination module → joint decision-making module → cache configuration module / priority scheduling module / traffic splitting module → effect evaluation module constitutes a complete closed-loop control circuit.

[0112] The aforementioned modules can be implemented as independent hardware logic units within the switching chip, or as software functional modules running on a general-purpose processor. In the software implementation, an electronic device includes a processor and a memory. The memory stores computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of the aforementioned congestion control method for lossless networks.

[0113] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0114] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0115] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A congestion control method for lossless networks, applied to a network splitter with multiple input ports and multiple output ports, characterized in that, Includes the following steps: S1. Collect the queue depth of each output port; S2. Compare the queue depth with the congestion threshold to determine the congestion status of each output port; the congestion status includes multiple congestion levels arranged from low to high according to the severity of congestion, and each congestion level corresponds to a set of predefined linkage response parameters, the linkage response parameter set includes cache depth configuration parameters, traffic scheduling priority weight and traffic splitting weight; S3. Based on the current congestion level, obtain the corresponding cache depth configuration parameters and traffic splitting weights from the linkage response parameter set; the cache depth configuration parameters and the traffic splitting weights are jointly generated based on the same queue depth vector within the same decision period, and the cache depth configuration parameters and the traffic splitting weights are inversely correlated for the same output port; S4. Adjust the cache depth of the corresponding output port according to the cache depth configuration parameters in the linkage response parameter set, and adjust the scheduling priority of each output port according to the traffic scheduling priority weight in the linkage response parameter set. S5. Based on the traffic distribution weights in the linkage response parameter set, the traffic to be forwarded is distributed to each output port for output; S6. Within the evaluation window after the adjustment actions of S4 and S5 are executed, the change in packet loss rate is statistically analyzed; In response to the change in packet loss rate indicating that the adjustment action is ineffective, the congestion state is upgraded to a higher congestion level and S3 to S5 are re-executed.

2. The congestion control method for lossless networks according to claim 1, characterized in that, In S2, the lowest level among the multiple congestion levels is the normal state; An upgrade threshold and a downgrade threshold are configured for each congestion level, wherein the upgrade threshold is higher than the downgrade threshold, forming a hysteresis interval; In response to a single sample value of the queue depth exceeding the upgrade threshold corresponding to the current congestion level, the congestion state is upgraded to the corresponding higher congestion level; In response to the queue depth being lower than the downgrade threshold corresponding to the current congestion level for M consecutive sampling periods, the congestion state is downgraded to the corresponding lower congestion level.

3. The congestion control method for lossless networks according to claim 2, characterized in that, In S4, the buffer for each output port includes a shallow buffer and a deep buffer; In response to the congestion state being in the normal state, the deep cache is in the off state, and the traffic to be forwarded is forwarded only through the shallow cache; In response to the congestion state escalating to a congestion level higher than the normal state, the open capacity of the deep cache is set to a preset capacity value corresponding to the current congestion level, and the open capacity increases progressively as the congestion level increases.

4. The congestion control method for lossless networks according to claim 2, characterized in that, In S5: In response to the congestion level reaching a preset activation level, the traffic splitting weight is inversely proportional to the queue depth of the corresponding output port, and the traffic to be forwarded is weighted and distributed to each output port according to the traffic splitting weight; In response to the congestion state being in the normal state, the traffic to be forwarded is distributed to each output port according to the polling strategy.

5. The congestion control method for lossless networks according to claim 4, characterized in that, S5 further includes the following sub-steps: S51. Establish flow tables at each output port and perform flow segmentation and statistics on the traffic passing through each output port according to the five-tuple hash. S52. In response to the instantaneous rate of a single stream exceeding a preset proportion of the bandwidth of the corresponding output port, the single stream is marked as an image stream; S53. Migrate the image stream to the output port with the highest splitting weight.

6. The congestion control method for lossless networks according to claim 3, characterized in that, It also includes the following steps: S7. In response to the congestion state reaching the highest congestion level and the open capacity of the deep cache reaching the maximum configuration value, a backpressure signal is sent to the upstream device to notify the upstream device to suspend sending data to the corresponding output port; In S7, the reverse pressure signal has an upper limit on its duration; In response to the duration of the backpressure signal reaching the upper limit of the duration, the backpressure signal is released, and the traffic splitting strategy is switched to selectively discard low-priority traffic according to the traffic scheduling priority weight.

7. The congestion control method for lossless networks according to claim 1, characterized in that, In step S1, a queue depth comparator is configured in the switching chip. When the queue depth of any output port crosses the congestion threshold, a congestion event interrupt is generated through the queue depth comparator, triggering the execution of step S2.

8. The congestion control method for lossless networks according to claim 1, characterized in that, In S1, the queue depth is periodically collected at low-frequency sampling intervals; In response to the monotonically increasing sampled value of the queue depth over P consecutive sampling periods, the sampling interval is switched from the low-frequency sampling interval to the high-frequency sampling interval, wherein the span between the low-frequency sampling interval and the high-frequency sampling interval is at least two orders of magnitude. In response to the fact that the sampled value of the queue depth is lower than the congestion threshold for Q consecutive sampling periods under the high-frequency sampling interval, the sampling interval is restored to the low-frequency sampling interval.

9. The congestion control method for lossless networks according to claim 2, characterized in that, In step S6, in response to the change in packet loss rate indicating that the adjustment action has been effective for K consecutive times, the upgrade threshold is lowered and the downgrade threshold is raised to narrow the hysteresis interval.

10. A shunt system for congestion control in lossless networks, characterized in that, include: The queue depth monitoring module is configured to collect the queue depth of each output port; The congestion determination module is configured to compare the queue depth with the congestion threshold to determine the congestion status of each output port. The congestion status includes multiple congestion levels arranged from low to high congestion severity. Each congestion level corresponds to a set of predefined linkage response parameters, which include cache depth configuration parameters, traffic scheduling priority weights, and traffic splitting weights. The joint decision-making module is configured to obtain the corresponding cache depth configuration parameters and traffic splitting weights from the linkage response parameter set according to the current congestion level. The cache depth configuration parameters and the traffic splitting weights are jointly generated based on the same queue depth vector within the same decision period. The cache depth configuration parameters and the traffic splitting weights are inversely correlated with the same output port. A cache configuration module is configured to adjust the cache depth of the corresponding output port according to the cache depth configuration parameter; A priority scheduling module is configured to adjust the scheduling priority of each output port according to the traffic scheduling priority weight; The traffic splitting module is configured to distribute the traffic to be forwarded to each output port for output according to the traffic splitting weight; The effect evaluation module is configured to count the change in packet loss rate within the evaluation window after the adjustment actions of the cache configuration module and the traffic splitting module are executed. In response to the change in packet loss rate indicating that the adjustment action is invalid, the congestion state is upgraded to a higher congestion level and the joint decision module is triggered to re-execute the joint generation. The cache configuration module, the priority scheduling module and the traffic splitting module perform corresponding adjustments according to the regenerated linkage response parameter set.

Images