A network state-aware congestion rerouting method and system

Abstract

This invention discloses a network state-aware congestion-prone flow rerouting method and system. The method specifically includes: under congestion conditions, statistically calculating the contribution of each flow to the queue, dynamically determining a large flow judgment threshold based on the number of active flows, and identifying flows with contributions exceeding the large flow judgment threshold as responsible elephant flows; based on the responsible elephant flow list and network state information, modeling the rerouting problem as a mixed-integer programming model with the objective of minimizing maximum link utilization, and solving for the globally optimal path allocation scheme; according to the globally optimal path allocation scheme, installing new path forwarding rules and deleting old path rules on each switch using a build-then-tear strategy. This invention achieves sub-second congestion response and globally optimal traffic scheduling through cross-layer collaboration between the data plane and control plane, effectively avoiding the congestion migration problem caused by traditional reactive rerouting.

Description

Technical Field

[0001] This invention belongs to the field of computer network technology, specifically relating to a method and system for rerouting congested large flows based on network state awareness. Background Technology

[0002] With the rapid development of applications such as cloud computing, big data analytics, and distributed machine learning, the scale and complexity of traffic carried by modern networks continue to grow. In these application scenarios, network performance directly impacts the quality of upper-layer services and user experience. Research shows that even millisecond-level network latency jitter can significantly increase the completion time of distributed computing tasks, thereby affecting overall system efficiency. Therefore, instantaneous congestion caused by traffic bursts has become one of the core challenges facing network operations and maintenance.

[0003] The first step in congestion control is congestion detection. Traditional solutions deploy detection logic on the control plane, sensing network congestion by periodically polling switch status or receiving statistical information reported by receiving devices. However, this centralized detection method has an inherent latency bottleneck: from the start of queue backlog on the switch to the controller collecting status, analyzing data, and identifying congestion, the entire process typically takes tens or even hundreds of milliseconds. For short-lived, sudden congestion, this latency often means that the congestion has already irreversibly affected flow completion time. The development of programmable data plane technology has provided a new approach to solving this problem—moving the congestion detection logic forward to the switch, enabling it to directly sense queue status changes at line speed, thereby compressing the detection latency to the microsecond level. However, simply achieving fast detection is not enough. Most existing data plane detection schemes use fixed thresholds to determine congestion, making it difficult to distinguish between transient traffic bursts and persistent congestion. More importantly, these schemes remain at the level of "detecting congestion" and lack the ability to analyze the causes of congestion. They cannot answer the key question of "which flows caused the congestion and how much each contributed," which makes subsequent congestion mitigation decisions lack precise basis.

[0004] After detecting congestion and identifying the responsible traffic, the next step is to reroute the congested flow to alternative paths to alleviate bottleneck pressure. Effective rerouting decisions rely on real-time monitoring of the overall network link load status. The emergence of in-band network telemetry (INT) technology provides strong support for obtaining this global view. As packets pass through each hop switch, fine-grained state information such as queue depth, link utilization, and timestamps can be embedded, enabling the control plane to reconstruct the overall network load distribution in near real-time. However, existing rerouting schemes based on telemetry information generally adopt a reactive decision-making model: when congestion is detected, the system migrates traffic to paths that appear to have lower load based on the currently measured link load. This greedy strategy based on immediate state ignores the change in network state caused by the rerouting operation itself—the influx of traffic will cause the target path load to increase. If this impact is not anticipated during decision-making, the new path may quickly become the next congestion point, triggering another round of rerouting, forming a vicious cycle of congestion migration and routing oscillation.

[0005] In summary, existing congestion control technologies face two core challenges: at the detection level, while data plane solutions can achieve rapid response, they lack accurate attribution of responsible traffic; at the scheduling level, while telemetry-based rerouting solutions provide a global view, their reactive decision-making model struggles to prevent congestion migration. Therefore, there is an urgent need for a congestion control method that combines accurate data plane attribution with predictive optimization in the control plane. This method should quickly identify responsible congestion flows while simultaneously predicting the cascading effects of rerouting through a global optimization model, thereby achieving stable and efficient network traffic scheduling. Summary of the Invention

[0006] The purpose of this invention is to provide a network state-aware congestion rerouting method and system, which can quickly and accurately identify congestion and its responsible traffic in the data plane, and avoid congestion migration in the control plane through global optimization, thereby achieving stable and efficient traffic scheduling and solving at least one of the above-mentioned problems in the prior art.

[0007] In a first aspect, the present invention provides a network state-aware congestion rerouting method, the method specifically comprising:

[0008] The switch monitors the occupancy level and growth trend of the output port queue. When the queue occupancy exceeds the threshold and continues to increase within multiple consecutive time windows, it is determined that the system has entered a congestion state.

[0009] In a congested state, the contribution of each flow to the queue is calculated based on the outbound traffic statistics of time windowing. The threshold for determining large flows is dynamically determined in combination with the number of active flows. Flows whose contribution exceeds the threshold for determining large flows are identified as responsible elephant flows, and a list of responsible elephant flows is formed.

[0010] The congestion notification, which includes congestion location information, a list of responsible elephant flows, and their contribution estimates, is reported to the control plane via the switch.

[0011] Based on the responsibility elephant flow list and network status information, the rerouting problem is modeled as a mixed integer programming model with the objective of minimizing the maximum link utilization, and the globally optimal path allocation scheme is obtained by solving it.

[0012] Based on the globally optimal path allocation scheme, a build-then-delete strategy is adopted to install new path forwarding rules on each switch and delete old path rules to achieve smooth route switching.

[0013] Secondly, the present invention provides a network state-aware congestion rerouting system, the system specifically comprising:

[0014] The data plane detection module is used to monitor the occupancy level and growth trend of the output port queue through the switch. When the queue occupancy exceeds the threshold and continues to increase within multiple consecutive time windows, it is determined that the system has entered a congestion state.

[0015] The network telemetry module is used to calculate the contribution of each flow to the queue based on time-windowed outbound traffic statistics under congestion conditions. It dynamically determines the threshold for large flow judgment by combining the number of active flows, identifies flows whose contribution exceeds the threshold for large flow judgment as responsible elephant flows, and forms a list of responsible elephant flows.

[0016] The congestion reporting module is used to report congestion notifications, which include congestion location information, a list of responsible elephant flows and their contribution estimates, to the control plane via a switch.

[0017] The control plane rerouting module is used to model the rerouting problem as a mixed integer programming model with the objective of minimizing the maximum link utilization, based on the responsibility elephant flow list and network status information, and solve it to obtain the globally optimal path allocation scheme.

[0018] The rule distribution module is used to install new path forwarding rules and delete old path rules on each switch according to the global optimal path allocation scheme and adopt the strategy of building first and then tearing down, so as to achieve smooth route switching.

[0019] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the network state-aware congestion rerouting method as described in any of the above methods.

[0020] Compared with the prior art, the present invention has at least one of the following technical effects:

[0021] 1. This invention achieves sub-second congestion response and globally optimal traffic scheduling through cross-layer collaboration between the data plane and the control plane, effectively avoiding the congestion migration problem caused by traditional reactive rerouting;

[0022] 2. This invention can quickly and accurately identify congestion and its responsible traffic in the data plane, and can also avoid congestion migration in the control plane through global optimization, thus achieving stable and efficient traffic scheduling.

[0023] 3. This invention achieves fast and accurate congestion detection and responsible flow identification in the data plane through cross-layer collaboration between the data plane and the control plane, and implements predictive rerouting optimization based on global state in the control plane. This ensures real-time response while avoiding congestion migration, thus achieving stable and efficient network congestion control.

[0024] 4. This invention achieves rapid congestion response capability. By moving the congestion detection and high-flow identification logic forward to the data plane, the switch can complete congestion determination and responsibility attribution at line speed without waiting for periodic polling from the control plane, significantly shortening the time interval from congestion occurrence to system response;

[0025] 5. This invention effectively avoids congestion migration problems. The control plane uses a global optimization model for rerouting decisions. When evaluating candidate solutions, it not only considers the mitigation effect on the current bottleneck, but also predicts the impact on other links through capacity constraints and load balancing objectives, thereby avoiding congestion migration and routing oscillations caused by traditional reactive rerouting.

[0026] 6. This invention improves detection stability through a dual-indicator congestion determination mechanism. By combining two indicators—queue occupancy level and growth trend—it can effectively distinguish between transient traffic fluctuations and genuine congestion, reducing false triggers;

