Distributed routing method for long-distance cross-data center RDMA (Remote Direct Memory Access) network

Abstract

A distributed routing method for a long-distance cross-data center RDMA (Remote Direct Memory Access) network belongs to the field of communication, and comprises the following steps: pre-calculating path quality fraction coding propagation delay and link capacity; designing a switch real-time congestion estimator to calculate a congestion score; calculating the path cost by adopting a weighted fusion formula; the optimal path is selected through cost filtering and diversity preserving hash. By fusing the path quality and the real-time congestion signal of the switch, intelligent path selection of the cross-data center RDMA network flow is realized, and the problems of path isomerism asymmetry, congestion signal delay outdated, concurrent flow routing conflict and the like in the existing routing method are solved. According to the method, prospective congestion perception is provided on a data plane to suppress tail delay, the RDMA is kept friendly, low-risk increment deployment can be realized on programmable exchange hardware at a line speed and supported, medians and tail FCTs are reduced by 76% and 64%, and the flow transmission performance of the cross-data center RDMA network is remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, and specifically relates to a distributed routing method for long-distance cross-data center RDMA networks. Background Technology

[0002] Modern cloud services increasingly rely on data center (DC) deployments spanning multiple geographic locations to provide applications such as geographically replicated storage and distributed machine learning training. These applications impose stringent requirements on latency and throughput when transferring large amounts of data across data centers. To meet these demanding performance needs, cross-DC services based on Remote Direct Memory Access (RDMA) are being deployed. RDMA offloads the network stack to an RDMA network interface card (RNIC) and bypasses the kernel, achieving high throughput with extremely low latency and minimal CPU resource consumption. However, when these RDMAs traverse multiple cross-DC paths, new challenges emerge, including path asymmetry, timing lag in congestion signals, and conflicts arising from simultaneous routing of a large number of flows. These issues can cause existing routing methods to fail or experience significant performance degradation.

[0003] Existing routing methods mainly include the following categories:

[0004] (1) Equal Cost Multipath Forwarding (ECMP) and Weighted Multipath (WCMP): ECMP hashes the flow quintuple to randomly distribute the flow onto multiple paths considered "equivalent," making it simple to deploy and easy to implement in existing networks. Weighted schemes such as WCMP allow for the use of static weights to favor certain paths (e.g., favoring high-bandwidth paths) to improve load balancing. However, these methods generally have two shortcomings: firstly, they typically ignore the differences in propagation delay between paths and the tradeoff between link capacity and delay; secondly, the weights or hashes are mostly static or based on slowly changing information (e.g., link configuration), thus failing to respond promptly to short-term queue growth or bursts of traffic. In real-world delay-capacity conflict scenarios (i.e., some paths have high bandwidth but also high latency), the randomness of ECMP and the capacity preference of WCMP can both place delay-sensitive RDMA flows onto high-latency paths, significantly worsening the median and tail flow completion times (FCT).

[0005] (2) Centralized SDN traffic engineering (e.g., B4, Jupiter): This type of method performs global traffic planning and bandwidth allocation through the control plane, which can improve link utilization and throughput performance on a macro level. It is effective in batch migration between data centers or long-term traffic scheduling. However, the control loop of centralized traffic engineering has inherent latency (scheduling and distribution are often on the order of minutes or slower). Therefore, when the network experiences short-term sudden congestion or a large number of new flows arrive at the same time, the instructions of the control plane are often lagging behind and cannot make timely responses at the flow-by-flow granularity, making it difficult to suppress instantaneous queue surges and tail latency spikes.

[0006] (3) End-to-end congestion control algorithms (e.g., DCQCN, TIMELY, DCTCP, BiCC, etc.): These algorithms utilize ECN or delay feedback to adjust the transmission rate. They perform well in single-datacenter (short RTT) environments, effectively controlling queues and improving transmission stability. However, in long RTT environments spanning multiple datacenters, the delay of the end-to-end feedback loop increases significantly, causing congestion signals to become lagging and / or inefficient. Consequently, sender adjustments based on these signals cannot play a timely role in path selection or short-term congestion mitigation. Furthermore, these algorithms typically only focus on rate control and do not directly address the "which path to choose" problem. Therefore, they still rely on path selection mechanisms such as ECMP / static TE and are constrained by their limitations.

[0007] (4) Flow fragmentation or finer-grained traffic splitting techniques (such as Flowlet, Packet-spraying, etc.): These methods improve multipath utilization by distributing forwarding within a flow by time slice or packet, which is beneficial for throughput improvement. However, fine-grained traffic splitting introduces packet out-of-order delivery, and current mainstream RDMA RNICs are quite sensitive to out-of-order delivery: out-of-order delivery may be misjudged as packet loss and trigger retransmission or other recovery mechanisms, thus significantly impairing the latency and throughput performance of RDMA. To avoid this, modifications to the end host or RNIC are often required, or complex reordering / buffering mechanisms need to be introduced, which is costly and risky in deployment. Summary of the Invention