[0027] 7. This invention adapts to different concurrency scenarios by using an adaptive large flow identification threshold. The judgment threshold is dynamically adjusted according to the number of active flows, avoiding over-labeling in low-concurrency scenarios and accurately identifying large flows that contribute significantly in high-concurrency scenarios. Attached Figure Description

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

[0029] Figure 1 This is a flowchart illustrating a network state-aware congestion rerouting method according to an embodiment of the present invention.

[0030] Figure 2 This is a schematic diagram of the structure of a network state-aware congestion rerouting system provided in an embodiment of the present invention. Detailed Implementation

[0031] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0032] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating a network state-aware congestion rerouting method based on an embodiment of the present invention is shown below, in detail:

[0033] S101 monitors the occupancy level and growth trend of the output port queue through the switch. When the queue occupancy exceeds the threshold and continues to increase within multiple consecutive time windows, it determines that the system has entered a congestion state.

[0034] In this embodiment, the data plane congestion detection step is as follows: The switch continuously monitors the occupancy level and its changing trend of the output port queue. When the queue occupancy exceeds a preset threshold and shows a continuous increasing trend over multiple consecutive time windows, the queue is determined to be in a congested state. The congestion state determination adopts a dual-indicator mechanism, specifically including:

[0035] Divide the timeline into equal-length time windows, and sample the current queue occupancy rate at the end of each window;

[0036] Let the queue occupancy threshold be α. When the queue occupancy ratio exceeds α and the queue occupancy shows a monotonically increasing trend in the most recent K consecutive time windows, the queue is determined to be in a congested state.

[0037] The growth trend constraint is used to filter transient fluctuations caused by short-term traffic bursts, thereby improving the stability of congestion detection.

[0038] S102, under congestion conditions, calculate the contribution of each flow to the queue based on time-windowed outbound traffic statistics, dynamically determine the threshold for determining large flows by combining the number of active flows, identify flows whose contribution exceeds the threshold for determining large flows as responsible elephant flows, and form a list of responsible elephant flows.

[0039] In this embodiment, the congestion flow identification step is as follows: Under congestion conditions, the contribution of each flow to the queue is calculated based on time-windowed dequeue flow statistics. A large flow determination threshold is dynamically determined by combining this with the number of active flows. Flows with a contribution exceeding the threshold are identified as responsible large flow flows. The flow contribution calculation method includes:

[0040] For streams In the time window The contribution of the flow within the window is defined as the contribution of the flow within the window. The sum of the number of bytes of all out-of-queue packets;

[0041] For any data packet, the dequeue statistics of its flow are accumulated over multiple time windows during the waiting period in the queue to obtain an estimate of the cumulative contribution of the flow during the waiting period.

[0042] The contribution calculation is based entirely on observable dequeue events, without the need to maintain real-time queue status.

[0043] Adaptive methods for determining the threshold for large flow judgment include:

[0044] Let the estimated number of active flows in the current queue be... Flow determination threshold Defined as: ,in This is the preset minimum contribution ratio;

[0045] When the number of active flows is small, the threshold is automatically increased to avoid over-marking; when the number of active flows is large, the threshold degenerates to the minimum constraint. Only flows with significantly larger contributions are identified;

[0046] In the data plane implementation, a discretization strategy is adopted: the number of active streams is estimated in a coarse-grained manner and mapped to a predefined interval, and the corresponding threshold is obtained by looking up the table according to the interval.

[0047] S103 reports a congestion notification, which includes congestion location information, a list of responsible elephant flows, and their contribution estimates, to the control plane via a switch.

[0048] In this embodiment, the congestion information reporting step is as follows: the switch sends a congestion notification to the control plane, the notification including congestion location information, a list of responsible elephant flows and their contribution estimates.

[0049] The congestion information reporting mechanism specifically includes:

[0050] (1) Congestion notification format

[0051] Once the congestion identification unit has completed the identification of the responsible elephant flows, the notification generation unit encapsulates the congestion notification and sends it to the control plane. The congestion notification uses a structured format and includes the following fields:

[0052] Notification header:

[0053] Message type: Indicates that this is a congestion notification;

[0054] Timestamp: The time the notification was generated;

[0055] Switch identifier: The ID of the switch that sent the notification;

[0056] Port identifier: The output port number where congestion occurred;

[0057] Queue depth: The current level of queue occupancy;

[0058] Congestion duration: The time elapsed since congestion was detected;

[0059] Elephant Flow List: For each identified responsible elephant flow, it includes:

[0060] Flow identifier: a 5-tuple (source IP, destination IP, source port, destination port, protocol number);

[0061] Estimated bandwidth: The estimated bandwidth of the stream calculated based on the cumulative contribution.

[0062] Contribution percentage: The percentage of traffic that this flow contributes to the dequeueing flow during congestion.

[0063] (2) Notification triggering strategy

[0064] To avoid overloading the control plane due to repeated notifications, the system adopts the following triggering strategy:

[0065] De-jitter mechanism: A notification is only triggered after a congestion state has lasted for a minimum duration T_min (T_min = 5 milliseconds in this embodiment). This avoids notifications being generated for extremely short-lived congestion events;

[0066] Notification interval limit: For the same queue, the minimum interval between two notifications is T_interval (in this embodiment, T_interval = 100 milliseconds). During this interval, no new notifications will be sent even if congestion persists or worsens.

[0067] State change trigger: If the identified elephant stream set changes significantly during the waiting interval (e.g., a major contributing stream is added or removed), a new notification can be triggered in advance.

[0068] (3) Notification transmission

[0069] Congestion notifications are sent from the switch to the control plane via a dedicated control channel. This embodiment employs the following transmission method:

[0070] The notification is encapsulated as a UDP packet, with the destination address being the controller IP and the destination port being a predefined control port. The notification packet is forwarded internally by a high-priority queue to ensure that the notification reaches the control plane in a timely manner.

[0071] The control plane maintains persistent connections with each switch and receives and parses congestion notifications. Upon receiving a notification, the control plane first performs a validity check, and then passes the notification content to the state fusion unit for processing.

[0072] S104, based on the responsibility elephant flow list and network status information, models the rerouting problem as a mixed integer programming model with the objective of minimizing the maximum link utilization, and solves the globally optimal path allocation scheme.

[0073] In this embodiment, the control plane rerouting optimization solution steps are as follows: the elephant flow rerouting problem is modeled as a mixed integer nonlinear programming problem, with the goal of minimizing the maximum link utilization, and a globally optimal path allocation scheme that satisfies flow conservation constraints and capacity constraints is solved.

[0074] The rerouting optimization model includes:

[0075] Decision variables: For each elephant flow f and each link e, define a binary variable representing whether flow f passes through link e; define a continuous variable ρ representing the maximum link utilization; define a continuous variable... This indicates the total utilization rate of each link;

[0076] Optimization objective: Minimize the weighted sum of the maximum link utilization ρ and the path delay penalty term, where the path delay penalty term is used to encourage the selection of shorter paths;

[0077] Optimization objective: Minimize the weighted sum of the maximum link utilization ρ and the link utilization variance penalty term, i.e. , where λ is the weighting coefficient; the bottleneck elimination term ρ is used to minimize the peak load of the entire network, and the variance penalty term uses the convexity of the quadratic function to apply a superlinear penalty to the high-load links, so as to promote the balanced distribution of traffic across the entire network;

[0078] Flow conservation constraint: For each flow and each node, the difference between the inflow and outflow is equal to the net demand of that node, ensuring that a complete path is formed from the source to the destination;

[0079] Capacity constraint: The sum of the background load of each link and the demand of the elephant flow passing through that link shall not exceed the product of the link capacity and the maximum utilization.

[0080] Path length constraint: The number of hops in each flow path does not exceed a preset limit.

[0081] The optimization model's solution acceleration strategies include:

[0082] Warm-start initialization: Encode the current path of each elephant flow into an initial feasible solution and provide it to the solver;

[0083] Problem simplification: Limit the search space to a subgraph where the number of hops between source and destination nodes does not exceed a preset limit; pre-filter links with background loads close to the capacity limit; merge multiple elephant flows with the same source and destination node pairs.

[0084] Time control: Sets the upper limit of solution time and relative gap tolerance, and returns the current optimal solution when any termination condition is met.

[0085] Furthermore, it also includes a rollback mechanism:

[0086] When the optimization solution fails to find a feasible solution within the time limit, switch to greedy mode;

[0087] Process each large flow in descending order of bandwidth demand, and calculate a weighted shortest path for each flow. The weights take into account both link latency and current utilization.

[0088] After each flow is assigned a path, the utilization rate of the corresponding link is updated immediately, affecting the path selection of subsequent flows.

[0089] S105, based on the globally optimal path allocation scheme, adopts a build-then-tear strategy to install new path forwarding rules and delete old path rules on each switch, thereby achieving smooth route switching.

[0090] In this embodiment, the route distribution and activation steps are as follows: a build-then-delete strategy is adopted, which first installs forwarding rules along the new path and then deletes the old path rules to achieve smooth route switching.

[0091] Specifically, the "build first, demolish later" strategy includes:

[0092] For each elephant flow that is rerouted, first install forwarding rules at each hop switch along the new path;

[0093] Waiting for a preset convergence time gives data packets in transit a chance to reach their destination along the old path;

[0094] Delete forwarding rules that are no longer needed on the old path;

[0095] The strategy ensures that at any given time there is at least one valid path from the source to the destination.

[0096] In some embodiments, step S101 above, which involves monitoring the occupancy level and growth trend of the output port queue through the switch, and determining that a congestion state has been entered when the queue occupancy exceeds a threshold and continues to increase within multiple consecutive time windows, specifically includes:

[0097] Divide the timeline into equal-length time windows and sample the current queue occupancy rate at the end of each time window;

[0098] Maintain a historical sample containing the queue occupancy ratios from multiple recent time windows;

[0099] When the queue occupancy rate in the latest historical samples exceeds a preset threshold, and the queue occupancy rate in the historical samples shows a monotonically increasing trend over multiple consecutive time windows, the system is determined to be in a congested state.

[0100] In this embodiment, the congestion status determination adopts a dual-indicator mechanism combining queue occupancy level and growth trend, specifically including:

[0101] (1) Time window division: Divide the time axis into time windows of equal length. The window length is set according to the network environment and performance requirements. At the end of each window, sample and record the current queue occupancy ratio.

[0102] (2) Congestion determination: Let the queue occupancy threshold be α (for example, α=0.8, indicating that the queue occupancy has reached 80% of its capacity). The queue is determined to be in a congestion state when the following two conditions are met:

[0103] Condition 1: The current queue occupancy rate exceeds the threshold α;

[0104] Condition 2: Within the most recent K consecutive time windows (e.g., K=3), the queue occupancy shows a monotonically increasing trend.

[0105] (3) Design Principle: The purpose of introducing the growth trend constraint is to filter transient fluctuations caused by short-term traffic bursts. The judgment method based solely on the queue occupancy threshold has obvious limitations: in high-load scenarios, the queue may remain at a high level for a long time but does not necessarily mean abnormal congestion; while a short-term traffic burst may instantly increase the queue occupancy, but it will not evolve into continuous congestion. By requiring the queue occupancy to continuously increase within multiple consecutive windows, it is possible to effectively distinguish between transient fluctuations and real congestion trends, thereby improving the stability and accuracy of detection.

[0106] In some embodiments, in step S102 above, the step of calculating the contribution of each flow to the queue based on time-windowed dequeue flow statistics under congestion conditions, dynamically determining the large flow judgment threshold in combination with the number of active flows, and identifying flows whose contribution exceeds the large flow judgment threshold as responsible elephant flows specifically includes:

[0107] Based on the congestion status, initiate time-window-based dequeue traffic statistics to obtain an estimate of the contribution of each flow;

[0108] Estimate the number of active flows in the current queue and dynamically calculate the large flow judgment threshold based on the number of active flows;

[0109] The contribution estimates of each flow are compared with the dynamic large flow determination threshold, and flows whose contribution estimates exceed the large flow determination threshold are identified as responsible elephant flows.

[0110] In this embodiment, the data plane congestion detection mechanism specifically includes:

[0111] (1) Queue monitoring and time window division

[0112] Data plane congestion detection monitors the queues at switch output ports. The queue monitoring unit divides the time axis into equal-length time windows, with a window length of... Based on the network environment and performance requirements, this embodiment takes... millisecond;

[0113] At the end of each time window, the queue monitoring unit samples the queue depth value in the current queue, denoted as q(t): representing the amount of data (in bytes) buffered in the queue at the end of the time window corresponding to time t. The maximum capacity of the queue... Determined by the switch hardware configuration, it is a known constant.

[0114] (2) Historical queue depth recording mechanism

[0115] To characterize the short-term evolution trend of the queue state, the queue monitoring unit maintains a circular buffer of length K to store the queue depth sample values ​​within the most recent K time windows. In this embodiment, K=3, meaning the buffer stores the following values ​​sequentially: . Indicates time The amount of data (in bytes) cached in the queue at the end of the corresponding time window. Indicates time The amount of data (in bytes) cached in the queue at the end of the corresponding time window;

[0116] When a new time window ends, the latest sampled value is enqueued and the oldest sampled value is dequeued. The update is completed by shifting the register, without introducing additional processing latency.

[0117] (3) Dual-indicator congestion status determination

[0118] The congestion determination unit determines the congestion status based on two indicators: queue occupancy level and growth trend. The specific determination logic is as follows:

[0119] Condition 1 (Occupancy Level Condition): The current queue occupancy rate exceeds the preset threshold α, that is: In this embodiment, α=0.8, which means that the occupancy level condition is met when the queue occupies more than 80% of its capacity;

[0120] Condition 2 (Growth Trend Condition): Within the most recent K consecutive time windows, the queue occupancy shows a monotonically increasing trend, that is: ;

[0121] The congestion determination unit determines that the queue is in a congested state and triggers the subsequent high-flow identification process only if both conditions 1 and 2 are met simultaneously.

[0122] The principle behind introducing the growth trend condition is as follows: In real-world networks, queue occupancy may spike momentarily due to short-term traffic surges, but these transient fluctuations usually subside quickly and do not constitute persistent congestion. If judgment is based solely on occupancy level thresholds, these transient events will frequently trigger congestion alerts, leading to unnecessary rerouting operations. By requiring queue occupancy to continuously increase over multiple consecutive windows, transient fluctuations can be effectively filtered out, and only events that truly evolve into persistent congestion can be responded to.

[0123] (4) Data plane implementation

[0124] When implementing the congestion detection logic on a programmable switch, hardware resource constraints need to be considered. This embodiment adopts the following implementation method:

[0125] Queue occupancy sampling is achieved by reading the queue depth register provided by the switch. This operation can be completed within the packet processing pipeline without introducing additional latency. The circular buffer is implemented using a register array, with each output port maintaining K registers to store the sampled values ​​of the K most recent windows. During window switching, the buffer contents are updated via shift operations. The congestion determination logic is implemented using a comparator and is executed when a packet dequeues. The determination result is stored in a status register for subsequent read by the high-flow identification module.

[0126] The congestion flow identification mechanism specifically includes:

[0127] (1) Statistics on the contribution of traffic flow

[0128] Once the queue enters a congested state, the contribution statistics unit begins to calculate the contribution of each flow to the queue. The contribution statistics are implemented based on time-windowed dequeue traffic statistics.

[0129] For each time window The system maintains a traffic statistics table, recording the number of outbound bytes for each flow within this window. When a data packet... When leaving the queue, the system performs the following operations:

[0130] 1) Extract the identifier of the stream to which the data packet belongs (this embodiment uses a 5-tuple: source IP, destination IP, source port, destination port, protocol number);

[0131] 2) Locate the record for this flow in the flow statistics table; if it does not exist, create a new record.

[0132] 3) Reduce data packet size Add this to the count of dequeued bytes for this stream in the current window;

[0133] Flow f in the time window The contribution within is defined as:

[0134] ;

[0135] in, Indicates data packet The time of departure is used to sum and iterate through all instances in the window. Packets that are out of queue and belong to flow f. To estimate the cumulative contribution of a flow during congestion, the system maintains statistics for multiple consecutive windows.

[0136] (2) Estimation of the number of active flows

[0137] The active flow estimation unit is responsible for estimating the number N of active flows in the current queue, which is used to calculate the adaptive large flow determination threshold;