[0008] To address the shortcomings of existing routing methods in cross-data center RDMA scenarios, such as neglecting link quality (propagation delay, link capacity), delayed response to concurrency and sudden congestion, and insufficient compatibility with RDMA packet order sensitivity, this invention provides a distributed routing method for long-distance cross-data center RDMA networks. This invention integrates link quality from the control plane with congestion signals from the data plane at the switch, achieving a flow-based multipath selection mechanism that considers both path delay and bandwidth while rapidly responding to impending congestion, thus resolving several contradictions that existing routing methods struggle to balance.

[0009] The technical solution adopted by this invention to solve the technical problem is as follows:

[0010] This invention provides a distributed routing method for long-distance cross-data center RDMA networks, which mainly includes the following steps:

[0011] Step S1, Control Plane: Pre-calculate path quality score encoding propagation delay and link capacity;

[0012] Collect path attributes, use integer linear mapping and saturate at the maximum latency to obtain the latency score, calculate the link capacity score, synthesize the original path score with integer path weights and right-shift and normalize to obtain the path quality score;

[0013] Step S2, Data plane: Real-time calculation of congestion score;

[0014] Maintain the sampling register and sampling period, calculate the instantaneous queue level, update the short-term trend using EWMA in shift form, calculate the congestion persistence penalty, synthesize the congestion score using integer congestion weights and right-shift and normalize to obtain the congestion score.

[0015] Step S3, Data Surface: Flow-based Decision Making and Diversity Choice;

[0016] Flow identification and flow2output table lookup; read path quality scores in step S1 and calculate congestion scores in step S2; calculate fusion cost by fusing path quality scores from the control plane and congestion scores from the data plane using integer global fusion weights; filtering and path diversity selection strategies; fallback strategies; write mapping and garbage collection.

[0017] Furthermore, the formula for calculating the delay score is as follows:

[0018]

[0019] Where delayScore(p) is the delay score of candidate path p, S delay To normalize the number of right shifts, >>S delay Indicates a right shift S delay In the bit, MAX_DELAY represents the maximum saturation value of delay, delay(p) is the propagation delay of one leg of candidate path p, and linkCap(p) is the configured bandwidth of candidate path p.

[0020] Furthermore, the formula for calculating the link capacity score is as follows:

[0021] linkCapScore(p)=255-levelScore[idx](2)

[0022] Among them, levelScore[idx] is the level score. First, the configured bandwidth is classified into indexes using the bandwidth threshold array, and then the level score is obtained by looking up the link capacity threshold table.

[0023] Furthermore, the mathematical expression for synthesizing the original path score using integer path weights and then right-shifting and normalizing it to obtain the path quality score is as follows:

[0024] pathScore(p) = w dl delayScore(p)+w lc ·linkCapScore(p)(3)

[0025] C path (p) = min(pathScore(p)>>S path ,255)(4)

[0026] Where pathScore(p) is the original score of the path, w dl For delayed weights, w lc C represents the link capacity weight. path (p) represents the path quality score, S path To normalize the number of right shifts, >>S path Indicates a right shift S path The delayScore(p) is the delay score, and the linkCapScore(p) is the link capacity score.

[0027] Furthermore, the formula for calculating the short-term trend score is as follows:

[0028] T = T old -(T old >>K)+(Δ>>K)(5)

[0029] Among them, T old T represents the trend score of the previous time period, K is the trend shift constant, Δ is the difference between the number of current queue bytes sampled by the switch and the number of current queue bytes sampled in the previous time period, and T is the trend score of the previous time period. old >>K represents the trend score T of the previous time period. old The binary value of Δ is shifted right by K bits, where Δ >> K means shifting the binary value of the difference Δ to the right by K bits.

[0030] Furthermore, the mathematical expression for synthesizing the congestion score from the integer congestion weights and then right-shifting and normalizing it is as follows:

[0031] congScore(p) = w ql ·Q+w tl ·T+w dp ·D(6)

[0032] C cong (p)=min(congScore(p)>>S cong ,255)(7)

[0033] Where congestionScore(p) is the congestion score, w ql w represents the instantaneous queue weight. tl For short-term trend weighting, w dp For the continuous penalty weight, C cong (p) represents the normalized congestion score, S cong To normalize the number of bits for right shift, >>S cong Indicates a right shift S cong In this context, Q represents the instantaneous queue score, T represents the short-term trend score, and D represents the congestion persistence penalty score.

[0034] Furthermore, during the flow identification and flow2output table lookup process, a flow ID is generated for the arriving packet, and the local flow2output table is checked: if a mapping exists, the time of the most recent processing of the network flow data packet is refreshed and it is forwarded directly to ensure the stickiness of the path within the flow; otherwise, a new flow decision is made.