[0138] Accurately counting active flows requires maintaining a complete flow table, which is costly in the data plane. This embodiment uses a probabilistic data structure for approximate estimation. Specifically, the HyperLogLog algorithm is used, which requires only O(log logn) space to estimate the cardinality of n distinct elements, and the error rate can be controlled at a low level.

[0139] The implementation is as follows: A HyperLogLog counter is maintained for each output port. When a packet leaves the queue, the hash value of its flow identifier is entered into the counter to update it. When the number of active flows needs to be obtained, an estimate is read from the counter. The counter is reset at the end of each statistical period to reflect the current active flow status.

[0140] In scenarios with more limited resources, a simpler estimation method can be used: maintain a fixed-size stream identifier cache and roughly estimate the size of active streams by the degree of cache filling.

[0141] (3) Adaptive large flow determination threshold

[0142] The large flow identification unit dynamically determines the large flow judgment threshold based on the number of active flows. The threshold calculation formula is: ;

[0143] in, As a preset minimum contribution ratio, this embodiment takes =0.1.

[0144] The design principle of this formula is as follows:

[0145] When the number of active flows N is small (e.g., N=2), if the traffic is evenly distributed, the average contribution of each flow is 50%. In this case, the threshold β=max(0.1,0.5)=0.5, and only flows with a contribution exceeding 50% are identified as large flows. This avoids the problem of marking multiple flows as large flows in low-concurrency scenarios.

[0146] When the number of active flows N is large (e.g., N=100), if the traffic is evenly distributed, the average contribution of each flow is only 1%. In this case, the threshold β=max(0.1,0.01)=0.1, and only flows with a contribution exceeding 10% are identified as large flows. This ensures that in high-concurrency scenarios, only flows with significantly larger contributions are marked.

[0147] Considering the computational constraints of the data plane, this embodiment employs a discretization strategy. The number of active flows is mapped to several predefined intervals, each interval corresponding to a pre-configured threshold. During data plane runtime, the threshold is obtained by looking up the estimated number of active flows in a table, eliminating the need for division operations.

[0148] Furthermore, the initiation of time-windowed dequeue traffic statistics to obtain contribution estimates for each flow specifically includes:

[0149] When a data packet dequeues within any time window, extract the flow identifier and data packet size of that data packet.

[0150] Update the cumulative dequeue bytes of the corresponding stream within the statistical time window based on the stream identifier;

[0151] The contribution estimate of each flow is calculated based on the cumulative number of dequeued bytes of each flow across all time windows.

[0152] In this embodiment, the traffic contribution calculation method is based on statistics of dequeue events, specifically including:

[0153] (1) Definition of contribution: For flow In the time window Contribution within ( ), defined as the flow in the window The sum of the number of bytes in all out-of-queue packets. Formalized as: ;

[0154] in, Indicates belonging to the flow data packets, Indicates data packet The time of departure, size( () indicates the data packet size;

[0155] (2) Cumulative contribution estimation: For any data packet The waiting time of a data packet in the queue may span multiple time windows. By summing the dequeue statistics of its flow within these windows, the cumulative contribution of that flow during the packet waiting period can be estimated.

[0156] (3) Implementation advantages: The contribution calculation is based entirely on observable dequeue events, without the need to maintain real-time queue state or global flow view. All calculations are triggered when data packets are dequeued, which complies with the computation and storage constraints of the programmable data plane.

[0157] Furthermore, the estimation of the number of active flows in the current queue, and the dynamic calculation of the large flow determination threshold based on the number of active flows, specifically includes:

[0158] Based on packet dequeue events, a cardinality estimate of the number of active flows is obtained by using a probabilistic statistical algorithm to perform cardinality estimation on different flow identifiers.

[0159] Based on the estimated number of active flows, the corresponding threshold range for determining large flows is determined according to a predefined mapping relationship.

[0160] Obtain the specific flood determination threshold from the flood determination threshold range.

[0161] In this embodiment, the adaptive large flow determination threshold is dynamically adjusted according to the number of active flows, specifically including:

[0162] (1) Threshold calculation formula: Let the estimated number of active flows in the current queue be N, and the large flow judgment threshold β is defined as: in, For the preset minimum contribution ratio (e.g.) =0.1 indicates that at least 10% of the queue resources must be occupied before it is considered a large flow.

[0163] (2) Adaptive principle:

[0164] When the number of active flows N is small, the value of 1 / N is large, and the threshold β automatically increases. This is because in low-concurrency scenarios, the average contribution of a single flow to the queue is inherently high, requiring a stricter threshold to avoid over-marking.

[0165] When the number of active flows N is large, the value of 1 / N is small, and the threshold β degenerates to the minimum constraint. This ensures that, in high-concurrency scenarios, only flows with significantly larger contributions are identified as the responsible elephant flows.

[0166] (3) Discretization Implementation: Considering the computational constraints of the data plane, accurately estimating N and performing continuous scaling operations is costly. Therefore, a discretization strategy is adopted: coarse-grained estimation of the number of active flows is performed and mapped to several predefined intervals (e.g., 1-5, 6-20, 21-100, >100); for each interval, a corresponding large flow judgment threshold is pre-configured. During runtime, the data plane only needs to look up the threshold in a table based on the estimation results, without performing complex calculations.

[0167] In some embodiments, step S104 above, which involves modeling the rerouting problem as a mixed-integer programming model with the objective of minimizing maximum link utilization based on the responsibility elephant flow list and network state information, and solving for the globally optimal path allocation scheme, specifically includes:

[0168] By combining network telemetry data with the responsibility elephant flow list, the overall network status information, including the background load and link capacity of each link, is reconstructed.

[0169] Based on the network-wide status information and the list of responsible elephants, a hybrid integer programming model is constructed with the objective of minimizing the maximum link utilization.

[0170] Solving the mixed-integer programming model yields the globally optimal path allocation scheme for each flow in the list of responsible elephant flows.

[0171] In this embodiment, control plane state reconstruction specifically includes:

[0172] (1) Network telemetry data processing

[0173] The control plane continuously receives link status information from the network telemetry module. In this embodiment, in-band network telemetry (INT) technology is used, and the following metadata is inserted into probe packets as they pass through each hop switch: switch identifier and port identifier, queuing delay, current queue depth, and cumulative number of bytes sent along the link.

[0174] After the probe data packet arrives at the destination, the INT agent extracts the aforementioned metadata and reports it to the control plane. The control plane then calculates the status indicators for each link based on this data.

[0175] Link utilization: Calculated based on the difference in cumulative bytes between two adjacent probes and the time interval.

[0176] ;

[0177] in, The cumulative number of bytes sent at time t. Indicates time The cumulative number of bytes sent. Indicates time The cumulative number of bytes sent. Indicates within the time interval [ , The cumulative number of bytes sent within [ ] For link capacity, Indicates within the time interval [ , Link capacity within ];

[0178] Queue depth: Read directly from the metadata carried in the probe packets. The state fusion unit maintains a link state table, recording the above metrics for each directed link. The link state table is updated every [period]. (This embodiment takes) Updated every millisecond to ensure that the deviation between the state information held by the control plane and the actual network condition is kept within an acceptable range.

[0179] (2) Elephant Flow Report Merging

[0180] Since the same elephant flow may be detected by multiple switches along its path, the control plane needs to deduplicate and merge reports from different switches.

[0181] The state fusion unit maintains a table of elephant flows to be rerouted. Upon receiving a new congestion notification, for each elephant flow in the notification, the following processing is performed:

[0182] 1) Search the table to see if a record for the stream already exists based on the stream identifier (5-tuple);

[0183] 2) If it does not exist, create a new record and fill in the flow identifier, estimated bandwidth, and source switch information;

[0184] 3) If it already exists, compare the estimated bandwidth in the new report with the existing records:

[0185] If the estimated bandwidth in the new report is larger, update the estimated bandwidth and source switch information in the record;

[0186] Otherwise, leave the existing records unchanged.

[0187] The principle behind retaining a larger estimated bandwidth is that on switches closer to the flow source, the measured flow bandwidth is closer to the actual transmission rate of the flow; while on switches closer to the bottleneck, the flow may have been throttled due to congestion, and the measured value may be lower.

[0188] (3) Background load correction

[0189] Before building the optimization model, the control plane needs to subtract the contribution of the elephant flow to be rerouted from the original load measurements of the links to avoid the bandwidth requirements being calculated repeatedly.

[0190] For each link e, the corrected background load is calculated as follows:

[0191] 1) Obtain the raw load measurement value of link e (From network telemetry data);

[0192] 2) Determine the set of flows that the current path passes through link e within the elephant flow set F to be rerouted. ;

[0193] 3) Calculate the total bandwidth of the elephant streams that need to be deducted: ;

[0194] 4) Calculate the corrected background load: .

[0195] If the corrected value is negative (possibly due to measurement error or time deviation), then set it to 0.

[0196] Corrected background load This reflects the link occupancy of traffic that does not participate in rerouting, and will be used as input to the optimization model.

[0197] The specific steps for rerouting optimization include:

[0198] (1) Optimize model construction:

[0199] The optimization modeling unit models the elephant flow rerouting problem as a mixed-integer quadratic programming problem. The model construction process is as follows:

[0200] Input preparation:

[0201] The network topology graph G=(V,E) is obtained from the network configuration database;

[0202] Capacity of each link Retrieved from the network configuration database;

[0203] Background load after link correction Provided by the state fusion unit;

[0204] The set of elephant flows to be rerouted, F, where each flow contains a source node. , destination node t and bandwidth requirements .

[0205] Definition of decision variables:

[0206] For each flow and each link Define binary variables ;

[0207] Define continuous variables Indicates the maximum link utilization;

[0208] Define continuous variables This represents the total utilization rate of each link e;

[0209] The objective function is defined as follows:

[0210] ;

[0211] Where λ is the weighting coefficient. The objective function consists of two parts:

[0212] Bottleneck elimination term ρ: Directly minimize the peak load of the entire network to ensure that the pressure on the most congested links is relieved. This is the primary optimization objective, with a weight of 1.

[0213] Variance penalty term This approach leverages the convexity of quadratic functions to impose a superlinear penalty on high-load links. Specifically, when a link's utilization increases from 50% to 60%, the penalty increment is 0.36 - 0.25 = 0.11; while from 80% to 90%, the penalty increment is significantly larger at 0.81 - 0.64 = 0.17. This superlinear characteristic forces the optimizer to prioritize paths that distribute network traffic more evenly among multiple feasible paths, rather than directing traffic to a currently low-load "low-lying area," thus effectively preventing the creation of new congestion points.

[0214] The weighting coefficients are set to maintain a balance between eliminating the primary bottleneck (reducing the peak value) and the secondary bottleneck (balancing the distribution). A smaller λ value ensures that bottleneck elimination is always the priority, while the variance penalty term plays a role in selecting the best option when multiple options have similar peak values.

[0215] Link utilization definition: This definition expresses link utilization as the ratio of the sum of background load and the demand of elephant flows passing through the link to the link capacity.

[0216] Constraints:

[0217] Flow conservation constraints (for each flow f and each node v):

[0218] ;

[0219] This represents the set of all links originating from node v. This represents the set of all links pointing to node v. This represents the sum of the traversal patterns of flow f on all links e originating from node v. This represents the sum of the traversal patterns of flow f on all links e pointing to node v;

[0220] Capacity constraints (for each link e): This constraint associates the utilization of each link with the maximum utilization variable, ensuring that ρ can accurately reflect the peak load of the entire network.

[0221] Utilization upper bound constraint: In this embodiment, Reserve 15% capacity margin for the link to cope with traffic fluctuations;

[0222] Path length constraint (for each flow f): In this embodiment, =10;

[0223] Because this model contains binary decision variables and the quadratic objective function term This problem belongs to the Mixed-Integer Quadratic Programming (MIQP) problem. Directly solving it has high computational complexity, so it needs to be transformed and the solution accelerated.

[0224] (2) Piecewise linearization of quadratic terms

[0225] To transform the mixed-integer quadratic programming problem into a more easily solvable mixed-integer linear programming problem, this embodiment uses a piecewise linearization method to approximate the quadratic penalty term in the objective function;

[0226] Segmentation strategy: The link utilization range [0,1] is evenly divided into K segments. In this embodiment, K=10, that is, the length of each segment is 0.1. The segmentation breakpoints are {0, 0.1, 0.2, ..., 0.9, 1.0};

[0227] Through the above transformation, the original mixed-integer quadratic programming problem is transformed into a mixed-integer linear programming (MILP) problem, which can be solved using a mature MILP solver.

[0228] (3) Solving for acceleration strategies

[0229] The solution acceleration unit employs the following strategies to further improve solution efficiency:

[0230] Warm-start initialization: Before invoking the solver, the current path of each elephant flow is encoded as an initial feasible solution. Specifically, for the current path of flow f... For each link e on the network, set The initial value is 1. This initial solution satisfies all flow conservation constraints, providing an effective search starting point for the solver;

[0231] Search space reduction: For each flow f to be rerouted, compute the search space from the source node. to the destination node All jumps do not exceed The set of links traversed by a simple path Decision variables are created only for these links; for the remaining links... Fixed at 0. By from and Each executes a depth limit as follows Constructed using a breadth-first search of 2 / 2;

[0232] Infeasible link pre-filtering: for background load Exceed Links that are not selected are directly excluded from the candidate paths. Even if these links are selected, they are very likely to lead to constraint violations.