[0035] Furthermore, the formula for calculating the fusion cost is as follows:

[0036] C(p)=min((α·C path (p)+β·C cong (p))>>S final ,255)(8)

[0037] Among them, S final To normalize the number of right shifts, >>S final Indicates a right shift S final Bits, α, β are integer global fusion weights, C path (p) represents the normalized path quality score, C cong (p) represents the normalized congestion score.

[0038] Furthermore, the filtering and path diversity selection strategy is as follows: First, the candidate path set is sorted in ascending order of fusion cost, high-cost outgoing ports are removed, and low-cost sets are retained; then, the final outgoing port is selected based on the modulo operation of the flow ID within the filtered set; the fallback strategy is as follows: if all candidate paths are judged to be high-cost or the flow2output table is unavailable, the path will fall back directly to the local default equal-cost multipath forwarding.

[0039] Furthermore, during the writing mapping and garbage collection process, the mapping between the selected port and the flow ID is written to the locally constrained flow2output table, and subsequent packets are forwarded directly by looking up the flow2output table; the flow2output mapping table is a bounded cache, and the switch periodically performs garbage collection on timeout entries with the configured idle timeout to release space.

[0040] The beneficial effects of this invention are:

[0041] This invention provides a distributed routing method for long-distance cross-data center RDMA networks. By fusing path quality and real-time switch congestion signals, it achieves intelligent path selection for cross-data center RDMA network flows. Specifically, it includes: pre-calculating path quality scores to encode propagation delay and link capacity; designing a real-time switch congestion estimator to calculate congestion scores; calculating path costs using a weighted fusion formula; and selecting the optimal path through cost filtering and diversity-preserving hashing.

[0042] This invention solves the problems of path heterogeneity and asymmetry, outdated congestion signal delay, and concurrent flow routing conflicts in existing routing methods. Compared with existing routing methods, it has the following advantages:

[0043] (1) This invention proposes to fuse the path quality score pre-calculated in the control plane with the congestion score generated in real time in the data plane of the switch using configurable integer weights to form the final cost for flow-by-flow selection. This design explicitly separates and quantifies path quality (propagation delay and link capacity) from data plane congestion attributes (instantaneous queues, short-term trends, and congestion persistence), avoiding biased decisions based on a single dimension and enabling efficient comparison and selection in the data plane. Compared with static or slowly varying strategies that only use ECMP and WCMP, this invention avoids systematically allocating delay-sensitive flows to high-bandwidth but high-latency paths, thereby effectively reducing median latency.

[0044] Secondly, the data plane congestion estimation of this invention employs a fusion of Q (instantaneous queue), T (short-term trend represented by shifted EWMA), and D (congestion persistence count), enabling it to detect impending queue growth at the millisecond level and combine it with path quality for decision-making. This mechanism overcomes the signal lag limitations of control plane or end-to-end feedback in long RTT environments, allowing switches to make proactive choices regarding short-term congestion when new flows arrive, thereby suppressing short-term queue surges and reducing tail latency.

[0045] (2) This invention introduces a two-step mechanism in the selection phase: "filtering high-cost suffixes + selecting based on flow hashing within the low-cost set". First, obviously inferior paths are removed to narrow down the candidate set, and then hash selection is performed within the retained set. This maintains path diversity while prioritizing low cost, effectively suppressing the clustering effect caused by a large number of new flows simultaneously selecting the same path. This strategy avoids the trade-off between the slow response of centralized flow engineering and the blind randomness of ECMP.

[0046] (3) To be compatible with the packet order sensitivity of RDMA, this invention records and maintains a local mapping (flow2output table) of the "outgoing port" in the data plane, ensuring that subsequent packets within the flow go through the same outgoing port to avoid triggering the RNIC's retransmission mechanism due to out-of-order delivery. Compared with the out-of-order problem caused by fine-grained fragmentation, this invention can take into account both multi-path utilization and ordering without modifying the end host or RNIC, reducing deployment complexity and risk.

[0047] In summary, this invention takes into account both path quality and immediate congestion, provides forward-looking congestion awareness at the data plane to suppress tail latency, maintains RDMA friendliness (avoids out-of-order delivery), can be implemented at line speed on programmable switching hardware, and supports low-risk incremental deployment, making it significantly superior to various single or hybrid solutions of existing routing methods. Attached Figure Description

[0048] Figure 1 The flowchart illustrates a distributed routing method for long-distance cross-data center RDMA networks provided by this invention.

[0049] Figure 2 This is a system scenario diagram. Detailed Implementation

[0050] The present invention will be further described in detail below with reference to the accompanying drawings.