[0233] Symmetrical flow merging: If multiple elephant flows have the same ( , The nodes are paired and merged into a single virtual stream, with the bandwidth requirement being the sum of the bandwidth requirements of the individual streams. After optimization, the paths of the virtual stream are assigned to the original streams.

[0234] (4) Solver call

[0235] This embodiment uses the open-source CBC (Coin-or Branch and Cut) solver to solve the transformed mixed-integer linear programming model. The solution process is as follows:

[0236] (4.1) Construct the linearized optimization model according to the above specifications and generate the LP format model file;

[0237] (4.2) Load the model into the solver and set the hot start solution and termination parameters;

[0238] (4.3) Call the solver's branch and bound algorithm to solve the problem;

[0239] (4.4) After the solution is completed, extract each decision variable. The value is used to reconstruct a new path for each elephant flow.

[0240] In commercial deployment scenarios, commercial solvers such as CPLEX and Gurobi can also be used to achieve better performance. These solvers natively support quadratic programming problems and can directly solve the original MIQP model without linearization, but linearization methods have better versatility on open-source solvers.

[0241] Furthermore, the construction of a mixed-integer programming model based on the network-wide state information and the list of responsible elephant flows, with the objective of minimizing the maximum link utilization, specifically includes:

[0242] For each flow in the list of responsible elephant flows, set binary decision variables to characterize whether the flow passes through a specific link, forming a set of path allocation decision variables;

[0243] Based on the path allocation decision variable set, the bandwidth requirements of each flow, and the background load and link capacity of the link, the expected link utilization of each link is defined.

[0244] The core objective is to construct an optimization objective function that minimizes the maximum value among all expected link utilization rates.

[0245] To optimize the objective function, flow conservation constraints and link capacity constraints are added, forming a mixed integer programming model.

[0246] In this embodiment, the elephant flow rerouting problem is modeled as a mixed-integer nonlinear programming problem, specifically including:

[0247] (1) Problem input:

[0248] Network topology diagram ,in For a set of switch nodes, A set of directed links;

[0249] Each link capacity and corrected background load ;

[0250] A set of elephant flows awaiting rerouting Each stream With source node , destination node and bandwidth requirements .

[0251] (2) Decision variables:

[0252] For each flow and each link Define binary variables , indicating whether flow f passes through link e;

[0253] Define continuous variables This represents the maximum link utilization of the entire network after rerouting;

[0254] Define continuous variables , representing the utilization rate of each link e.

[0255] (3) Optimization objective: Minimize the weighted sum of the maximum link utilization and the link utilization variance penalty term:

[0256] ;

[0257] Where λ is the weighting coefficient (default value is 0.01). For link utilization, define: The objective function consists of two components:

[0258] Bottleneck Elimination Directly minimize the peak load of the entire network to ensure that the pressure on the most congested links is relieved;

[0259] Variance penalty term Σ By leveraging the convexity of quadratic functions, a superlinear penalty is imposed on high-load links, forcing the optimizer to tend to choose the path that minimizes the variance of the overall network traffic distribution among multiple feasible paths, thereby avoiding the concentration of traffic in a certain "low-lying area" and causing new congestion.

[0260] (4) Constraints:

[0261] Flow conservation constraint: For each flow f and each node v, the difference between the flow into and out of that node must equal the net demand of that node. The net demand of the source node is 1, and the net demand of the destination node is... The net demand at intermediate nodes is 0. This constraint ensures that each flow starts from the source node, reaches the destination node, and remains conserved at intermediate nodes, forming a complete path;

[0262] Capacity constraint: For each link e, the sum of the background load and the demand of all elephant flows passing through that link must not exceed the product of the link capacity and the maximum utilization rate. ;

[0263] Utilization upper bound constraint: Set the maximum allowable utilization rate (For example =0.85), reserving capacity margin for the link to cope with traffic fluctuations;

[0264] Path length constraint: The number of hops in each flow path does not exceed a preset limit. This avoids creating excessively long detours.

[0265] Furthermore, solving the mixed-integer programming model yields the globally optimal path allocation scheme for each flow in the responsibility elephant flow list, specifically including:

[0266] Set model solution parameters for a mixed integer programming model, including an upper limit on solution time and a relative gap tolerance;

[0267] Based on the current path of each flow in the responsibility elephant flow list, an initial feasible solution set is constructed as the hot start input of the solver;

[0268] Based on the preset upper limit of the number of path hops and the link load status, the search space of the mixed integer programming model is reduced to generate a reduced solution model.

[0269] Call the mathematical programming solver to solve the reduced solution model and obtain the path assignment variable solution that satisfies the constraints;

[0270] Based on the solution of the path assignment variables, determine the corresponding globally optimal path assignment scheme for each flow in the list of responsible elephant flows.

[0271] In this embodiment, to meet the real-time requirements of congestion control, the following strategy is adopted to accelerate the solution of the optimization model:

[0272] (1) Warm-start initialization: The current path of each elephant flow is encoded as an initial feasible solution and provided to the solver. Although the current path causes congestion, it is still a feasible solution that satisfies the flow conservation constraint. Starting from this point, the solver only needs to explore path changes that may improve the objective function, instead of constructing a solution from scratch, which can significantly reduce the search space.

[0273] (2) Problem size reduction:

[0274] Limit the optimization scope: For each elephant flow f to be rerouted, limit the search space to no more than the number of hops between the source node and the destination node. Within the subgraph, the subgraph is quickly constructed using a breadth-first search with finite depth;

[0275] Pre-filtering infeasible links: For links whose background load is already close to the capacity limit (e.g., exceeding 90%), they are directly excluded from the candidate paths;

[0276] Merging symmetric flows: If multiple elephant flows have the same source-destination node pairs, merge them into a virtual flow. After optimization, the paths of the virtual flow are then assigned to the original flows.

[0277] When the optimization algorithm fails to find a feasible solution within the time limit, the system switches to greedy mode to ensure robustness.

[0278] (1) Sort the elephant flows to be rerouted in descending order of bandwidth requirement;

[0279] (2) For each flow, calculate the weighted shortest path, with the path weight taking into account both link latency and current utilization: in, Represents path weight, For link latency, β represents the current utilization rate, and β is the penalty coefficient. This weighting design makes the algorithm tend to choose paths with low latency and light load;

[0280] (3) After each flow is assigned a path, the utilization rate of the corresponding link is updated immediately, which affects the path selection of subsequent flows;

[0281] (4) The time complexity of the greedy algorithm is O(n). It can be completed in milliseconds, ensuring that the system can still respond in a timely manner even in the worst case.

[0282] In some embodiments, step S105 above, which involves installing new path forwarding rules and deleting old path rules on each switch according to the globally optimal path allocation scheme and adopting a build-then-delete strategy to achieve smooth routing switching, specifically includes:

[0283] Based on the global optimal path allocation scheme, a corresponding new path forwarding rule instruction set is generated for each flow to be rerouted;

[0284] Following the order from the destination to the source, the new path forwarding rule instruction set is distributed to the relevant switches and installed to establish a new data forwarding path;

[0285] Wait for a preset convergence wait time to ensure that in-transit data packets transmitted on the old data forwarding path are processed;

[0286] After the convergence waiting time ends, delete the old forwarding rule instruction set corresponding to the old data forwarding path in the order from the source to the destination.

[0287] In this embodiment, a make-before-break strategy is used to achieve smooth route switching:

[0288] (1) For each elephant flow f that is rerouted, first follow the new path Install forwarding rules on each hop switch to ensure the new path is fully ready;

[0289] (2) Wait for the preset convergence time (e.g., 10 milliseconds) gives data packets that are already en route a chance to reach their destination along the old path;

[0290] (3) Delete old paths Forwarding rules that are no longer needed;

[0291] (4) The strategy ensures that there is at least one valid path from source to destination at any time, avoiding problems such as forwarding interruption, packet loss or routing loop.

[0292] The routing process and its activation specifically include:

[0293] (1) Generation of forwarding rules

[0294] The scheme output unit converts the path allocation results into specific forwarding rules. For each rerouted elephant flow f, its new path... = ( , , ..., It contains k links;

[0295] For each link on the path = ( , ), needs to be done on the switch Install a forwarding rule:

[0296] Matching condition: The destination IP address is equal to the destination IP of flow f (for scenarios requiring more granular differentiation, a complete 5-tuple can be used for matching).

[0297] Action: Forward the data packet to port (port) ), where port( ) is a link In the switch The corresponding output port;

[0298] The generated rule sets are grouped by switch and are ready to be distributed.

[0299] (2) First build then dismantle switching strategy

[0300] The rule distribution module employs a make-before-break strategy to perform route switching, ensuring that forwarding is not interrupted during the switching process. The specific steps are as follows:

[0301] Phase 1: New Path Rule Installation. For each rerouted flow f, forwarding rules are installed at each hop switch along the new path p_f^new. Rule installation proceeds from the destination to the source, meaning rules are installed first at the end switches, then sequentially forward, and finally at the source switches. This sequence ensures that the downstream path is fully ready when the source rules take effect and begin routing traffic.

[0302] Phase Two: Convergence Waiting After all new path rules are installed, wait for the convergence time T_converge (in this embodiment, T_converge = 10 milliseconds). This waiting time allows data packets still in transit on the old path to reach their destination, avoiding out-of-order data packets caused by sudden path switching;

[0303] Phase 3: Deletion of Old Path Rules After the convergence waiting period ends, delete the old paths. Remove forwarding rules that are no longer needed. Rule deletion follows the order from source to destination, the reverse of the installation order.

[0304] Throughout the handover process, flow f always has at least one valid path from source to destination, ensuring the continuity of forwarding.

[0305] (3) Rule conflict handling

[0306] When multiple elephant flows have the same destination address but different new paths, simple destination address matching cannot distinguish them. The rule distribution module uses the following strategy to handle such conflicts:

[0307] Strategy 1: Exact 5-tuple matching expands the matching criteria of the rule from the destination IP to the complete 5-tuple (source IP, destination IP, source port, destination port, protocol number). This method can accurately distinguish different flows, but it increases TCAM resource consumption;

[0308] Strategy 2: Tunnel encapsulation establishes an independent tunnel for each flow that needs to be differentiated (such as an MPLS label path or a Segment Routing path). The source switch adds a tunnel identifier to the data packet, the switches along the route forward the data according to the tunnel identifier, and the destination switch removes the tunnel identifier.

[0309] This embodiment prioritizes strategy one, and reverts to strategy two when TCAM resources are insufficient.

[0310] (4) Rule Issuance Agreement

[0311] The rule distribution module distributes rules to the switch via the control channel. This embodiment supports the following protocols:

[0312] OpenFlow protocol: Applicable to software switches and some hardware switches that support OpenFlow. Rules are issued in the form of FlowMod messages;

[0313] P4Runtime Protocol: Applicable to P4-based programmable switches. Rules are distributed via the gRPC interface in the form of TableEntries.

[0314] Vendor-specific protocols: For switches from specific vendors, rules can be issued through their management interfaces.

[0315] The rule distribution module abstracts the differences in the underlying protocols and provides a unified interface for installing and deleting rules.

[0316] Implementation Results: To verify the effectiveness of this invention, a systematic simulation experiment was conducted on the NS-3 network simulation platform. This section describes in detail the experimental environment configuration, comparison scheme settings, evaluation index selection, and experimental result analysis.

[0317] The experiment was conducted using the NS-3 (Network Simulator 3) network simulation platform. NS-3 is a discrete event simulator for network research, widely used in network protocol research and system verification in academia and industry. This experiment implemented the complete functionality of the data plane congestion detection module, network telemetry module, control plane optimization module, and rule distribution module described in this invention within NS-3.

[0318] (1) Experimental setup

[0319] To verify the applicability of this invention under different network sizes and structures, three representative real-world network topologies were selected for the experiment:

[0320] Abilene topology: The core topology of the US Internet2 academic backbone network, containing 11 nodes and 14 links, with a network diameter of 4 hops, representing a small-scale backbone network scenario;

[0321] GEANT topology: The core topology of the European academic research network, containing 22 nodes and 36 links, with a network diameter of 5 hops, representing a medium-sized wide area network scenario;

[0322] Germany50 topology: The topology of the Deutsche Telekom network, which includes 50 nodes and 88 links, with a network diameter of 7 hops, representing a large-scale network scenario;

[0323] The three topologies differ significantly in terms of the number of nodes, link density, and network diameter, which allows for a comprehensive evaluation of the performance of the invention in different network environments.

[0324] In the experiment, the background traffic was generated using the Poisson arrival model, and the traffic size followed a heavy-tailed distribution, so that the average network load was maintained at around 30%.

[0325] (2) Comparison of schemes

[0326] The experiment compares the proposed solution with the benchmark solution:

[0327] The baseline scheme (TCP congestion control) employs the built-in end-to-end congestion control mechanism of the TCP protocol, without enabling congestion flow detection and reporting functions in the data plane, and the control plane does not perform active traffic rerouting. When network congestion occurs, it passively responds solely based on TCP's congestion window adjustment mechanism. This scheme represents the traditional congestion control method widely deployed in current networks.

[0328] The present invention employs a solution that enables full data plane congestion detection and large flow identification, while the control plane performs proactive rerouting based on global state optimization. When the data plane detects congestion and identifies the responsible large flow, the control plane calculates the globally optimal rerouting scheme using a mixed-integer optimization model and sends it to the switches for execution.

[0329] (3) Evaluation indicators

[0330] The experiment uses Average Flow Completion Time (AFCT) as the core evaluation metric. Flow completion time is defined as the time interval between the sending of the first data packet and the acknowledgment of the last data packet in a flow. Average flow completion time is a key indicator of network transmission efficiency, directly reflecting user experience and application performance.

[0331] A lower average flow completion time means that data transmission is completed faster, network congestion is effectively alleviated, and link bandwidth is utilized more efficiently.

[0332] (4) Experimental results

[0333] Table 1 shows the comparison results of the average flow completion time of the present invention and the benchmark scheme on three network topologies;

[0334] Table 1 Comparison of average flow completion times (unit: seconds)

[0335]

[0336] This invention significantly outperforms the benchmark solution on all test topologies. The performance advantage of this invention compared to the benchmark solution mainly stems from three aspects:

[0337] First, the data plane offers rapid congestion detection and accurate attribution capabilities. Through a dual-index congestion determination mechanism and an adaptive large flow identification threshold, the system can identify the responsible large flow within milliseconds after congestion occurs, providing accurate input for subsequent rerouting decisions.

[0338] Second, the control plane's global optimization rerouting capability. Unlike the passive speed reduction of end-side congestion control, this invention actively schedules elephant flow paths through a global optimization model, alleviating current congestion while avoiding the initiation of new congestion points, thus achieving a balanced distribution of load across the entire network;

[0339] Third, a closed-loop control architecture with cross-layer collaboration. The close cooperation between the data plane and the control plane enables the system to strike a balance between rapid response and global optimization, ensuring real-time congestion response while avoiding routing oscillations caused by local greedy decisions.

[0340] Simulation results show that the network state-aware congestion rerouting method and system provided in this invention can significantly reduce the average flow completion time on network topologies of different sizes and structures, with performance improvements ranging from 12% to 30%. This invention achieves fast and accurate congestion detection and globally optimal flow scheduling through cross-layer collaboration between the data plane and control plane, effectively solving the problems of slow response and easy congestion migration in traditional congestion control schemes, and has good practical value and application prospects.

[0341] Reference Figure 2 An embodiment of the present invention provides a network state-aware congestion rerouting system 2, wherein the network state-aware congestion rerouting system 2 specifically includes:

[0342] The data plane detection module 201 is used to monitor the occupancy level and growth trend of the output port queue through the switch. When the queue occupancy exceeds the threshold and continues to increase in multiple consecutive time windows, it is determined that the system has entered a congestion state.

[0343] The network telemetry module 202 is used to calculate the contribution of each flow to the queue based on time-windowed outbound traffic statistics under congestion conditions, dynamically determine the large flow judgment threshold in combination with the number of active flows, identify flows whose contribution exceeds the large flow judgment threshold as responsible elephant flows, and form a list of responsible elephant flows.

[0344] The congestion reporting module 203 is used to report congestion notifications containing congestion location information, a list of responsible elephant flows and their contribution estimates to the control plane via a switch.

[0345] The control plane rerouting module 204 is used to model the rerouting problem as a mixed integer programming model with the goal of minimizing the maximum link utilization, based on the responsibility elephant flow list and network status information, and solve it to obtain the globally optimal path allocation scheme.

[0346] The rule distribution module 205 is used to install new path forwarding rules and delete old path rules on each switch according to the global optimal path allocation scheme and adopt the strategy of building first and then tearing down, so as to achieve smooth route switching.

[0347] It is understandable that, such as Figure 1 The content of the network state-aware congestion rerouting method embodiment shown is applicable to this network state-aware congestion rerouting system embodiment. The specific functions implemented in this network state-aware congestion rerouting system embodiment are the same as those shown below. Figure 1 The embodiment of the network state-aware congestion rerouting method shown is the same, and the beneficial effects achieved are the same as those described above. Figure 1The beneficial effects achieved by the network state-aware congestion rerouting method embodiment shown are also the same.

[0348] The network state-aware congestion rerouting system provided by this invention includes a data plane detection module, a network telemetry module, a congestion reporting module, a control plane rerouting module, and a rule distribution module.

[0349] The data plane detection module is deployed on the programmable switch in the network and is responsible for monitoring the status changes of each output port queue in real time. When congestion is detected, the responsible flow for the congestion is identified, and the congestion reporting module reports the congestion information to the control plane.

[0350] The network telemetry module is responsible for collecting link status information across the entire network. In this embodiment, in-band network telemetry (INT) technology is used to detect metadata such as queue depth, link utilization, and timestamps of data packets as they pass through each hop switch. The destination end extracts this data and reports it to the control plane rerouting module. In other embodiments, out-of-band telemetry or other network status acquisition mechanisms may also be used.

[0351] The control plane rerouting module and rule distribution module are the decision-making center of the system. They are responsible for fusing network telemetry data and congestion notification information, reconstructing the overall network state, and calculating the globally optimal rerouting scheme through optimization algorithms. This module includes a state fusion unit, a load correction unit, an optimization modeling unit, a solution acceleration unit, a greedy backoff unit, and a scheme output unit.

[0352] The rule distribution module is responsible for converting the rerouting decisions generated by the control plane into specific forwarding rules, and distributing them to the relevant switches using a build-then-tear strategy to ensure smooth routing switching.

[0353] Furthermore, the data plane detection module includes: a queue monitoring unit, used to sample the queue occupancy ratio and maintain historical samples at the end of each time window; a congestion determination unit, used to determine whether a congestion state has been entered based on the queue occupancy level and growth trend; a contribution statistics unit, used to update the number of dequeued bytes of the corresponding flow in the current time window when a data packet is dequeued; an active flow estimation unit, used to estimate the number of active flows in the current queue and map them to a predefined interval; a large flow identification unit, used to obtain a determination threshold by looking up a table according to the active flow interval and identify large flows whose contribution exceeds the threshold; and a notification generation unit, used to encapsulate the congestion location, the list of large flows, and the contribution information and send them to the control plane.

[0354] Furthermore, the control plane rerouting module includes: a state fusion unit for receiving and parsing network telemetry data and congestion notifications, and maintaining a network-wide link state table; a load correction unit for deducting the bandwidth contribution of the elephant flow to be rerouted from the original link load; an optimization modeling unit for constructing a mixed-integer nonlinear programming model; a solution acceleration unit for performing hot-start initialization, problem size reduction, and time control strategies; a greedy backoff unit for generating alternative solutions based on the weighted shortest path when the optimization solution fails; and a solution output unit for converting the path allocation results into forwarding rule issuance instructions.

[0355] The system's workflow is as follows: The data plane continuously monitors queue status. When persistent congestion is detected and the responsible large flow is identified, the congestion reporting module sends a congestion notification to the control plane rerouting module. Upon receiving the notification, the control plane rerouting module, in conjunction with the network-wide link status provided by the network telemetry module, solves the rerouting optimization problem. After optimization, the rule distribution module distributes the new path allocation scheme to the relevant switches. This closed loop enables the system to achieve a balance between the rapid response capability of the data plane and the global optimization capability of the control plane.

[0356] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0357] 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 merely 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 system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0358] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the network state-aware congestion rerouting method as described in any of the above methods.

[0359] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0360] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0361] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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 this application.

[0362] In the embodiments disclosed in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0363] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A network state-aware congestion rerouting method, characterized in that, The method specifically includes: The switch monitors the occupancy level and growth trend of the output port queue. When the queue occupancy exceeds the threshold and continues to increase within multiple consecutive time windows, it is determined that the system has entered a congestion state. In a congested state, the contribution of each flow to the queue is calculated based on the outbound traffic statistics of time windowing. The threshold for determining large flows is dynamically determined in combination with the number of active flows. Flows whose contribution exceeds the threshold for determining large flows are identified as responsible elephant flows, and a list of responsible elephant flows is formed. The congestion notification, which includes congestion location information, a list of responsible elephant flows, and their contribution estimates, is reported to the control plane via the switch. Based on the responsibility elephant flow list and network status information, the rerouting problem is modeled as a mixed integer programming model with the objective of minimizing the maximum link utilization, and the globally optimal path allocation scheme is obtained by solving it. Based on the globally optimal path allocation scheme, a build-then-delete strategy is adopted to install new path forwarding rules on each switch and delete old path rules to achieve smooth route switching.

2. The congestion-prone flow rerouting method based on network state awareness according to claim 1, characterized in that, The method involves monitoring the occupancy level and growth trend of the output port queue through the switch. When the queue occupancy exceeds a threshold and continues to increase over multiple consecutive time windows, a congestion state is determined. This specifically includes: Divide the timeline into equal-length time windows and sample the current queue occupancy rate at the end of each time window; Maintain a historical sample containing the queue occupancy ratios from multiple recent time windows; When the queue occupancy rate in the latest historical samples exceeds a preset threshold, and the queue occupancy rate in the historical samples shows a monotonically increasing trend over multiple consecutive time windows, the system is determined to be in a congested state.