[0051] This invention provides a distributed routing method (LCMP) for long-distance cross-data center RDMA networks. Its core idea is to fuse the path quality score (a unified representation of propagation delay and link capacity) pre-calculated by the control plane with the congestion score generated in real-time by the switch data plane (obtained by fusing instantaneous queue level Q, short-term trend T, and congestion persistence penalty D) according to a global fusion weight, thus obtaining the fusion cost of each candidate path. In cross-data center networks with highly heterogeneous latency and link capacity, this invention designs a representation method that balances propagation delay and link capacity, enabling the data plane to quickly compare the quality of different paths when making flow-by-flow decisions. This invention can quickly detect congestion signals in long RTT environments, allowing flow-by-flow selection to make timely and efficient path switching for instantaneous congestion on a millisecond scale, without relying on lagging end-to-end feedback. This invention alleviates the clustering effect caused by a large number of concurrent flows simultaneously choosing a low-cost path.

[0052] like Figure 1 As shown, the present invention provides a distributed routing method for long-distance cross-data center RDMA networks, the specific implementation process of which is as follows:

[0053] Step S1, Control Plane: Calculate and distribute path quality scores;

[0054] Step S1.1: Collect path attributes;

[0055] The propagation delay delay(p) (in ms) and the configured bandwidth linkCap(p) (in Gbps) for each candidate path p are periodically (e.g., on a minute-hour basis) collected by the control plane.

[0056] Step S1.2: Calculate the delay score;

[0057] Using an integer linear mapping and saturating at the maximum latency, floating-point operations are avoided. The specific calculation formula is as follows:

[0058]

[0059] Where delayScore(p) is the delay score, S delay To normalize the number of right shifts, >>S delay Indicates a right shift S delay The bit MAX_DELAY represents the maximum saturation value of the delay. For example, when the maximum saturation value of delay MAX_DELAY is 32ms, then it corresponds to S delay It is 5.

[0060] Step S1.3: Calculate the link capacity score;

[0061] First, the configured bandwidth `linkCap(p)` is categorized using the bandwidth threshold array `linkCapThresholds[0..N-1]` (where N represents the preset number of categories) to obtain the index `idx`. Then, the level score `levelScore[idx]` is obtained by looking up the link capacity threshold table `linkCapThresholds`. To ensure that high bandwidth corresponds to low cost, the link capacity score `linkCapScore(p)` is defined as follows:

[0062] linkCapScore(p)=255-levelScore[idx](2)

[0063] The link capacity threshold table `linkCapThresholds` categorizes various configured link capacities (such as 10Gbps, 100Gbps, etc.) during the initialization phase. The bandwidth capacity corresponding to the current link is determined by looking up its index `idx` in the bandwidth threshold table, where `levelScore[idx]` is the level score for the current capacity. Since the link capacity score is inversely proportional to the actual value, the level score for the current capacity needs to be subtracted from 255.

[0064] Step S1.4: Synthesize and normalize the original scores of the path;

[0065] Use integer path weight w dl and w lc The original scores of the synthesized path are then right-shifted and normalized. The mathematical expression for this process is as follows:

[0066] pathScore(p) = w dl delayScore(p)+w lc ·linkCapScore(p)(3)

[0067] C path (p) = min(pathScore(p)>>S path ,255)(4)

[0068] Where pathScore(p) is the original score of the path, w dl For delayed weights, w lc C represents the link capacity weight. path (p) represents the normalized path quality score, S path To normalize the number of bits for right shift, >>S path Indicates a right shift S path Bit.

[0069] In the specific implementation process, the present invention preferably adopts integer-friendly parameter configuration, such as path weight (w dl ,w lc) = (3,1).

[0070] Step S1.5: Submit table and parameters;

[0071] The control plane stores vectors such as the path quality score table, link capacity threshold table (linkCapThresholds), and grade score table into its own switch buffer to ensure that the data plane can obtain the path quality score using a single path quality score table.

[0072] Step S2, Switch data plane: Real-time calculation of congestion score;

[0073] Step S2.1: Maintain the sampling register and sampling period;

[0074] Each output port maintains registers, including queueCur, queuePrev, trend, durCnt, and lastSample. Lightweight sampling tasks update these registers at short intervals (e.g., 1-10ms).

[0075] Step S2.2: Calculate the instantaneous queue level;

[0076] The queueCur (current queue byte count) recorded in the register is compared with the queue threshold table (qThresh) to obtain the level index, and then the instantaneous queue level Q∈[0,255) is obtained by looking up the levelScore table.

[0077] Step S2.3: Calculate the short-term trend;

[0078] The short-term trend T is updated using a shifted EWMA to avoid floating-point operations. The specific calculation formula is as follows:

[0079] T = T old -(T old >>K)+(Δ>>K)(5

[0080] Among them, T old T represents the trend score for the previous time period, K is the trend shift constant, Δ is the difference between queueCur (the number of bytes in the current queue sampled by the switch) and queuePrev (the number of bytes in the current queue sampled in the previous time period), and T is the trend score for the previous time period. old >>K indicates that T old The binary value of queueCur is shifted right by K bits (i.e., the decimal value is divided by 2 to the power of K). Δ>>K means shifting the binary value of the difference between queueCur and queuePrev to the right by K bits (i.e., the decimal value is divided by 2 to the power of K).

[0081] In the specific implementation process, the present invention preferably adopts integer-friendly parameter configuration, such as trend shift constant K = 3.

[0082] Step S2.4: Calculate the congestion persistence penalty;

[0083] When the instantaneous queue level Q exceeds the high watermark threshold, the register (durCnt) increments; otherwise, the register (durCnt) is shifted to the right to decay. The value of the congestion persistence penalty D is obtained by shifting the register (durCnt) to the right.

[0084] Step S2.5: Synthesize the congestion score;

[0085] Use integer congestion weight w ql ,w tl ,w dp The congestion score congScore(p) is synthesized and then right-shifted for normalization. The mathematical expression for this process is as follows:

[0086] congScore(p) = w ql ·Q+w tl ·T+w dp ·D(6)

[0087] C cong (p)=min(congScore(p)>>S cong ,255)(7)

[0088] Among them, w ql w represents the instantaneous queue weight. tl For short-term trend weighting, w dp The congestion score is the congestion score, where C is the weight for persistent penalty. cong (p) represents the normalized congestion score, S cong To normalize the number of bits for right shift, >>S cong Indicates a right shift S cong Bit.

[0089] In its implementation, this invention preferably employs integer-friendly parameter configurations, such as congestion weight (w). ql ,w tl ,w dp ) = (2,1,1).

[0090] Step S3, Data Surface: Flow-based Decision Making and Diversity Choice;

[0091] Step S3.1: Flow identification and flow2output table lookup;

[0092] Generate a flow ID (e.g., a 5-tuple hash) for the arriving packet; check the local flow2output table: if a mapping exists, refresh the last time the network flow packet was processed (lastSeen) and forward it directly to ensure stickiness of the path within the flow; otherwise, continue to make new flow decisions.

[0093] Step S3.2: Read the path quality score C according to step S1. path (p), calculate the congestion score C according to step S2. cong (p).

[0094] Step S3.3: Calculate the fusion cost;

[0095] The path quality score C of the control plane is fused using integer global fusion weights α and β. path (p) and the congestion score C of the data surface cong (p) Calculate the fusion cost C(p), the specific calculation formula is as follows:

[0096] C(p)=min((α·C path (p)+β·C cong (p))>>S final ,255)(8)

[0097] Among them, S final To normalize the number of right shifts, >>S final Indicates a right shift S final Bit.

[0098] In the specific implementation process, α and β are small integers. After testing, α:β = 3:1, which emphasizes path quality to reduce tail delay. After calculating the fusion cost C(p), it can be right-shifted for final normalization.

[0099] Step S3.4: Filtering and Path Diversity Selection Strategy;

[0100] First, the candidate path set (typically m∈[2,8]) is sorted in ascending order of fusion cost C(p). High-cost exit ports are removed, and the low-cost set is retained (the first set is retained by default). strip).

[0101] Then, within the filtered set, a modulo operation is performed based on the flow ID (hash the quintuple) to select the final output port, thereby ensuring that each new flow prioritizes low-cost paths while maintaining path diversity in multi-flow scenarios to avoid clustering effects.

[0102] Step S3.5: Rollback strategy;

[0103] If all candidate paths are judged to be high-cost or the flow2output table is unavailable, the system will fall back to the local default equal-cost multipath forwarding (ECMP).

[0104] Step S3.6: Write mapping and garbage collection;

[0105] To maintain RDMA compatibility, the mapping between selected ports and flow IDs is written to a locally constrained flow2output table. Subsequent packets are forwarded directly by looking up the flow2output table, thus ensuring packet ordering and avoiding RNIC retransmissions due to rerouting. This flow2output mapping table is a bounded cache, and the switch periodically garbage collects timeout entries with a configured idle timeout (e.g., shortTimeout based on RTT or a conservative fixed value) to free up space.

[0106] The following example illustrates the specific implementation details of a distributed routing method for long-distance cross-data center RDMA networks according to the present invention.