3. The network state-aware congestion rerouting method for large flows according to claim 1, characterized in that, In congested conditions, the contribution of each flow to the queue is calculated based on time-windowed dequeue traffic statistics. A threshold for identifying large flows is dynamically determined by combining this with the number of active flows. Flows whose contribution exceeds this threshold are identified as "responsible elephant flows." Specifically, this includes: Based on the congestion status, initiate time-window-based dequeue traffic statistics to obtain an estimate of the contribution of each flow; Estimate the number of active flows in the current queue and dynamically calculate the large flow judgment threshold based on the number of active flows; The contribution estimates of each flow are compared with the dynamic large flow determination threshold, and flows whose contribution estimates exceed the large flow determination threshold are identified as responsible elephant flows.

4. The network state-aware congestion rerouting method for large flows according to claim 3, characterized in that, The initiation of time-windowed dequeue traffic statistics to obtain contribution estimates for each flow specifically includes: When a data packet dequeues within any time window, extract the flow identifier and data packet size of that data packet. Update the cumulative dequeue bytes of the corresponding stream within the statistical time window based on the stream identifier; The contribution estimate of each flow is calculated based on the cumulative number of dequeued bytes of each flow across all time windows.

5. The network state-aware congestion rerouting method for large flows according to claim 4, characterized in that, The process of estimating the number of active flows in the current queue and dynamically calculating the large flow determination threshold based on the number of active flows specifically includes: Based on packet dequeue events, a cardinality estimate of the number of active flows is obtained by using a probabilistic statistical algorithm to perform cardinality estimation on different flow identifiers. Based on the estimated number of active flows, the corresponding threshold range for determining large flows is determined according to a predefined mapping relationship. Obtain the specific flood determination threshold from the flood determination threshold range.

6. The network state-aware congestion rerouting method for large flows according to claim 1, characterized in that, Based on the responsibility elephant flow list and network state information, the rerouting problem is modeled as a mixed-integer programming model with the objective of minimizing the maximum link utilization, and the globally optimal path allocation scheme is obtained by solving it. Specifically, this includes: By combining network telemetry data with the responsibility elephant flow list, the overall network status information, including the background load and link capacity of each link, is reconstructed. Based on the network-wide status information and the list of responsible elephants, a hybrid integer programming model is constructed with the objective of minimizing the maximum link utilization. Solving the mixed-integer programming model yields the globally optimal path allocation scheme for each flow in the list of responsible elephant flows.

7. The network state-aware congestion rerouting method for large flows according to claim 6, characterized in that, The aforementioned mixed-integer programming model, based on the network-wide state information and the list of responsible elephant flows, aims to minimize the maximum link utilization. Specifically, it includes: For each flow in the list of responsible elephant flows, set binary decision variables to characterize whether the flow passes through a specific link, forming a set of path allocation decision variables; Based on the path allocation decision variable set, the bandwidth requirements of each flow, and the background load and link capacity of the link, the expected link utilization of each link is defined. The core objective is to construct an optimization objective function that minimizes the maximum value among all expected link utilization rates. To optimize the objective function, flow conservation constraints and link capacity constraints are added, forming a mixed integer programming model.

8. The network state-aware congestion rerouting method for large flows according to claim 6, characterized in that, Solving the mixed-integer programming model yields the globally optimal path allocation scheme for each flow in the responsibility elephant flow list, specifically including: Set model solution parameters for a mixed integer programming model, including an upper limit on solution time and a relative gap tolerance; Based on the current path of each flow in the responsibility elephant flow list, an initial feasible solution set is constructed as the hot start input of the solver; Based on the preset upper limit of the number of path hops and the link load status, the search space of the mixed integer programming model is reduced to generate a reduced solution model. Call the mathematical programming solver to solve the reduced solution model and obtain the path assignment variable solution that satisfies the constraints; Based on the solution of the path assignment variables, determine the corresponding globally optimal path assignment scheme for each flow in the list of responsible elephant flows.

9. The network state-aware congestion rerouting method for large flows according to claim 1, characterized in that, The process of installing new path forwarding rules and deleting old path rules on each switch according to the globally optimal path allocation scheme, using a "build first, then tear down" strategy to achieve smooth route switching, specifically includes: Based on the global optimal path allocation scheme, a corresponding new path forwarding rule instruction set is generated for each flow to be rerouted; Following the order from the destination to the source, the new path forwarding rule instruction set is distributed to the relevant switches and installed to establish a new data forwarding path; Wait for a preset convergence wait time to ensure that in-transit data packets transmitted on the old data forwarding path are processed; After the convergence waiting time ends, delete the old forwarding rule instruction set corresponding to the old data forwarding path in the order from the source to the destination.

10. A network state-aware congestion rerouting system, characterized in that, The system specifically includes: The data plane detection module is used to monitor the occupancy level and growth trend of the output port queue through the switch. When the queue occupancy exceeds the threshold and continues to increase within multiple consecutive time windows, it is determined that the system has entered a congestion state. The network telemetry module is used to calculate the contribution of each flow to the queue based on time-windowed outbound traffic statistics under congested conditions. It dynamically determines the threshold for large flow judgment by combining the number of active flows, identifies flows whose contribution exceeds the threshold for large flow judgment as responsible elephant flows, and forms a list of responsible elephant flows. The congestion reporting module is used to report congestion notifications, which include congestion location information, a list of responsible elephant flows and their contribution estimates, to the control plane via a switch. The control plane rerouting module is used to model the rerouting problem as a mixed integer programming model with the objective of minimizing the maximum link utilization, based on the responsibility elephant flow list and network status information, and solve it to obtain the globally optimal path allocation scheme. The rule distribution module is used to install new path forwarding rules and delete old path rules on each switch according to the global optimal path allocation scheme and adopt the strategy of building first and then tearing down, so as to achieve smooth route switching.

Images