[0107] In this embodiment, a wide area network scenario spanning multiple data centers, comprising eight data centers, is first constructed, such as... Figure 2 As shown (DCI Switch refers to the Data Center Interconnect Switch, Spine to the spine switch, Leaf to the leaf switch, 4hostseachpod to each cluster has 4 hosts, and Legend represents the legend), there are 6 candidate paths between Data Center 1 (DC1) and Data Center 8 (DC8): DC2, DC3, DC4, DC5, DC6, and DC7. Table 1 shows the link information from DC1 to the 6 candidate paths. The link information from DC8 to these 6 candidate paths is the same as the previous link configuration. For any RDMA application flow that needs to be transmitted across DCs, the outbound DCI switch of the source DC will read the quality score of the candidate path in the routing table, combine it with the real-time congestion score of its local outbound port to make a flow-by-flow decision, select the outbound port, and record this mapping in the local flow2output. Subsequently, the data packet enters the wide area link along the selected path and finally reaches the inbound switch and host of the target DC.

[0108] Table 1 Topology Link Table

[0109] path via DC One-way propagation delay (ms) Link capacity (Gbps) p2 DC2 250 200 p3 DC3 25 200 p4 DC4 100 100 p5 DC5 10 100 p6 DC6 50 40 p7 DC7 5 40

[0110] The LCMP control plane statistically analyzes the propagation delay and configured capacity of available paths every few minutes to several hours, and calculates a quality score for each path according to preset mapping rules. Mapping rules may include: mapping one-way delay linearly to a range of 0-255, saturating to 255 if the delay exceeds the maximum saturation value MAX_DELAY (e.g., 512ms); mapping link capacity to levels using a capacity threshold vector and obtaining the corresponding score from a table, then inverting it using a 255-levelScore to reflect that higher capacity corresponds to lower cost.

[0111] The data plane maintains a 32-bit register (queueCur, queuePrev, trend, durCnt) for each candidate outgoing port at the switch side, and samples the port queue at sample intervals (e.g., every 1-10ms). Short-term trends are updated using a shifted EWMA (K=3) to suppress transient jitter and preserve growth directionality; persistent counts are used to record the duration of persistently high bits in the queue and to penalize long-term congestion. These three factors are weighted and right-shifted to normalize, resulting in a congestion score of 0-255.

[0112] Table 2 shows the 10 level scores (levelScore, equally spaced across 0-255). Table 3 shows the queue levels (qThresh). Table 4 shows 10 example intervals of the short-term trend T. Table 5 shows 10 example intervals of the bandwidth threshold array (linkCapThresholds) and their corresponding link capacity scores (linkCapScore).

[0113] Table 2 Level Score Table

[0114] Index (idx) Level score 0 0 1 28 2 57 3 85 4 113 5 142 6 170 7 198 8 227 9 255

[0115] Table 3. Queue Level qThresh Value Table

[0116] Index (idx) Queue level (qThresh) 0 <32KB 1 32–64KB 2 64–96KB 3 96–128KB 4 128–160KB 5 160–192KB 6 192–224KB 7 224–256KB 8 256–288KB 9 ≥288KB

[0117] Table 4 Short-term trend T value table

[0118]

[0119]

[0120] Table 5. Link Capacity and Corresponding Link Capacity Score Conversion Table

[0121] Index (idx) Bandwidth threshold array Grade Score Link capacity score 0 10 0 255 1 25 28 227 2 40 57 198 3 60 85 170 4 80 113 142 5 100 142 113 6 120 170 85 7 140 198 57 8 160 227 28 9 200 255 0

[0122] The specific implementation process of the distributed routing method for long-distance cross-data center RDMA networks in this embodiment is as follows:

[0123] (1) Control plane: Calculate and distribute path quality scores (path by path).

[0124] Based on formula (1), substituting the maximum saturation delay value MAX_DELAY = 512ms, S delay =9, and the calculated delay score is shown in Table 6.

[0125] Table 6 Control Plane Path Delay Scores

[0126] path Propagation delay (ms) Delay score p2 500 249 p3 50 24 p4 200 99 p5 20 9 p6 100 49 p7 10 4

[0127] Table 7 shows the link capacity scores obtained after querying Table 5.

[0128] Table 7 Link Capacity Score Table

[0129] path Link capacity (Gbps) Link capacity score p2 200 0 p3 200 0 p4 100 113 p5 100 113 p6 40 198 p7 40 198

[0130] Based on formulas (3) and (4), the original path score and path quality score are calculated, as shown in Table 8.

[0131] Table 8. Total Link Score Table

[0132]

[0133] (2) Data plane: Real-time sampling and calculation of congestion score (observation value at the sampling time).

[0134] In real-world operation, switches tend to prioritize placing the first packet of a new flow on paths with lower control plane evaluation costs (i.e., paths with lower path quality scores). Therefore, at the beginning of system operation or on short timescales, paths with low path quality scores (e.g., p3, p5, p7) attract more new flows, resulting in higher instantaneous queues, rising trends, and (potentially) persistent counts on the data plane. To reflect this reality, the example below sets the registers (queueCur, trend, durCnt) for paths p3, p5, and p7 to higher values ​​than other paths, resulting in relatively higher calculated congestion scores; while less frequently selected high-path-quality-score paths (e.g., p2, p4, p6) exhibit lower instantaneous queues and congestion scores. This realistically demonstrates how control plane preferences are fed back to the subsequent flow selection process through data plane sampling.

[0135] Table 9 provides the queueCur, queuePrev, and T functions. old durCnt represents the value observed by the switch for each output port at a certain sampling time.

[0136] Table 9 Congestion Observations from Data Surface Sampling

[0137] path queueCur(bytes) queuePrev(bytes) <![CDATA[T old ]]> durCnt p2 30,720 (≈30KB) 40,960 (≈40KB) 100 0 p3 307,200 (≈300KB) 204,800 (≈200KB) 2,000 2 p4 49,152 (≈48KB) 61,440 (≈60KB) 100 0 p5 184,320 (≈180KB) 122,880 (≈120KB) 1,500 1 p6 40,960 (≈40KB) 51,200 (≈50KB) 100 0 p7 122,880 (≈120KB) 61,440 (≈60KB) 800 1

[0138] Table 10 presents the results of the instantaneous queue level Q calculated by queueCur.

[0139] Table 10 Queue Level Q Value Table

[0140]

[0141]

[0142] The results of calculating the short-term trend T based on formula (5) are shown in Table 11.

[0143] Table 11 Short-term trend T value table

[0144] path Δ Δ>>3 <![CDATA[T old ]]> T T p2 -10,240 -1,280 100 -1,192 0 p3 102,400 12,800 2,000 14,550 227 p4 -12,288 -1,536 100 -1,448 0 p5 61,440 7,680 1,500 8,993 142 p6 -10,240 -1,280 100 -1,192 0 p7 61,440 7,680 800 8,380 142

[0145] Table 12 shows the results of the congestion persistence penalty D (example mapping: D = min(durCnt × 51, 255)).

[0146] Table 12 Congestion Persistence Penalty D Value Table

[0147] path durCnt D p2 0 0 p3 2 102 p4 0 0 p5 1 51 p6 0 0 p7 1 51

[0148] Based on formulas (6) and (7), the congestion score congScore(p) is synthesized and normalized to obtain the congestion score, as shown in Table 13. Paths with low path quality scores (p3, p5, p7) are frequently selected in a short period of time, resulting in higher Q / T / D levels and thus significantly improved congestion scores; paths with high path quality scores (p2, p4, p6) are relatively idle at this time, with low congestion scores. This data surface signal is used to immediately suppress the concentration of subsequent new flows into already compressed paths, alleviating the clustering effect.

[0149] Table 13 Congestion Costs Table

[0150]

[0151] (3) Data aspect: Integrating cost, sorting, filtering and flow decision.

[0152] The fusion cost is calculated based on formula (8), as shown in Table 14.

[0153] Table 14. Numerical Table of Fusion Cost C(p)

[0154]

[0155] Then, the fusion costs are sorted in ascending order and high-cost paths are filtered (keeping the lowest 50%), resulting in a final retention set of {p5, p7, p3}. The switch calculates flowID = HASH(5-tuple) from the quintuple of the first packet. For example, the hash value H = 20241015. The index is set to H mod k = 20241015 mod 3 = 0. Following the retention set order (p5, p7, p3), with index = 0, path p5 is selected as the outflow port. The data is then written to flow2output and the first packet is forwarded, as shown in Table 15.

[0156] Table 15 Flow2 Output Table

[0157] Fields Value (Example) flowID 0x1337BEEF / 20241015 outDevIdx port5

[0158] The present invention provides a distributed routing method for long-distance cross-data center RDMA networks. In 8-DC topology tests, it reduces the median and tail FCT by up to 76% and 64% respectively compared with existing routing methods, significantly improving the streaming performance of cross-data center RDMA networks.

[0159] This invention achieves simultaneous reduction of median and tail FCT in cross-DC RDMA network flow scenarios by fusing path quality from the slowly varying control plane with real-time congestion information from the rapidly varying data plane. Compared to existing methods such as ECMP / UCMP, this invention, by favoring low-latency paths and combining them with the current congestion status, significantly reduces the probability of latency-sensitive flows being incorrectly placed on high-latency paths, thereby reducing P50. Furthermore, this invention employs congestion estimation based on queues / trends / persistence and hash selection within low-cost sets to effectively avoid short-term queue saturation caused by clustering effects, significantly reducing tail latency such as P99. In addition, this invention uses integers and lookup tables for implementation, resulting in low resource overhead, compatibility with P4 programmable switches or SmartNICs, and only requires upgrading the DCI switch, facilitating incremental deployment and maintenance.

[0160] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A distributed routing method for long-distance cross-data center RDMA networks, characterized in that, Includes the following steps: Step S1, Control Plane: Pre-calculate path quality score encoding propagation delay and link capacity; Collect path attributes, use integer linear mapping and saturate at the maximum latency to obtain the latency score, calculate the link capacity score, synthesize the original path score with integer path weights and right-shift and normalize to obtain the path quality score; Step S2, Data plane: Real-time calculation of congestion score; Maintain the sampling register and sampling period, calculate the instantaneous queue level, update the short-term trend using EWMA in shift form, calculate the congestion persistence penalty, synthesize the congestion score using integer congestion weights and right-shift and normalize to obtain the congestion score. Step S3, Data Surface: Flow-based Decision Making and Diversity Choice; Flow identification and flow2output table lookup; read path quality scores in step S1 and calculate congestion scores in step S2; calculate fusion cost by fusing path quality scores from the control plane and congestion scores from the data plane using integer global fusion weights; filtering and path diversity selection strategies; fallback strategies; write mapping and garbage collection.

2. The distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, The formula for calculating the delay score is: Where delayScore(p) is the delay score of candidate path p, S delay To normalize the number of right shifts, >>S delay Indicates a right shift S delay In the bit, MAX_DELAY represents the maximum saturation value of delay, delay(p) is the propagation delay of one leg of candidate path p, and linkCap(p) is the configured bandwidth of candidate path p.

3. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, The formula for calculating the link capacity score is as follows: linkCapScore(p)=255-levelScore[idx] (2) Among them, levelScore[idx] is the level score. First, the configured bandwidth is classified into indexes using the bandwidth threshold array, and then the level score is obtained by looking up the link capacity threshold table.

4. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, The mathematical expression for synthesizing the original path score using integer path weights and then right-shifting and normalizing it to obtain the path quality score is as follows: pathScore(p)=w dl ·delayScore(p)+w lc ·inkCapScore(p) (3) C path (p)=min(pathScore(p)>>S path ,255) (4) Where pathScore(p) is the original score of the path, w dl For delayed weights, w lc C represents the link capacity weight. path (p) represents the path quality score, S path To normalize the number of bits for right shift, >>S path Indicates a right shift S path The delayScore(p) is the delay score, and the linkCapScore(p) is the link capacity score.

5. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, The formula for calculating the short-term trend score is as follows: T=T old -(T old >>K)+(Δ>>K) (5) Among them, T old T represents the trend score of the previous time period, K is the trend shift constant, Δ is the difference between the number of current queue bytes sampled by the switch and the number of current queue bytes sampled in the previous time period, and T is the trend score of the previous time period. old >>K represents the trend score T of the previous time period. old The binary value of Δ is shifted right by K bits, where Δ >> K means shifting the binary value of the difference Δ to the right by K bits.

6. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, The mathematical expression for synthesizing the congestion score from the integer congestion weights and then right-shifting and normalizing it is as follows: congScore(p)=w ql ·Q+w tl ·T+w dp ·D (6) C cong (p)=min(congScore(p)>>S cong ,255) (7) Where congScore(p) is the congestion score, w ql w represents the instantaneous queue weight. tl For short-term trend weighting, w dp For the continuous penalty weight, C cong (p) represents the normalized congestion score, S cong To normalize the number of bits for right shift, >>S cong Indicates a right shift S cong In this context, Q represents the instantaneous queue score, T represents the short-term trend score, and D represents the congestion persistence penalty score.

7. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, During the flow identification and flow2output table lookup process, a flow ID is generated for the arriving packet, and the local flow2output table is checked: if a mapping exists, the time of the last processing of the network flow data packet is refreshed and the packet is forwarded directly to ensure the stickiness of the path within the flow; otherwise, a new flow decision is made.

8. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, The formula for calculating the fusion cost is as follows: C(p)=min((α·C path (p)+β·C cong (p))>>S final ,255) (8) Among them, S final To normalize the number of bits for right shift, >>S final Indicates a right shift S final Bits, α, β are integer global fusion weights, C path (p) represents the normalized path quality score, C cong (p) represents the normalized congestion score.

9. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, The filtering and path diversity selection strategy is as follows: First, the candidate path set is sorted in ascending order of fusion cost, high-cost outgoing ports are removed, and low-cost sets are retained; then, the final outgoing port is selected based on the modulo operation of the flow ID within the filtered set; the fallback strategy is as follows: if all candidate paths are judged to be high-cost or the flow2output table is unavailable, the system will fall back to the local default equal-cost multipath forwarding.

10. A distributed routing method for long-distance cross-data center RDMA networks according to claim 1, characterized in that, During the writing mapping and garbage collection process, the mapping between the selected port and the flow ID is written to the locally constrained flow2output table, and subsequent packets are forwarded directly by looking up the flow2output table; the flow2output mapping table is a bounded cache, and the switch periodically performs garbage collection on timeout entries with the configured idle timeout to release space.

Images